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:
http://www.timetraveller.org/talks/backup_talk.pdf
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:
http://practicalsysadmin.com/wiki/index.php/Swap_space
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.
Cheers,
Rob
--
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: