While I realize this is a religious issue and everyone has their own idea I think it's a particularly bad idea to as Karsten's page says make the basic recommendation for 6 partitions. If you read his page it looks like he's pretty strong on /boot and swap partitions as well. So yes I think a basic recommendation for 8 partitions is insane. You just end up with a labor intensive fragile system that requires a substantial amount of specialized knowledge to create and is rather sensitive to any future changes to the system.
First let me say that for any particular use that a there can be a small gain by using small partitions. Say putting of of the 8 partitions on the fastest part of the disk, or skipping a journal, mounting read only, etc. No argument for a particular metric you can make a difference. The flip side is that it requires specialized knowledge (quick, what's the optimal /var, /usr, /usr/local for a particular distribution? ) that's often basically unknowable. Can you really guess how many packages you are going to install in /usr/local in the next 3 years? Can you really afford to periodically "spend a day rationalizing your partition sizes?". What actual real world benefit justifies losing a man day periodically? Did you notice that even after the "day of rationalization" he still had to make symlinks between partitions to handle overflow? Sure when Unix boxes were hugely expensive, CPU cycles are precious commodities, OS's were primitive, disks hugely expensive, security was terrible (plain text passwords, buffer overflows, no selinux/apparmor, commonly all network services ran as root, rare use of jails/chroot, no stack protection, no NX bit, etc. etc. etc.) that sysadmin time was cheap in comparison to the gains. Even small gains were worth spending man hours on. These days disk are cheap, ram is cheap, security is way better, buffer overflows are getting rarer, network services are usually setup pretty reasonably by default. Sure mounting as noexec can help... unless of course apparmor or selinux already made a profile dramatically more restrictive already. So you could spend time tuning which flags for each of the 8 partitions.... of course you might well make a mistake like Karsten did and leave exec on for /tmp. So what use case adds security by using noexec if /tmp is world readable and mounted with exec? Using 8 partitions causes more complexity requires more optimization in a never ending circle. Oh the humanity... just imagine how much space you would save by deleting those unneeded hugely inefficient journals. Never mind it's the 8 partitions themselves that creates the need for 7 journals. Ignore that various distributions, kernel developers, and the author claim that it helps availability, data integrity, and speed. Sure journals are sometimes slower and they actually take some small amount of disk space.... but if they save even a single user file that would have been lost with EXT2 that it's worth it. IMO the distributions do a pretty good job of the defaults, (like using just a few partitions) you really shouldn't ignore their defaults without a good reason. Sure there are special cases that justify all kinds of weird configurations.... I wouldn't start with 8 partitions as a default basic recommendation. If you are really I/O limited there's many things to tune before you start looking at partition sizes. The page also makes a few mentioned of ro, seems a bit silly. So if only root can write to /usr, and root can remount rw what are you protection from? Sure you might prevent a silly user mistake... a tangible benefit..... unless of course it causes the sysadmin to delay patching because of the extra hoops of remount instead of the simple apt-get update/upgrade (or clicking on a icon if you like GUIs). A single delayed patch might well cost more than you could ever save with such optimizations 100x over. Sure things like putting /tmp on a ram disk sounds like a great idea, especially if you don't really understand the buffer cache. It should be really fast right, after all ram is fast... right? Well as it turns out the buffer cache works really well on anything that would fit in a ramdisk. Additionally when you aren't I/O intensive that ram could be useful elsewhere. Even if it was 1000x faster I suspect most workloads are not I/O limited by /tmp anyways. Not to mention having /tmp survive a reboot might just save you 10 minutes retyping the document you are working on before a power outage. Would it really be so awful if I could cd /tmp and untar the linux kernel source tree so I could look at it and then not have to worry about forgetting to delete it? With Karsten's recommended config you would start the download then after waiting realize that /tmp is full. Sure you could cd ~, then retry. Of course then as you get distracted after pouring over the source now you have 400MB (assuming you didn't build it) wasted in your home directory. So sure when a partition fills on an 8 partition machine there is less disruption.... of course you are going to have quite a few more of them. Not to mention the effort to get into the 8 partition state... and the effort to keep all 8 partitions properly balanced. So basically in a wide variety of uses I think the suggestions on that page are a silly waste of time that makes a system much more fragile. The labor intensive nature basically can't be justified by the small gains offered. The gains mentioned are so specific to a use pattern that they appeal to the engineer/programm/admin that loves to tinker and optimize and on their face seem plausible. Two disks can swap twice as fast as one... right? Well of course.... except for those nasty real life details. Say that your system is *gasp* actually using I/O system at the same time it's generating all the memory pressure that causes the swapping. So suddenly those disk head that would have happily stayed exactly where you wanted it is now disappearing for 1/60th of a second to go load a block for you. Which of course you could improve some by juggling the partitions close to the swap next time you have a day to kill.... unless of you have the moxie to actually do something I/O intensive on another partition. Should I really closely watch all 7 partitions? God forbid apt-get cache to many packages, I really should go in there and clean up all those packages.... which of course cost me man hours... and again if I end up reinstalling the ones I just cleaned up. >> * Crude partition based backups > > You'd rather provide an explicit and laundry list of directories (that > must then be maintained), when just adding "-x" (don't cross filesystem > boundaries) to your rsync command solves that problem entirely? Really? Er, yes. Why would I want to tie what I backup to a partition boundary? Doubly so for a system with 8 partitions. In Karsten's config do you think it's a bonus that if you backup /usr/local that /usr/local/data doesn't get backed up? If I'm happy to reinstall from DVD/CD/PXE if necessary (after all a disk death is rare enough I'm likely to want an upgrade anyways) why not let me backup /etc, /home, and /opt (or /usr/local if you prefer) instead of, er, /dev/hda2, /dev/sda5, /dev/hda7, and /dev/hda3 (which gets more than /etc). In any case, by crude partition based backups I meant things like dump restore vs the current rather elegant solutions that add things like deplication, support of efficient storage and network usage via librsync, easy to use configuration system, *gasp* user friendly GUIs, etc. Not to mention that the more current file based (not partition based) backup systems allow backing up to a much wider range of targets. Sure CD, DVD.. much like the tapes of old, but also using rsync, or even various network/cloud services like s3 or rsync.net. Thus it becomes much easier to get replicated offsite backups cheaply. _______________________________________________ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
