Quoting Bill Broadley (b...@cse.ucdavis.edu): > Er, right in the bold 3rd paragraph he mentions /boot, he mentioned in in the > why partition paragraph... twice. In fact he mentioned /boot as 4th most > important partition ahead of /tmp, /var, /home, and /usr/local. He mentioned > /boot a dozen or so times, and it's in his examples that he lists. > > So what is factually incorrect again?
It's not in his basic recommendation, nor his "How many partitions" list, nor his desktop recommendation. The only example he has it in is "A suggested laptop/desktop configuration" at the end. You're characterisation of "strong on /boot" is obviously wrong -- as will be apparent to anyone who actually reads the page. But, you know, Karsten has already done his best to set you straight. Oddly, there are scenarios where a separate /boot still makes some sense, even on modern hardware where the 1024 logical cylinder BIOS booting limit no longer applies -- but for the most part, that is (as I already said) indeed obsolete. Partitioning needs emerge from the particular situations of specific systems, always. Attentive reading of Karsten's page would have told you he was saying that. If not, his post _here_ calling your attention to that fact should have. ;-> > > And yet a trained monkey can do "df -h" on a similar installed > > system, to guesstimate the target requirement for the system's > > projected life. > > Sure, if you have a similar system like that in production, even then > it seems like a fair number of mistakes are made, like you are Karsten > occasional reinstalls and use the use. And yet, this proves in practice to almost never be a problem. When starting out, you don't get fancy, you observe where space is needed and how much, and it becomes pretty obvious. Observe, learn, apply knowledge gained. This really isn't difficult. > IMO as far as maintenance, robustness, and > sustainability are concerned that many (>= 6) are worse than few (<=4) > partitions are having to resort to ln -s is particularly evil, ruins > performance and makes it harder to maintain the machine. The 11 years of 24x7 service from my server's hard drives (the pair that were killed eventually by a PG&E power spike, this past April) seem incompatible with your assertion about maintenance, robustness, and sustainability. Just as one data point that is handiest to mind. Obviously, you move part of a filesystem and symlink it only as a last-resort move, and you do _not_ do that for performance-sensitive moves, as fortunately most would not be. What you would generally eventually then do, in that last-resort scenario, is rsync-over-ssh the data off to somewhere across a network for safekeeping, blow away the filesystems in question, remake them at the desired size, remount, rsync the data back. That's how we do it in production. _______________________________________________ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech
