Resizing and defragmenting Linux filesystems (NewsForge) [LWN.net]

Resizing and defragmenting Linux filesystems (NewsForge)

Posted Oct 14, 2003 7:01 UTC (Tue) by vidileo (subscriber, #7891)
Parent article: Resizing and defragmenting Linux filesystems (NewsForge)

Does this only work if you have free space (or a partition you can blow away) *after* the partition you want to resize? If this is the case, how would you rezise the filesystem in a partition 'squashed' by two others?

For example:
/dev/hda1 <- Swap
/dev/hda2 <- /var
/dev/hda3 <- /home
/dev/hda4 <- /tmp
/dev/hda5 <- /

How could you resize /var or /home or /tmp?

And another last question: Is it realy that bad to use a single filesystem for a PC/Laptop you only use it yourself? Has anyone had a bad experience with this?

(Log in to post comments)

Resizing and defragmenting Linux filesystems (NewsForge)

Posted Oct 14, 2003 7:38 UTC (Tue) by eru (subscriber, #2753) [Link]

How could you resize /var or /home or /tmp?

I guess you first have to shrink the partition that sits before the one you want to grow... But I believe that in a complex case like this it is much safer to make backups, wipe the disk clean and reinstall your system with a better partitioning.

And another last question: Is it realy that bad to use a single filesystem for a PC/Laptop you only use it yourself? Has anyone had a bad experience with this?

I don't think it is bad at all. I nowadays install my desktop system with with 3 partitions: "/boot", swap, and "/" for everything else, and believe this is the best arrangement for a personal system, because then you don't get inconvenient repartitioning problems if the usage of the various file systems is not what you expected initially.

Besides, disk space allocation is a prime example of a tedious mechanical task that should be entirely left to the computer. Users (or even administrators of less-demanding installations) should not have to care about partitioning. Linux can be made to work this way by using the above simple partitioning scheme.

Resizing and defragmenting Linux filesystems (NewsForge)

Posted Oct 14, 2003 10:35 UTC (Tue) by p00ya (guest, #15990) [Link]

I nowadays install my desktop system with with 3 partitions: "/boot", swap, and "/" for everything else, and believe this is the best arrangement for a personal system, because then you don't get inconvenient repartitioning problems if the usage of the various file systems is not what you expected initially.

Why have the /boot then? I'm running a reiserfs / at home quite happily, and there's nothing in /boot that isn't recoverable with grub on a rescue disk (or knoppix FTM). Take the usual security/safety precautions for a home system and you should be fine.

Resizing and defragmenting Linux filesystems (NewsForge)

Posted Oct 14, 2003 11:02 UTC (Tue) by eru (subscriber, #2753) [Link]

Why have the /boot then?

Supposedly with some BIOSes, LILO cannot boot the kernel if it lies too far from the beginning on a large disk. Putting it into its own partition at the beginning of the disk avoids this. Maybe this no longer matters on current computers and/or with Grub?

Resizing and defragmenting Linux filesystems (NewsForge)

Posted Oct 14, 2003 19:28 UTC (Tue) by vidileo (subscriber, #7891) [Link]

> I guess you first have to shrink the
> partition that sits before the one you want to grow...

And then do what? As far as I understood, you can enlarge the filesystem up to the end of the (previously enlarged) partition. By 'enlarged' I mean saying the partition end has bin shifted. But if you have free space *before* the partition you want to resize, how could you use it?

> Besides, disk space allocation is a prime example of a
> tedious mechanical task that should be entirely left to the computer

Well yes... but even so you wold need some guidelines like "notify me if partition full" or "partition should allways have xxx free space" or "don't resize this partition" (for /tmp for example). I guess it could be done with a volume manager that can resize volumes with mounted filesystems (and resize the filesystem, which is already possible).

Resizing and defragmenting Linux filesystems (NewsForge)

Posted Oct 14, 2003 8:19 UTC (Tue) by beejaybee (guest, #1581) [Link]

"And another last question: Is it realy that bad to use a single filesystem for a PC/Laptop you only use it yourself? Has anyone had a bad experience with this?"

Yes, it's bad. Just wait till your filesystem breaks for some reason.

The nice thing about having multiple partitions is that it allows you to do things like having multiple versions of the various partitions, so you can boot into an alternate filesystem & repair damaged filesystems properly.

This doesn't apply if all of the following conditions apply:

(a) you have 100% guaranteed mains supply, or a reliable UPS with infinite capacity;

(b) you use a reliable journalled filesystem, or a reliable RAID controller with parity or mirroring, and you don't mind the (sometimes lengthy) delay involved in restoring a damaged filesystem next time it's mounted;

And there's yet another benefit. If you have multiple partitions you can arrange things so that files & directories that shouldn't be written to (except during installation & patching) are mounted read-only. This is better protection than just setting the owner & access mode properly on the directories. You should be able to make it _very_ difficult for an intruder to make unauthorized changes to your system files, even if they somehow manage to acquire root priveleges.

Using only one partition is a bit like having only one user (root). It's convenient but not very secure.

Resizing and defragmenting Linux filesystems (NewsForge)

Posted Oct 14, 2003 9:40 UTC (Tue) by eru (subscriber, #2753) [Link]

I suspect you missed the context. We were talking about personal desktops and laptops, not servers. In the last case multiple file systems and building alternate roots etc. may make sense.

Linux actually does not lose the entire file system that easily in a crash, even with old ext2, and with modern journaling FS it is even less likely. Your reference to software reliability is really about the reliability of the kernel and system utilities, and Linux is not that unstable :-), unless you do development on these things or want to run bleeding-edge versions (for those users that do, I agree multiple file systems do make sense).

The security benefits you mention largely apply to servers. Having one partition is not comparable to doing everything as root, because the system is still protected by normal file permissions. And by-partition protection is too coarse anyway. What would be an improvement is importing the BSD idea of file flags and securelevels (there a file can be marked unmodifiable by anyone (even root), except in the lowest securelevel, and the securelevel can be lowered only by rebooting).

(Funny thing is, I have had these same discussions about the inconveniences of multiple partition even back in my MS-DOS days. Even there I preferred to not split disks so much, and others objected with much the same arguments as you...)

Resizing and defragmenting Linux filesystems (NewsForge)

Posted Oct 14, 2003 13:26 UTC (Tue) by bhw (guest, #15998) [Link]

You missed the point. They stated that this was for a personal use PC or laptop. I currently run 5 linux servers, 3 desktop PC's and 1 laptop that's been reloaded numerous times (RH 7.1 to RH9.0). I don't claim to be an expert, and yes it is nice to move data from one partition to another in the event of a crash. Allows you to reformat, etc.. and hopefully put everything back or blow it away and re-install the data later. On my servers, they use multiple partitions, multiple RAID drives and just in case, backups to other servers. On my desktop/laptops I run the 3 partitions previously mentioned, very flexable, very easy to add programs (/usr/local/...). My background comes from some very old versions of UNIX that would give most of you fits. Having the ability to boot in rescue mode on a Linux box to date has been a piece of cake. The point that has not been mentioned is proper backups. Store the data in a seperate drive, disk, tape, etc.. Then when it crashes, you have the choice of trying to fix the current filesystem(s) or blow it away and start over. I do though currently agree with you on production environments, partitions are the rule, but given time constrants, pull that blown drive, drop a new one in place and let your RAID card do it's job. The users are happy, and your not worrying about partitions and data recovery. Multiple partitons are more prone to problems if you use scripts to automatically backup data across partitions. Ever write to a directory where the partition failed to mount due to errors? You may have not known it until days later. I think we sometimes make things too hard just because we have always done it that way. Simplicity, reliability.