3

I have a few systems which have been running over a decade in a cluster on SLES 10 (now long past EOL). We're migrating to CentOS 6 64-bit. I got everything done but the final data syncs, and lo and behold, surprise, I ran out of disk space...except it's in the inode table, not the raw capacity. ReiserFS (in use on the SLES boxes) did not enforce a limit - indeed, I don't even know how many inodes there are in use because it not only doesn't enforce, it doesn't even track/report them. I can get that number with a one-liner, no problem.

My issue largely revolves around LVM, probably. That's my weak spot. I'm just really -fairly- new to using it, having mostly used raw devices since 1993.

What I have is a new machine with a logical volume group, containing a swap partition and the root filesystem as two volumes. It's a whopping 100GB, but it needs to have well over 6.5mil inodes...I ran out around 6.4mil.

I understand fully that I need to get a totally new ext4 filesystem made, as you can't increase the inode count at all.

I'm working under VMWare, which helps. I can simply add/remove virtual drives as necessary.

I want to basically replace the root filesystem with one which has a better inode ratio for our uses. What I am unsure of is how to handle the LVM parts of this, as well as the actual "restore the data without restoring the filesystem [i.e., the part which holds the inode table, etc.] itself. I basically need to get the data to a spare virtual drive, re-format the root partition as necessary, then restore the drive. LVM is getting in my way, knowledge-wise. I've familiarised myself with lvcreate, lvchange, etc., to some degree, but I could use a blow-by-blow description of which tools to properly use to handle the entire filesystem (it's one filesystem, which all resides on /, so it includes /dev, etc.) as far as backup and restore, and especially the LVM swap-out.

If it helps in writing the commands and such, assume vg_webserver4c6 as the logical volume group, and lv_root and lv_swap as the logical volume names. lv_root is the problem child.

Any help is greatly appreciated - the more detailed, the better!

Thanks!

Fairlight
  • 33
  • 2
  • Why do you need 6.5 million files in _the root filesystem_? You really should have those somewhere else. – Michael Hampton May 14 '14 at 23:34
  • Not my call. Someone decided that keeping years worth of records with request and response for transactions in a postfix-style directory heirarchy was a bright idea. It's the right call for readdir() performance compared to hitting double inode redirection on zillions of files in one directory, but it's hell on the inode usage. The "why" is of little import in this case. It's what I was given to contend with, and it has to be handled without changing their design. We really only have the root filesystem. We don't really enefit from segregation, and I'd hit the same issue on another mount – Fairlight May 14 '14 at 23:53

1 Answers1

3

  1. Use to tar or rsync to backup the whole filesystem. No need to include /dev/, /proc or /sys: these are created at boot time.

  2. no need to use any lv commands because you don't need to resize lv_root, you just need to recreate the filesystem with 10 million inodes:

    mkfs.ext4 -N 10000000 /

  3. use tar or rsync to restore the files

  4. fix your boot loader (rerun grub-install)

That's it.

Michael Martinez
  • 2,543
  • 3
  • 20
  • 31
  • Question: Say while I'm at it that I still want to make a new filesystem with a very large inode count, but make that partition bigger. Do you have a methodology for that? – Fairlight May 15 '14 at 01:34
  • This is confirmed as working as advertised. Excellent solution, thank you! I am still interested in knowing how to swap out that logical volume if necessary, though, if you know. – Fairlight May 15 '14 at 04:01
  • If you want to grow the logical volume to 150G and if the volume group has enough free space for this expansion, then simply do: lvextend -L 150G /dev/vg_webserver4c6/lv_root. After doing that, then you proceed with the steps given above. If the volume group does not have enough space, then first you would need to add some physical volumes using the "vgextend" command. – Michael Martinez May 15 '14 at 17:59