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!