[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Single root filesystem evilness decreasing in 2010? (on workstations)

On Sun, 28 Feb 2010, thib wrote:

Usually I never ask myself whether I should organize my disks into separate filesystems or not. I just think "how?" and I go with a cool layout without thinking back - LVM lets us correct them easily anyway. I should even say that I believed a single root filesystem on a system was "a first sign" (you know what I mean ;-).

But now I'm about to try a new setup for a Squeeze/Sid *workstation*, and I somehow feel I could be a little more open-minded. I'd like some input on what I covered, and more importantly, on what I may have missed. Maybe someone can point me to some actually useful lists of advantages to "partitioning"? I find a lot of BS around the net, people often miss the purpose of it.

So, what are the advantages I see, and why don't they matter to me anymore?

I've been pondering this myself of late. I was going to post to another list (SAGE or SAGE-AU) but you've done such a nice list of advantages/disadvantages that I think I'll piggy back here :)

I'm a long-time sysadmin and generally deal with servers but of course people ask my advice on workstations too.

* Filesystem corruption containment

A corrupt root filesystem is _much_ worse than a corrupt non-root filesystem. As long as the root FS is ok the box will boot, possibly without network access.

OTOH a box booted with just the root FS mounted is probably pretty useless. These days if a box has any filesystem problem I'm likely to boot it from a live cdrom to perform recoveries. In the past reasonably alternatives were available too though. Some Unixen in the 80s could boot from tape for example.

In the end the final defence against a corrupt filesystem is the backups.

* Free space issues

Since I'm the only one who uses this machine, I should know if something may go wrong and eat up my entire filesystem (which is quite big for a workstation). Yes, I still monitor them constantly.

On servers there is a concern about one part of the filesystem gobbling all the space. This has been one of the most compelling reasons to use multiple partitions.

Some filesystems such as XFS & ZFS allow you to effectively set quotas on parts of the filesystem. I think we'll see this becoming more common. This takes away a big part of the need for multiple filesystems.

* Specific mount options

According to the Lenny manpage, mount(8) --bind won't allow me to set specific options to the remounted tree, I wonder if this limitation can possibly be lifted. If not, I think a dummy virtual filesystem would do the trick, but that seems kludgy, doesn't it? Pointers?

I guess I could live without it, but I would actually find this quite annoying.

This is a good point. I actually hadn't considered this in my list. I'll respond by saying that in general the mount options I use for different filesystems on the same box do not vary much (or at all) in practice. If I want a filesystem marked noatime then I probably want all the filesystems marked noatime. There are exceptions to this of course.

* System software replacement

Easier to reinstall the system if it's on separate volumes than conf and data? Come on..

That's true but the time savings is not terribly great IMHO. The system can be backing up and restoring the dats while the human is off doing other stuff. Saves computer time (cheap) but not human time (expensive).

For a workstation, I don't need a fast system recovery mechanism, and I want to minimize my backup sizes. I'd rather save a list of selections rather than a big archive of binaries.

I recommend backing up all system binaries. It's the only way you can guarantee you will get back to the same system you had before the rebuild. This is most important for servers were even small behavioural changes can impact the system in a big way.

See this link for my talk on backups which goes in to this issue further:


All the info in this talk is being transferred to http://www.practicalsysadmin.com.

* Fragmentation optimization

One of the most obvious advantages, and usually my main motivation to separate these logs, spools, misc system variable data, temporary directories, personal data, static software and configuration files.

This is less of an issue than it used to be. Even ext2 will work towards minimising fragmentation. Several *nix filesystems now allow for online defragmentation (eg, xfs). I expect this problem will completely vanish in the future.

* Metadata (i-node) table sizes

While this may be a problem now I think it will be less of a problem in the future as some filesystems already allow you to add i-nodes dynamically and this will increasingly be the case.

* Block/Volume level operations (dm-crypt, backup, ...)

Encryption (with LUKS) in particular should beat any implementation at filesystem level. I don't have any number to back that up, however (although I remember seeing some).

Yes this is a good point. You may not want or be able to encrypt the entire disk.

As said earlier, I don't need a fast backup solution. I already prefer smarter filesystem-based backup systems in general.

As do I. What do you use? If you want to use dump with ext2/3/4 you will need to snapshot for data safety.

* Special block sizes for specific trees

I found a maildir with a 1k block size was more convenient than the current 4k default, for example. The solution is simple, "use a database".

This is a good argument too.  On a server this really can be important.

* (Mad?) positioning optimizations

It's often said some sectors on some cylinders get better performance, thus people sometimes carefully choose the position of critical trees by placing them on specific filesystems on specific volumes.

In modern disks the sector layout is hidden. The fastest sectors may be at the beginning of the disk, the end or striped throughout. This is specific to the design of the HDD and it is no longer possible to tell short of doing timing tests[1]. My recommendation is to ignore differences in sector speeds.

[1] I'd love to hear if anyone has found a method but I can't see how they could get through the h/w abstraction.

LVM won't theoritically guarantee the physical position of the logical volumes anyway. And I'll need it if I do any partitioning.

So now it is abstracted (at least) twice :)

* Swap special-case

My setup will still have its little dedicated swap space, it's pretty obvious how this can optimize it (no underlying filesystem, maybe on another unsafe but faster RAID0 volume, fast dm-crypt encryption, ...)

Under Linux 2.6 kernels a swap file is as efficient as a swap partition. The only real advantage of a swap partition is to allow suspend to disk (on a laptop).

There are however some neat dymanic swap allocation projects out there that would help me not lose these gigabytes I never seem to be using (at all). I

I wouldn't touch these if they in any way impacted performance. Disk is cheap. Give yourself 2GB swap.

figured, with all this RAM I could think of the swapping space as a mere rescue space to prevent OOM rampages - and nothing else. In *my* case, even buffers and cached pages never get to be pushed on disk after weeks without

Ah but they are. Cache pages may be clean or dirty. Your disk cache may be full of clean cache pages, which is just fine.

rebooting. I'm just OK with my three gigs. The 1:1 mem:swap rule has got to be wasting space here, hasn't it?

Absolutely.  This page has my thoughts on this topic:


Thanks in advance for your help. I hope I could make you think twice about it too or maybe provide people with other needs with a little checklist to better design their layout.

Thanks for the great checklist.



Email: robert@timetraveller.org
IRC: Solver
Web: http://www.practicalsysadmin.com
I tried to change the world but they had a no-return policy

Reply to: