Extend an LVM volume in Linux

April 24th, 2012 | Posted by spritian in Linux | LVM - (3 Comments)

One of my clients needed to expand their DB since it was at 96% utilization. Thankfully, it was already in a volume group. Here are the steps I took to add a new LUN to the VG and expand it.

First, use fdisk to find the new LUN that doesn’t have a partition table and then use fdisk to create a new partition on it as Linux LVM:

[root@redhat ~]# fdisk -l [trimmed] Disk /dev/sdf: 429.4 GB, 429496729600 bytes 255 heads, 63 sectors/track, 52216 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk /dev/sdf doesn't contain a valid partition table [root@redhat ~]# fdisk /dev/sdf Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel Building a new DOS disklabel. Changes will remain in memory only, until you decide to write them. After that, of course, the previous content won't be recoverable. The number of cylinders for this disk is set to 52216. There is nothing wrong with that, but this is larger than 1024, and could in certain setups cause problems with: 1) software that runs at boot time (e.g., old versions of LILO) 2) booting and partitioning software from other OSs (e.g., DOS FDISK, OS/2 FDISK) Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite) Command (m for help): p Disk /dev/sdf: 429.4 GB, 429496729600 bytes 255 heads, 63 sectors/track, 52216 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System Command (m for help): n Command action e extended p primary partition (1-4) p Partition number (1-4): 1 First cylinder (1-52216, default 1): Using default value 1 Last cylinder or +size or +sizeM or +sizeK (1-52216, default 52216): Using default value 52216 Command (m for help): t Selected partition 1 Hex code (type L to list codes): 8e Changed system type of partition 1 to 8e (Linux LVM) Command (m for help): p Disk /dev/sdf: 429.4 GB, 429496729600 bytes 255 heads, 63 sectors/track, 52216 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sdf1 1 52216 419424988+ 8e Linux LVM Command (m for help): w The partition table has been altered! Calling ioctl() to re-read partition table. Syncing disks. [root@redhat ~]# fdisk -l [trimmed] Disk /dev/sdf: 429.4 GB, 429496729600 bytes 255 heads, 63 sectors/track, 52216 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sdf1 1 52216 419424988+ 8e Linux LVM

Now that the partition table is setup correctly, let’s create a new LVM on the drive, and extend our existing volume group using the new physical LUN.

[root@redhat ~]# pvcreate /dev/sdf1 Physical volume "/dev/sdf1" successfully created [root@redhat ~]# vgextend ora_vg1 /dev/sdf1 Volume group "ora_vg1" successfully extended

Here you can see our physical extents has increased due to the addition of the new physical drive to the volume group:

[root@redhat ~]# vgdisplay --- Volume group --- VG Name ora_vg1 System ID Format lvm2 Metadata Areas 5 Metadata Sequence No 9 VG Access read/write VG Status resizable MAX LV 0 Cur LV 3 Open LV 3 Max PV 0 Cur PV 5 Act PV 5 VG Size 1.18 TB PE Size 32.00 MB Total PE 38555 Alloc PE / Size 25728 / 804.00 GB Free PE / Size 12827 / 400.84 GB VG UUID nwH9uL-gm6q-QX1y-UbLm-dkKK-wgLt-b3ZkeY [root@redhat ~]# lvdisplay --- Logical volume --- LV Name /dev/ora_vg1/lvol_d03 VG Name ora_vg1 LV UUID CqjYQG-duhz-xniN-Vzha-PgVH-pcj3-vqOLar LV Write Access read/write LV Status available # open 1 LV Size 749.00 GB Current LE 23968 Segments 4 Allocation inherit Read ahead sectors 0 Block device 253:4

I only wanted to allocated ~75% of the new LUN to lvol_d03, so I took the Current LE 23968 from the previous lvdisplay. I prefer to actually distribute via Extents, rather than the easy way of +G, etc. So I added 9827 extents (from a total of 12827 free) to the existing 23968, totaling 33795:

[root@redhat ~]# lvextend -l 33795 /dev/ora_vg1/lvol_d03 Extending logical volume lvol_d03 to 1.03 TB Logical volume lvol_d03 successfully resized [root@redhat ~]# lvdisplay --- Logical volume --- LV Name /dev/ora_vg1/lvol_d03 VG Name ora_vg1 LV UUID CqjYQG-duhz-xniN-Vzha-PgVH-pcj3-vqOLar LV Write Access read/write LV Status available # open 1 LV Size 1.03 TB Current LE 33795 Segments 5 Allocation inherit Read ahead sectors 0 Block device 253:4 [root@redhat ~]# vgdisplay --- Volume group --- VG Name ora_vg1 System ID Format lvm2 Metadata Areas 5 Metadata Sequence No 10 VG Access read/write VG Status resizable MAX LV 0 Cur LV 3 Open LV 3 Max PV 0 Cur PV 5 Act PV 5 VG Size 1.18 TB PE Size 32.00 MB Total PE 38555 Alloc PE / Size 35555 / 1.09 TB Free PE / Size 3000 / 93.75 GB VG UUID nwH9uL-gm6q-QX1y-UbLm-dkKK-wgLt-b3ZkeY

Above you can see we still have 3000 extents available. I tend to leave a little as wiggle room so if we ever get into a position of running out of space we aren’t screwed. 🙂

Now that LVM has extended the volume group, we need to have the filesystem recognize it:
(This box didn’t have ext3online (older kernel; 2.6.9), so just decided to do it the old school way…)

[root@redhat ~]# resize2fs /dev/mapper/ora_vg1-lvol_d03 resize2fs 1.35 (28-Feb-2004) /dev/mapper/ora_vg1-lvol_d03 is mounted; can't resize a mounted filesystem! [root@redhat /]# umount /prod/d03 [root@redhat /]# e2fsck -f /dev/mapper/ora_vg1-lvol_d03 e2fsck 1.35 (28-Feb-2004) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information /dev/mapper/ora_vg1-lvol_d03: 128/98172928 files (14.8% non-contiguous), 195569167/196345856 blocks [root@redhat /]# resize2fs /dev/mapper/ora_vg1-lvol_d03 resize2fs 1.35 (28-Feb-2004) Resizing the filesystem on /dev/mapper/ora_vg1-lvol_d03 to 276848640 (4k) blocks. The filesystem on /dev/mapper/ora_vg1-lvol_d03 is now 276848640 blocks long.

That’s it, now the moment of truth…

[root@redhat /]# mount -a [root@redhat /]# df -h [trimmed] /dev/mapper/ora_vg1-lvol_d03 1.1T 735G 306G 71% /prod/d03

Woot, all good! (749GB to 1.1TB)

Fuppes v691 Debian Packages

April 11th, 2012 | Posted by spritian in Linux - (1 Comments)

For those who don’t know what Fuppes is – it’s a pretty sleek UPnP server. I love it, and works great with my Xbox 360 (with a minor code fix). I recently just migrated some of my major tasks that my Linux VM was doing to my Dell PowerEdge 2850. In doing so, the architecture changed (32 bit to 64 bit), so I had to go through the daunting task of re-compiling fuppes… YAY, not.

I created a new 64 bit Linux VM with a fresh install of Debian 6.0.4, so I could compile everything without making my main Linux box messy. This included: ffmpeg, x264, all the other libs ffmpeg requires, and fuppes svn rev 691. After a couple of hours, and banging my head (and wishing I had distcc setup, since make -j2 wasn’t cutting it on my ESX server), I have a couple of really nice debian packages for fuppes! Yes, you heard right!

The battle was won but it all started with obtaining ffmpeg and x264 releases from 01/2012. I tried some later releases, but fuppes complained about libavformat. Once I got those knocked out, next came fuppes. I’m not sure if it’s just broken in the later release, but there was an error with the sqlite3 sql statements in the code pertaining to Xbox 360. The fix I made makes it work on Xbox 360, but breaks the DNLA stuff. I don’t really care for that, since I run MediaTomb as well for my DNLA devices. I didn’t really want to rewrite a bunch of SQL code, or logic to make it work (since it seems Xbox and DNLA were using the same SQL statements). Instead, I just fixed it by appending an ORDER BY to one of the queries. With that said, I compiled a fairly vanilla copy of ffmpeg, but included a few things I use commonly when transcoding. Lastly, x264 had to be compiled with –enable-shared, so after you install the deb, you’ll need to add a path to ld.so.conf so ffmpeg will work.

Here are the links!

x264_fuppes691-1_amd64.deb

ffmpeg_fuppes691-1_amd64.deb

fuppes_0-1_amd64.deb

As stated, ffmpeg was compiled with the following:

--prefix=/usr --enable-avfilter --enable-vdpau --enable-bzlib --enable-libgsm --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libvorbis --enable-pthreads --enable-zlib --disable-stripping --enable-runtime-cpudetect --enable-gpl --enable-postproc --enable-swscale --enable-x11grab --enable-libdc1394 --enable-shared --disable-static --enable-libfaac --enable-nonfree --enable-libx264

To install, download all 3 debs and do:

dpkg -i *.deb

Pretty easy.

Don’t forget to add /usr/local/lib to ld.so.conf (or add a new file in ld.so.conf.d). Once you do that, run ldconfig.
If ffmpeg complains about libx264 missing, then you did something wrong, and read the last sentence very S-L-O-W-L-Y ;-).

ffmpeg and fuppes loading now? Good! Modify the default fuppes.cfg (and other cfgs) in /usr/var/lib/fuppes/ and you will be streaming to your Xbox 360 in no time!

I’ll make another post in a couple of days including my fuppes cfgs. Enjoy!