How to shrink a root filesystem?

[Chris Moore_6]

I've got an RHEL4 OS running on an ia64 system. I currently have / mounted on /VolGroup00/LogVol0, as is the default when installing. I'd like to split that into multiple logical volumes like hp-ux does - for /var, /tmp, /usr, and so on.

Shouldn't be that hard - create the new directories, copy the files over, and mount them. But the lvol that / is mounted on takes up the whole volgroup right now. I'd like to shrink the filesystem, then shrink the lvol, so that I'll have room to create new directories. Is this possible? I can't seem to find anything about shrinking an ext3 filesystem while it's mounted.

[Steven E. Protter]

Shalom,

You are best advised to reinstall the operating system. reducing root at this point will take multiple steps as you reduce, create a new filesystem and attempt to move stuff.

Soft links will get broken and you really will have a lot of trouble with this.

It is possible, but I think you will need to dismount it.

My suggestion would be to boot off a knoppix or Centos Live CD and use parted to change partition sizes.

SEP

[Ivan Ferreira]

You cannot shrink a file system while mounted, and shrinking LV implies that you must destroy the LV. In this case, it would be better to reinstall the OS and restore data.

[Morcos]

The ext2online is used for filesystem online(mounted), but there is restriction on ext2onlie: u can use it to increase the size of filesystem. it's not possible to reduce a filesystem's size.
so to reduce, the file system must be unmounted.

Regards,
Ziad

[Rick Garland]

I wouldn't even think of shrinking the root filesystem

Reload the OS if you really need to reclaim some space.

If you can live with - good. I never have a problem with a root filesystem that is too big. (within reason, of course)

[Kodjo Agbenu · Accepted solution]

Hi,

My suggestion : boot on a live CD or a SuSE install CD in rescue mode, then :

0. light a candle and pray :-)

1. fsck the filesystem offline

2. shrink the filesystem offline, using ex2resize for example

3. shrink the lvol size accordingly

4. fsck the filesystem again to make sure

5. light another candle and pray again

6. reboot


Good lcuk.
Kodjo

[Andrew Bruce]

Hi Chris,

In addition to everyone's comments on shrinkage, etc., I thought I would add a few words about LVM (well, more accurately, splitting up a *nix directory structure into individual partitions/logical volumes)...

You commented that you'd like to rearrange the disk layout to use separate logical volumes for /var, /tmp, /usr, and so on, a la HP-UX:

I thought of doing this a while ago - my first *serious* play with Unix was HP-UX, so it followed that when plying with Linux, I'd like to have a similar disk structure.

Having gone through a lot of pain, I recommend you think long and hard about why you want to use LVM to split the directory structure. It adds an extra layer of complexity to your installation, and can give you lots of headaches if you later decide to change your layout. It is a lot harder to remove LVs and increase sizes, etc. than it is to have one big / partition.

Of course, this depends on what use your Linux system is for (server, workstation, home PC), how many disks you have, etc..

One big *disadvantage* of breaking out the different disk areas into separate LVs (or partitions for that matter) is that if you get your sizing wrong, you're left with an inflexible directory structure. For example, you underestimate how much space you need in /usr and it fills up. If it is a separate LV then you have to resize. If it is simply a part of / then you're happy until / fills up!

Partitions I try to stick to these days are a:

/
/home

This way, user files are safely away from the OS (easier to update/reinstall/change the OS), while the OS itself uses as much space as it needs across the directory structure.

Best regards,

Andy Bruce

[Andrew Bruce]

Oh, forgot to add:

Don't forget to hand out points - it's our reason to be here!

A.

ps No points for this particular post though! ;-)

[Chris Moore_6]

Thanks for all the answers. I'm really surprised that anyone would consider reloading a system rather than resizing a volume. To me a reload is a last chance desperate measure, if the resize fails. Reloading means I'm throwing away everything I've done for the past year and hoping that my backups really have exactly what I need, nothing I don't need, and that I can restore them reliably.

Kodjo had pretty much the answer I expected - boot some other bootable media, then adjust the filesystem while it's unmounted. I just haven't yet found bootable media for ia64 which will give me a shell with all the tools. There seem to be a lot of rescue CDs and Live CDs out there, but none that I've found that work on ia64.

Andrew had some excellent insight into the "whys" of the problem, and I think that's the final answer to the question. I come from the HP-UX world, and on HP-UX it's trivial to resize filesystems and logical volumes. This is precisely the argument in favor of splitting up the filesystems - you don't have to worry about someone filling /tmp and bringing the system down, and if you get corruption in /var you can umount it and fsck it easily. And if you later find out that /home is too big or /opt is too small you just resize them. It sounds like Linux doesn't yet have the ability to dynamically resize filesystems and logical volumes, so it looks like I'm better off keeping it the way it is.

Thanks to everyone for the help.

[Chris Moore_6]

See my previous post as to the solution.

[Andrew Bruce]

No points then? :-(

A.

[Chris Moore_6]

I thought I did the points...where did they go? I'll try again.