Re-allocate space in partitions without losing data

Question

Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/md0               1829037   1745454         0 100% /
tmpfs                   255940         0    255940   0% /lib/init/rw
udev                     10240        44     10196   1% /dev
tmpfs                   255940         0    255940   0% /dev/shm
/dev/mapper/sys-srv  206424760  35519164 160419836  19% /srv

This is the output of my df on my server. It is obvious that I need spance in md0, and I would like to take it from the /srv. Can someone figure out the setup of my disks and advice me on how can I increase the 2gb on partition to 10 or more?

pvs output:

  Incorrect metadata area header checksum
  Incorrect metadata area header checksum
  Incorrect metadata area header checksum
  Incorrect metadata area header checksum
  Incorrect metadata area header checksum
  Incorrect metadata area header checksum
  PV         VG   Fmt  Attr PSize   PFree

  /dev/md0        lvm2 --   232.88G 232.88G
  /dev/md1   sys  lvm2 a-   231.02G  29.02G

vgs output:

  Incorrect metadata area header checksum
  VG   #PV #LV #SN Attr   VSize   VFree 
  sys    1   2   0 wz--n- 231.02G 29.02G

lvs output:

  Incorrect metadata area header checksum
  LV   VG   Attr   LSize   Origin Snap%  Move Log Copy% 
  srv  sys  -wi-ao 200.00G

  swap sys  -wi-ao   2.00G

fdsik -l output:

Disk /dev/sda: 250.0 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1         243     1951866   fd  Linux raid autodetect
/dev/sda2             244       30401   242244135   fd  Linux raid autodetect

Disk /dev/sdb: 250.0 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *           1         243     1951866   fd  Linux raid autodetect
/dev/sdb2             244       30401   242244135   fd  Linux raid autodetect

Disk /dev/md0: 1998 MB, 1998585856 bytes
2 heads, 4 sectors/track, 487936 cylinders
Units = cylinders of 8 * 512 = 4096 bytes

Disk /dev/md0 doesn't contain a valid partition table

Disk /dev/md1: 248.0 GB, 248057888768 bytes
2 heads, 4 sectors/track, 60561008 cylinders
Units = cylinders of 8 * 512 = 4096 bytes

Disk /dev/md1 doesn't contain a valid partition table

Disk /dev/dm-0: 2147 MB, 2147483648 bytes
255 heads, 63 sectors/track, 261 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Disk /dev/dm-0 doesn't contain a valid partition table

Disk /dev/dm-1: 214.7 GB, 214748364800 bytes
255 heads, 63 sectors/track, 26108 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Disk /dev/dm-1 doesn't contain a valid partition table

Answer 1

You'll need to add more detail. Partition layout (the output of fdisk -l) and /dev/mapper in df's output probably means you are using LVM so that too if that is the case (the output of pvs; vgs; lvs). Also the content of /proc/mdstat as your rood seems to be RAIDed.

The mix of RAID and LVM that your df output implies will make rearranging space much more difficult then if / and /srv were both in the same LVM volume group - you might find it quicker+easier to check your backups, wipe the machine, rearrange, and restore your data and config from backup. You may be able to move some stuff out of the root filesystem by shrinking /svr, creating new volumes with the freed space, moving files over and mounting them in the right place - this would buy you some space until you can schedule a bigger change. /home is often a good candidates for this, /var/log perhaps too, but it depends where the space is being used. Also as a quick win, make sure you have cleared out package caches (aptitude clean on Debian-a-like systems) and move any old logs from /var/log that you are unlikely to need.

Edit: (after the additional detail was added)

There seems to be something wrong in your setup as md0 looks like a ~2Gb volume mounted as a simple filesystem yet LVM has it listed as a (much larger) pv.

You have a chunk of free space on yout other pv/vg though, so unless you need that (for instance because you are using an LVM snapshot based method to take consistent backups with minimal downtime) you could move root there. The basic procedure would be:

1. Make some space on you current / (clean out temp files, delete package cache and/or old logs) so you are not running on fumes space wise
2. Add a logical volume for the new root filesystem with the size that you want with lvcreate
3. Boot from a LiveCD or similar (a rescue mode / single-user mode boot would probably work too and is morelikely to understand your RAID/LVM layout without extra jiggery pokery)). Hopefully this instance (the rescue boot or live cd) can see your RAID and LVM setup in which case:
4. Copy the filesystem raw with dd if=/dev/md0 of=/dev/mapper/sys-root, resize it to fill the larger logical volume with resize2fs /dev/mapper/sys-root (it'll demand you run fsck first, follow its instruction to do this), and given the copied filesystem a new UUID with uuidgen and tune2fs /dev/hdaX -U <uuid-generated-by-uuidgen> (also take note of that UUID, you may need it)
5. mount the new filesystem and update /etc/fstab to refer to your new filesystem instead of the old one
6. reboot and manually tell grub (I'm assuming grub, if it is an old install you may still be using lilo as the bootloader) to boot of this new filesystem instead of the old
7. if that worked you should be using the new filesystem as root happily, update it's grub config to include the new setup as an option and rerun grub-install with the new config
8. you still have the old filesystem present, and grub configured to offer dual boot between old+new, in case something is discovered wrong later

^{(on a break at work ATM, so I have no time to research the exact commands/procedures needed for the above - scout the relevant documentation/forums for more details)}

As with any major operation like this: make sure your backups are up-to-date before proceeding, and/or take full raw copies or the disks/filesystems to another drive, in case something goes irreversibly wrong.

Answer 2

Your /srv device is using LVM which allows you to reallocate diskspace fairly freely within a LVM managed device pool, unfortunately it looks like your root partition is mounted directly off your md0 RAID array so you probably won't be able to reallocate the space via LVM.

Instead you could mount part of what is in / under /srv using mount --bind, this makes part of what needs to be under / live in /srv, liberating some space on /dev/md0.

I'd suggest you might relocate the home areas (/home) or your /var mount points as they are usually the larger ones but you can investigate this for yourself by using du -sh /* to tell you the disk usage of everything under /.

You could then copy the contents of the large directory to /srv and bind mount it, then remount / somewhere else to delete the old contents of your copied directory, example recipe:

mkdir /srv/var
cp -a /var/* /srv/var/
mount --bind /var /srv/var
mkdir /tmp/root
mount /dev/md0 /tmp/root
#rm -rf /tmp/root/var

Note that if you're operating on any part of the file system that might be in use then this will best be done in single user mode, and be careful! You might want to just rename the copied partition on / for testing to make sure it works before you delete it.