Extending a file system

Latest response

Assumptions: VM server runnig RHEL 6 with SCSI drives /dev/sda and d/dev/sdb are already in use and a volume group named appvg which has logical volume, lv1 defined. A Virtual Disk 20G is size has been presented the the VM.

The current procedures I have for extending a ext3 file system is:

  1. Scan in the new LUN, say /dev/sdc
  2. Use fdisk to create a partition and type, say /dev/sdc1 as type 8e
  3. Create new physical volume, pvcreate /dev/sdc1
  4. Extend the volume group, vgextend appvg /dev/sdc1
  5. Extend the logical volume, lextend -L +20G /dev/appvg/lv1
  6. Extend the file system, resize2fs /dev/appvg/lv1

I hear rumor that under RHEL 6, creating a partition on the scanned LUNs is no longer necessary and that I can use vgextend appvg /dev/sdc without the need of running pvcreate first and that I can use the -r parm on lvextend to resize the file system.

Can I now just run the following commands?:

  1. Scan the new LUN, say /dev/sdc
  2. vgextend appvg /dev/sdc
  3. lvextend -L +20G -r /dev/appvg/lv1

If so why is a partition no longer needed on a LUN and is use of the lvextend -r only for ext4 file systems?

gb
Log in to join the conversation

Responses

ma Community Member 57 points
21 March 2014 8:07 AM

I've heard multiple discussions around this. For claims of best practice purpose, I've seen lots of setups employing the partition layout instead of whole device assignment. I will keep my eye on this thread too :)

PS Guru 6494 points
21 March 2014 11:52 AM

This isn't new to RHEL6, I remember having discussions about it on RHEL 5 (and potentially earlier).

There is always argument around this and I am very strongly in favour of using the partition and always have been for the simple fact that other administrators when looking at the disk can immediately identify that there is a partition on there and the disk is being used.

The argument I have heard against using the partition is that if you put it on the raw disk without the partition, you can then resize the raw disk underneath (be it with SAN or at the Hypervisor for eg.) and then just vgresize without having to modify and re-read the partition table which can be tedious (and problematic).

The counter argument I have to resizing disks is that if you are using LVM, you add storage by bringing in an additional disk/volume, creating a partition and extending your volume group onto that new disk/volume and then resize your volume group.

My ethos is that you shouldn't change the geometry of a disk once it is in use, and instead add additional pv's. If the pv count gets too high, bring in a large pv and move the contents of the multiple small pv's over. This may be an 'old school' way of thinking, and in the age where you can hot add CPU cores and RAM the attitudes towards resizing disks may well shift.

As for 'lvextend -r', I was under the impression that it could be used with any filesystem that supported resize2fs (not just ext4). It's not something I use regularly though. Where did you read the ext4 restriction? documentation somewhere? (the man page doesn't mention anything either)

thomas.jones2@dodiis.mil's picture Guru 6435 points
21 March 2014 1:34 PM

You could already just vgextend to the base /dev/sdX device prior to EL6. That said, doing so means:

  • that you can't force your partitions to be aligned (something you missed in your second step, btw.). While partition alignment isn't as important with physical systems - particularly physical systems that aren't trying to maximize disk-based I/O throughput, it does have greater impact in virtualizated environments (not so much to an individual VM but the virtualization environment as a whole).
  • you may limit your ability to subsequently alter the underlying blockdev (grow or shrink the storage-extent presented to the host) and have LVM properly recognize that new geometry.
Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.