Quoting Bill Broadley ([email protected]): > While this is a rather personal preference, many of the ideas that led to the > 5-6 partitions as standard operating procedure are gone. Some of those ideas > that are no longer true: > * file systems that didn't scale to large sizes well
I can't find anywhere in Karsten's document where he says anything about Linux filesystem scaling problems, let alone those being a factor in partitioning. Can you please point it out? (It's possible you weren't thinking of Karsten's page, in that particular, but were just citing obsolete concerns generally.) > * lack of journals that lead to long fsck times Only if you mount rw by default, and only on filesystems of significant size and complexity. Consider /usr on a server where that is kept mounted read-only except during installation/removal of packages. Why have the overhead of a journal? Consider also a /tmp filesystem where you want high performance, and for some reason don't want to use tmpfs. (Maybe you prefer /tmp to be persistent between reboots.) Again, why do you want the overhead of a journal on _/tmp_? The example of /usr will not lead to long fsck times because it's synced at all times (except rare occasions when you remount it rw for package operations). The example of /tmp doesn't lead to long fsck times because, well, it's /tmp -- isn't huge, doesn't have large amounts of stuff in it. > * Rare/expensive unix systems that ran tons of services and had > shells for users. Which required protecting services from users > and vice versa. Actually, protecting the system from misbehaving processes, and the system from the sysadmin, and the system from poor recoverability, are rather more the point. So, for example, the more the root filesystem is isolated by having non-essential things be in separate filessytems, the more likely you will be able to mount / at boot time despite problems that may have arisen in, say, /usr or /var. There's a really good reason why system recovery/restore/repair tools are all in /bin and /sbin: That's so they'll not be unavailable if /usr is temporarily hosed and cannot be mounted. Why else do you think those and /usr/bin / /usr/sbin aren't simply merged for simplicity's sake? > * 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? > * The lack of online resizing and logical volumes Oddly, some of us don't like LVM/LVM2 on account of the avoidable complexity those add to a system's architecture, and would rather not trust our files to online resizing. Ironically for your comment (above), Karsten _does_ mention LVM in a laudatory fashion, as an option -- though he doesn't employ it in his examples. > * Multiple swap partitions because of limitations on swap size partitions. Multiple swap partitions per _spindle_, as mentioned in part of Karsten's page, is indeed old hat. On the other hand, having multiple swap partitions of the one-per-spindle variety is just common sense, as it improves performance considerably. > * Horrifyingly poor security defaults Can you be a few orders of magnitude more specific? Defaults of noexec or nosuid on some portions of the tree, e.g., were of course not intended to deter anyone who's already cracked root, but could prevent both canned attacks from succeeding (if, say, you've been caught napping by yet another developed PHP app hole) and can help avoid sysadmin mishap. Anyhow, Karsten's document wasn't about tips to deal with security issues. Are you asserting that his recommended partitioning strategy _hurts_ security? If so, in which particulars? > * ram was so expensive you usually didn't have enough to reasonably buffer Oddly enough, my server had a mere 256 MB until this April, not because RAM was expensive, but rather because I didn't want to sink _any_ more money into a box that was going away, and the migration to the replacement box kept being deferred. But anyway, regardless of how much RAM I have on my servers (and the upgrade to the newer machine with 1.5 GB was a big relief, thanks), it's a point of pride not to waste it. I have work for it to do. > * file systems that often resulted in poor locality, so partitions were > used to keep the head more local when processing a news spool or the like. Guess what? NFS hasn't gone away. Nor SMB. > * Installing 2 or more OSs on a single machine was rare. This seems irrelevant: Although Karsten's page doesn't address that case explicitly, I can't see that his recommendations wouldn't apply there, pretty much the same. Anyway, dealing with multiple OSes per machine through partitioning seems quaint, to me, since the development of good VM technology. My experience was always that people thinking they were going to boot back and forth between OSes were kidding themselves: They ended up, over time, staying almost entirely in one of the OSes, because shutting down and rebooting was too disruptive. On the other hand, having, say, a VMware window on your corporate Linux laptop running so you can use MS-Outlook for the corporate mail/calendar system, and MSIE for some of the less well-designed (e.g., ActiveX-based) intranet sites, is eminently practical. > * the lack of device, pty, /proc, tmpfs and other related virtual or temporary > filesystems that help offload the duties and security privs required > of a filesystem. Um, /proc is mentioned. But all of those are irrelevant to _partitioning_, anyway. Karsten's page is about partitioning strategy. Anyhow, I'd feel a prize chump if I had my server set up as single-filesystem plus swap on quite a few grounds, including performance: Being able to put the swap in the middle of the spindle, and the most-visited portions of the file tree on either side, is a huge win for keeping average seek time low. I'd be bloody incompetent if I _didn't_ do that. _______________________________________________ vox-tech mailing list [email protected] http://lists.lugod.org/mailman/listinfo/vox-tech
