3

Saturday I have to repartition my HDD. On my server I have 72GB HDD space which is not very much.

Currently my system is partitioned as follows:

Partition size:

Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/vg_web-lv_root
                       50G  5.8G   41G  13% /
tmpfs                 1.9G   16K  1.9G   1% /dev/shm
/dev/cciss/c0d0p1     485M   93M  367M  21% /boot
/dev/mapper/vg_web-lv_home
                       14G  8.7G  4.1G  68% /home

Inodes:

Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/mapper/vg_web-lv_root
                        3.2M    125K    3.1M    4% /
tmpfs                   179K       5    179K    1% /dev/shm
/dev/cciss/c0d0p1       126K      50    125K    1% /boot
/dev/mapper/vg_web-lv_home
                        869K    559K    311K   65% /home

I want to increase the /home directory with ± 20 - 30 GB and I want to decrease the root directory (/).

My server did already ran out of Inodes before I wiped a directory with 340.000 files. I get ± 15.000 small 1kb files a day.

Now I want to be sure that I don't get any issues saturday. Should I reinstall/format my harddisc and reinstall the system? Or should I repartition the harddisc and or how to do this?

2 Answers2

2

You don't need to reinstall/format your harddisk.

The answer to this question is dependent on filesystem - specifically, if your filesystem supports online resizing. I'm going to assume that you're using ext3/ext4 on all your partitions, but if not, you'll have to edit your question with more details.

Since we have to reduce root partition, so you need to boot system using Live CD or rescue CD , eg. SystemRescueCD

Note: Back up all your important data before attempting this. Always assume that you can lose all your data when resizing partitions.

This is an example of reducing a partition from 50 GB to 30 GB.

Shrink your filesystem, then LVM

Check the file system. If this fails or gives errors, you should reboot into a Live CD and fix your filesystem, then continue here.

Make sure that partition should be unmounted

# umount /dev/mapper/vg_web-lv_root 

then check file system

# e2fsck -yc /dev/mapper/vg_web-lv_root 

Resize the file system. (50 GB - 20 GB , Final Volume 30 GB)

# resize2fs  /dev/mapper/vg_web-lv_root 20G

Reduce the size of the logical volume.

# lvreduce -L 20G /dev/mapper/vg_web-lv_root

Enlarge the other filesystem and LVM volume

We're going to add 20G, since that's the amount that we clipped off the root filesystem.

# lvextend -L +20G /dev/mapper/vg_web-lv_home 
# resize2fs /dev/mapper/vg_web-lv_home
Rahul Patil
  • 24,711
  • Not every file system can be downsized - maybe I missed something, but I think OP doesn't mention using ext2. – peterph Sep 05 '13 at 21:26
  • 1
    Your lvreduce gives a size of 20G, but your resize2fs 30G. That's a good way to lose data! Also, I hope lvreduce and resize2f interpret 20G in exactly the same way, because if lvreduce treats it as smaller, again data loss :-( [also, you used blah in the lvreduce line instead of the name you used in the rest] – derobert Sep 05 '13 at 21:28
  • @derobert updated... please once review.. – Rahul Patil Sep 05 '13 at 21:56
  • @slm [about the edit you approved] when did ext4 get online shrink support? I don't think it has that. – derobert Sep 05 '13 at 22:00
  • @jasonwryan same question, I don't think ext4 can do online shrink – derobert Sep 05 '13 at 22:00
  • @RahulPatil unfortunately with that edit, you're running e2fsck on a mounted filesystem. Bad idea. I'm pretty sure you can't do an online shrink anyway, so you need to unmount the filesystem—which means a recovery disk... – derobert Sep 05 '13 at 22:03
  • @RahulPatil also, rather than separate steps, it should be much safer to use lvreduce -r... – derobert Sep 05 '13 at 22:05
  • @derobert thanks, but I haven't used that option – Rahul Patil Sep 05 '13 at 22:19
  • The size to resize2fs now sets the size to 20G so it agrees with lvreduce, but that is subtracting 30G, not 20G. – psusi Sep 06 '13 at 01:27
0

Adding size will also add some inodes, but not change the ratio of inodes to space. If you are storing a lot of small files you will probably run out of inodes again in the future, so you may want to backup and reformat that volume using a higher inodes to space ratio. Also if you have that many 1kb files, you may want to use a different filesystem as ext[234] will allocate a minimum of 4k, wasting 3k per file. As an alternative, if you are running a recent kernel that has the ability to inline file data in the inode, you can dedicate a fs just for these 1k files with a very high inode to space ratio and 2k inode size. This will also improve performance since it eliminates a seek between the inode and data block.

psusi
  • 17,303