Go to content Go to navigation Go to search

Up! Adding a big disk to a Fedora server · Jul 18, 08:45 PM

I made some notes about what happened when I added a Terabyte of storage to an ageing server, how I rearranged things and what tools I used.

A home server consisting of a headless PC (ie. no screen or keyboard) is fairly simple to start with, but as it grows and evolves some care is needed to keep things well organised. In my case the server is a reused PC case, an Athlon CPU and motherboard with one ATA bus and two SATA connectors. An ancient 80GB ATA disk dated back to the Windows 95 era, it had been updated with another 80GB disk, then again with a 160GB SATA disk. Now I add a 1TB SATA and the machine is fully expanded. This is the second motherboard/CPU combination that the PC has seen, in the future I could add another SATA PCI card, or upgrade to a motherboard with more on-board SATA interfaces.

The OS is Fedora Linux – I had been running F10 for a while and took the opportunity to upgrade to F11 using preupgrade-cli, which went flawlessly. For this I attached a keyboard and screen, just in case I needed to intervene when the network connection was down – I didn’t. Normally access to the server is over ssh from a normal laptop or desktop PC.

The machine recognised the disks starting with the 160GB disk as the boot disk, the second SATA bus wasn’t connected, then the two ATA disks appeared, so I had sda, sdb and sdc. The /etc/fstab file mentioned several partitions on the sdb and sdc drives, so after adding the new disk, which became sdb, the fstab file had to be edited. On the first boot I got errors and a repair console. I just had to remount the root read-write and edit the fstab file to correct the partition names to reflect the changed device names, so

mount / -o remount,rw

In /etc/fstab:
/dev/sdb1 -> /dev/sdc1
/dev/sdb2 -> /dev/sdc2
/dev/sdb5 -> /dev/sdc5
/dev/sdc1 -> /dev/sdd1
/dev/sdv2 -> /dev/sdd2

I exited and the next boot was fine. But I had an empty disk without even a partition table. I could create a partition table but I wanted to assign the whole disk to a logical volume without any waste – this is unlike the first disk where a partition table was needed for booting. So I used the pvcreate command:

pvcreate /dev/sdb

Then I created a volume group:

vgcreate fatty /dev/sdb

You can display the physical volumes and volume groups using pvdisplay and vgdisplay. The latter is useful because it tells you how many extents are available, and that number is used in the next step. I had 238467 extents in ‘fatty’.

[root@mediator ~]# vgdisplay fatty
—- Volume group —-
[...]
Total PE 238467

Then I created a logical volume on the physical volume, using all the extents:

lvcreate fatty -l 238467

You can display the logical volume with lvdisplay, but if the command line tools aren’t user friendly enough you can use a graphical version. At first I hoped gparted would work, but unfortunately it doesn’t support LVM yet – this is a real shame. In fact my LVM on a physical disk without partition table showed up as an empty disk – which would be a bad thing if a naive user decided to overwrite it. Maybe I should have made a partition table and a single LVM partition in it after all.

gparted - GNU Partition Editor

The other graphical tool worth mentioning is system-config-lvm. It’s not installed by default so I had to grab it with yum:

yum install system-config-lvm

system-config-lvm graphical LVM editor

This is a good way to view and modify LVM but it doesn’t support formatting, cryptsetup or anything like that, which is a shame. I found no enterprise-ready storage management graphical tools. Maybe there are some and I just didn’t find them.

Resolving to use the command line tools, I looked at the existing layout: one boot disk with a boot partition, and a volume group split into home, root and swap; one ‘recycled’ disk with boot (unused), root (unused), swap (unused) and home (mounted as backup) partitions; one ‘upgrade’ disk split into two partitions, for backup and music.

The idea for the new order was to have the bulk of the storage on the Terabyte disk. a separate system disk for booting and home directories, and a disk for the web server / databases. This would leave a spare disk for backups or emergency. I would do all the copying I needed to do first and leave the existing disks untouched, just in case… I chose the ext4 filesystem as it seems reasonably stable now. I made an ext4 filesystem on the new volume:

mkfs.ext4 /dev/fatty/lvol0

I made a mount point and added the filesystem to the fstab file:

mkdir /opt/storage

In /etc/fstab:
UUID=7028c111-de8a-4cfb-b044-6ef9606a4faf /opt/storage ext4 defaults 1 2

I got the UUID using blkid:

blkid /dev/mapper/fatty-lvol0
/dev/mapper/fatty-lvol0: UUID=“7028c111-de8a-4cfb-b044-6ef9606a4faf” TYPE=“ext4”

Knowing that, I changed the rest of the filesystems in fstab to use the UUID instead of a changeable device name – no more booting problems after changing disks!

I set about copying the existing stuff to the new locations. There are many ways to do this but I chose rsync, because I like its progress reporting.

cd /opt/old-home
mkdir /opt/storage/old-home
rsync -a —progress * /opt/storage/old-home

Then a long wait for the old, full filesystem to be copied into its new home…

All fields are optional. Any email address won't be published on your comment.
After previewing your comment, you must submit it, if you want it to appear on the site.
  Textile Help

  ·