Extending LVM & FS online with new disk
Recently my brother gave me his old laptop (some Sony Vaio) and I decided, that I will make mini-shell-server from it. It actually works great this way, but I encounter small obstacle – it has only 80G hard disk. It’s hard to extend this disk inside, so the more straight forward way was to add new external disk. I happened to have SATA II 250G hard disk, so I just bought external enclosure Welland ME-740J with USB support (as this laptop haven’t got eSATA).
On server I have Debian Squeeze installed with 2.6.32 kernel on it, so there was absolutely no problem with recognizing new hard disk after I plugged enclosure to USB port of the laptop (here’s an dmesg output):
[360327.763921] Initializing USB Mass Storage driver...
[360327.764262] scsi4 : SCSI emulation for USB Mass Storage devices
[360327.764376] usbcore: registered new interface driver usb-storage
[360327.764380] USB Mass Storage support registered.
[360327.764539] usb-storage: device found at 2
[360327.764541] usb-storage: waiting for device to settle before scanning
[360332.764350] usb-storage: device scan complete
[360332.767926] scsi 4:0:0:0: Direct-Access WDC WD25 00JS-22NCB1 PQ: 0 ANSI: 2
[360332.768794] sd 4:0:0:0: Attached scsi generic sg2 type 0
[360332.769870] sd 4:0:0:0: [sdb] 488397168 512-byte logical blocks: (250 GB/232 GiB)
[360332.772147] sd 4:0:0:0: [sdb] Write Protect is off
[360332.772155] sd 4:0:0:0: [sdb] Mode Sense: 38 00 00 00
[360332.772161] sd 4:0:0:0: [sdb] Assuming drive cache: write through
[360332.775767] sd 4:0:0:0: [sdb] Assuming drive cache: write through
[360332.775788] sdb: unknown partition table
[360332.782261] sd 4:0:0:0: [sdb] Assuming drive cache: write through
[360332.782277] sd 4:0:0:0: [sdb] Attached SCSI disk
And here’s output from fdisk -l:
Disk /dev/sdb: 250.1 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
Disk /dev/sdb doesn't contain a valid partition table
As you can see, my new disk is recognized as /dev/sdb and it has no partition table. I’m going to assign it to my existing Volume Group, cause I want to extend existing Logical Volumes and not creating new ones. That’s why, using fdisk, I will create one, ~250G partition for LVM:
fdisk -cu /dev/sdb
(inside fdisk): n
Command action
e extended
p primary partition (1-4)
(inside fdisk): p
Partition number (1-4): 1
First sector (2048-488397167, default 2048):
Using default value 2048
Last sector, +sectors or +size{K,M,G} (2048-488397167, default 488397167):
Using default value 488397167
Hopefully this is clear. Basically, all that has been done here, was creation of primary partition table (command n followed by p) and assigning full space to it (default values 2048-488397167). Now command p (inside fdisk) should show something like that:
Disk /dev/sdb: 250.1 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders, total 488397168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x7c5c7a2f
Device Boot Start End Blocks Id System
/dev/sdb1 2048 488397167 244197560 83 Linux
It needs to be available for LVM, so the partition type needs to be changed (still inside fdisk):
(inside fdisk): t
Selected partition 1
Hex code (type L to list codes): 8e
Changed system type of partition 1 to 8e (Linux LVM)
And here’s what command p is now showing:
Disk /dev/sdb: 250.1 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders, total 488397168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x7c5c7a2f
Device Boot Start End Blocks Id System
/dev/sdb1 2048 488397167 244197560 8e Linux LVM
Last step is to write changes that were made – command w inside fdisk will do the trick. Last check with dmesg to see, whether new partition is recognized by system:
[361136.668175] sdb: sdb1
OK, so here’s how my Volume Group looks like before attaching new disk:
vgdisplay
--- Volume group ---
VG Name dziobak
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 7
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 6
Open LV 6
Max PV 0
Cur PV 1
Act PV 1
VG Size 74.29 GiB
PE Size 4.00 MiB
Total PE 19018
Alloc PE / Size 19018 / 74.29 GiB
Free PE / Size 0 / 0
VG UUID oV4Qyj-HYQe-u2uK-31KW-HmHO-4kdM-x9CAl5
Now it’s time to “attach” new disk to this Volume Group:
pvcreate /dev/sdb1
vgextend dziobak /dev/sdb1
Volume group "dziobak" successfully extended
And here’s new vgdisplay output:
vgdisplay
--- Volume group ---
VG Name dziobak
System ID
Format lvm2
Metadata Areas 2
Metadata Sequence No 8
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 6
Open LV 6
Max PV 0
Cur PV 2
Act PV 2
VG Size 307.17 GiB
PE Size 4.00 MiB
Total PE 78636
Alloc PE / Size 19018 / 74.29 GiB
Free PE / Size 59618 / 232.88 GiB
VG UUID oV4Qyj-HYQe-u2uK-31KW-HmHO-4kdM-x9CAl5
As you can probably see, I’ve got 232.88 GiB of new free space to allocate inside this Volume Group. I don’t want to use all of it, as I may change plans somewhere in the future, so I decided, that additional 100G for /homepartition is all I need:
df -PTh /home
Filesystem Type Size Used Avail Use% Mounted on
/dev/mapper/dziobak-home ext4 61G 32G 27G 55% /home
Firstly, let’s check whether /home filesystem can be resized online. There’s a small applications called dumpe2fs, which, among other options, is able to print filesystems flags (-h flag). If there’s no resize_inode flag, then filesystem can’t be resized online:
dumpe2fs -h /dev/mapper/dziobak-home | grep resize_inode
dumpe2fs 1.41.12 (17-May-2010)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Good, we can resize:
lvextend -L+100G /dev/mapper/dziobak-home
Extending logical volume home to 161.48 GiB
Logical volume home successfully resized
resize2fs /dev/mapper/dziobak-home
resize2fs 1.41.12 (17-May-2010)
Filesystem at /dev/mapper/dziobak-home is mounted on /home; on-line resizing required
old desc_blocks = 4, new_desc_blocks = 11
Performing an on-line resize of /dev/mapper/dziobak-home to 42332160 (4k) blocks.
The filesystem on /dev/mapper/dziobak-home is now 42332160 blocks long.
Depending on sizes and disks itself, it can take some time. After that, my /home partition is much bigger:
df -PTh /home
Filesystem Type Size Used Avail Use% Mounted on
/dev/mapper/dziobak-home ext4 159G 32G 120G 21% /home
My Volume Group still have some free space to attach in the future:
vgdisplay
--- Volume group ---
VG Name dziobak
System ID
Format lvm2
Metadata Areas 2
Metadata Sequence No 9
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 6
Open LV 6
Max PV 0
Cur PV 2
Act PV 2
VG Size 307.17 GiB
PE Size 4.00 MiB
Total PE 78636
Alloc PE / Size 44618 / 174.29 GiB
Free PE / Size 34018 / 132.88 GiB
VG UUID oV4Qyj-HYQe-u2uK-31KW-HmHO-4kdM-x9CAl5
You’re welcome!
Discussion