Ever find that your GPS map is directing you to your destination, and it happens to be in the middle of an intersection or a highway? Do you really buy all of the hype around Google Maps (Google owned) vs Apple Maps (based off of TomTom)? While it is certainly true that Apple deserves some lumps for releasing a Beta product (FYI, Google does this all of the time, but to their credit, they have never hidden that fact), fighting between the haters aside, an interesting tidbit is that not all map errors are application errors; sometimes they are a result of incorrect GPS data.
GPS data is really only managed by two (yes TWO) companies, Tele Atlas and NavTeq. All of the map providers subscribe to that data and then apply that GPS location data to their maps for use in their various mapping and routing applications. For countries other than the US, there may be other companies involved, so your mileage may vary.
If you truly believe that the GPS coordinates are to blame for your recent unexpected arrival at an open field or center lane of a highway near your destination, then it is time to submit a bug report to the GPS providers. Visit the MapFix site for details as to how to do just this! Specifically, you’ll want to update the GPS information at both vendors at the links below. It is a little cumbersome, but make sure you do more than just move the pin: you have to completely fill out the report in order for either vendor to take any action on the correction. Tele Atlas NavTeq
Hopefully, by doing so, the next person going to that address will actually arrive at their expected destination rather than someplace unexpected (overly dramatic, of course, but worth chuckling at This silly CNN article).
Sometimes adding a volume to a system is a requirement. Sometimes an existing logical volume under linux needs to be expanded. What ever the reason may be, getting to the GUI is not always a guarantee, so the underlying command line functions cannot be forgotten.
Step 1: Create the “physical volume”
After adding the drive to the system, a partition needs to be identified on the drive. You can optionally choose to not partition the drive and simply point to the full device (/dev/sdb vs /dev/sdb1), but it isn’t recommended specifically for the reason that it will likely cause pain at another time (mounting the volume on another system when you are trying to rescue it, etc.. basically, things you think you will never have a need for, but when it does happen, you don’t want to have already shot down your chances). fdisk /dev/sdb
n
p
1
<accept default>
<accept default>
w
q
With the partition created, create the “physical volume” identifier on the partition: pvcreate /dev/sdb1
Step 2: Create/Extend the volume Group
If this is a new volume group, create it via: vgcreate NewVolumeGroupName /dev/sdb1
If this added space will be used to extend an existing volume group, do this via: vgextend VolumeGroupName /dev/sdb1
We now have the volume group “VolumeGroupName” which contains this new physical volume.
Step 3: Create/Extend the logical volume
If this is a new logical volume, create it via: lvcreate -l 100%FREE -n NewLogicalVolume VolumeGroupName
If this added space will be used to extend an existing logical volume, do this via: lvextend -l +100%FREE -n LogicalVolumeName
We now have the logical volume “LogicalVolumeName” with all of the new space allocated to it.
Step 4: Create/Extend the filesystem
This is specific to ext3/ext4 which does not translate to other filesystems well.
If this is a new filesystem, simply run: mkfs -t ext4 -m 0 -j /dev/mapper/VolumeGroupName-LogicalVolumeName
And it will run for a few minutes as it sets up the file system. Once complete, mount it to where ever you so desire.
If this is to extend an existing filesystem, this can be done seamlessly and on the fly via: resize2fs /dev/mapper/VolumeGroupName-LogicalVolumeName
Best practice says to do this with the volume unmounted and followed by “fsck -y /dev/mapper/VolumeGroupName-LogicalVolumeName”, but ext3/ext4 filesystems extend very cleanly.
Step 5: Turn off boot time file system checks
Ext3/Ext4 are journaled file systems. Large file systems can take a LONG time to fsck, which could translate to a long time before the machine boots. It may not be best practice to turn these off, but, IMHO, a controlled fsck is better than a surprise one 4 months from now when a system is rebooted without a maintenance window large enough to compensate for a 40 minute fsck. tune2fs -i 0 -c 0 /dev/mapper/VolumeGroupName-LogicalVolumeName
The above command means that it will never automatically check the file system again. It is recommended that you plan for a scheduled file system check on your terms by running “touch /forcefsck” prior to a reboot of your system.
The concept of a Storage Area Network (SAN) and Network Attached Storage (NAS) has been around for a long time but it still generates a large amount of confusion amongst technical and semi-technical people alike.
Let’s review:
SAN
A Storage Area Network (SAN) is composed of an independent system, from one to N) which has the sole purpose of providing access to disk storage via a dedicated network protocol. That network protocol is typically independent of your normal “computer-to-computer” communications protocol (going over your “Ethernet” network), with one exception (iSCSI).
That’s it, really. From a computer or server’s perspective, it is storage (not just disk) space made available to it that is not internal to that computer/server.
A SAN does not provide a file system. This is a common misconception. It is storage only. The file system that will be created on that storage is left up to the client. This is critical to understand when certain advanced features are attempted with a SAN, such as staring storage among several hosts. Typically, a server, or series of servers, will be put in to place to create, manage, and share the file systems out to clients.
NAS
Network Attached Storage (NAS) is a way of presenting storage, as a filesystem, to computers and servers. Most home NAS systems are single units, but, in this discussion, we are talking about the enterprise. In enterprise solutions, a NAS is typically a localized SAN with a specialized controller in front of it, with the SAN typically bound to the controller/controllers. The number of devices managed by the NAS is limited, but that limit is extremely high. The controller is unique in that it does all of what the SAN controller would do plus managing the file systems on that storage.
A NAS does not need another system between it and the hosts that need to access the storage space. Since all file system management is done at the NAS controller, it will know how to share out the file system to all of its customers.
In Summary: a SAN is not a filesystem
Why Do People Use SANs in the Enterprise?
Cost. Simply cost. A SAN solution can be very economical on the cost/gb ratio in the entry-level arena. The nearly intangible expense to measure is the cost associated to managing the filesystems on the remote servers. NAS solutions can be quite expensive in the entry-level and lower mid-level arena, and tend to have better ROI in the mid-level and above arena. However, it all depends on what problem is to be solved.
Secondary answer would be: confusion. Administrators and managers alike do not fully understand the differences. Many say “we need more storage space” with the quick answer of “get a SAN” without grasping how the storage will be used and what the trade-offs are (Database? Virtual Machines? etc). Information which was true in the early days of SANs with regard to the SAN vs. NAS debate no longer holds true, but it still lingers around.
This seems to be a “NAS is better” write-up?
Again, it all depends on the problem that is being solved which should drive the direction of the solution to be implemented. Going by “this one is better than the other” does justice to no one. The point is, implementing a SAN is not a superior alternative, it is just an alternative.
For example, complex environments which have a need for GlobusFS or MooseFS, would not benefit from a NAS since those highly customized clustered filesystems are not directly supported by a NAS. Your typical office location made up of windows desktops, servers, and even a mix of linux hosts, would benefit greatly from a NAS.
Remember: A SAN is disk storage for the hosts to manage. A NAS is storage with a file system.