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

Resizing and defragmenting Linux filesystems (NewsForge)

Posted Oct 14, 2003 7:38 UTC (Tue) by eru (subscriber, #2753)
In reply to: Resizing and defragmenting Linux filesystems (NewsForge) by vidileo
Parent article: Resizing and defragmenting Linux filesystems (NewsForge)

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.

(Log in to post comments)

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).