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.
It’s true: people still use Windows 2003. For one reason or another, be it obstinance or some other archaic piece of software, companies are forced to hold on to the Windows 2003 server operating system for much longer than many of us would like.
“Volume Shadow” was a nice feature incorporate in to Windows 2003 server. No additional client was needed. When enabled, you could right-mouse click on a file, select properties, and you were greeted with a window that has an additional tab labeled “Previous Version”.
At least, that was the promise. But, wait.. you’re looking. It’s not there. You’ve navigated to the folder, right-mouse clicked on the file, and there is no previous versions tab. Now you are thinking you need to go to a backup tape, and you are sweating a little bit over the validity of your backups.
Never mind what the age-old Tao of Backup tells us, we still sweat a little when having to turn to our backups. But then you are also positive Volume Shadow copy was enabled. So you check. You right-mouse click on “Computer” and select “Manage”, expand “Shared Folders”, right-mouse click on the drive, select “All tasks” and select “Configure volume shadow copy…” You look. You see it’s configured.
You scratch your head again. “Why am I not seeing the Previous Version tab?” you ask yourself. “Does it need a client?” So you navigate to C:\Windows\system32\twclient\twclient.msi and install it. As it is installing, you’re now thinking “But wait.. Windows 2003 included the client, didn’t it?” You are right.. it did. Installing the client doesn’t do any harm, though.
Still, there is no “Previous Versions” tab.
The Solution
Well, it seems that the ONLY way to see this tab is via the share itself. You cannot navigate to the file locally on the system and expect to see the “Previous Versions” tab. I’m guessing that the expectation was to provide this functionality to users directly, so the client would be installed on the Windows XP desktops.
On the server, select Start->run and enter “\\thisservername\thesharename\pathtofolder\”. When the folder opens, right-mouse click on the file, and you will now see the “Previous Versions” tab. Restore and breathe a little easier.
Now go make sure your backups are working. Just in case.