Date: Fri, 9 Nov 2012 23:01:30 -0500 (EST)
From: Mouse <mo...@rodents-montreal.org>
Message-ID: <201211100401.xaa23...@sparkle.rodents-montreal.org>
| To be fair, sometimes that's a right answer. Loosely put, it's a right
| answer whenever running out of space on any filesystem is equally bad
| and it's fine for that to mean running out of space on all.
If uses of space allocation were the only concern, that would be fine.
But it isn't - file systems are real first class objects in unix,
and while for some uses it is certainly true that a single filesys
containing everything is all that is needed, for others, even with
just a single user, it isn't.
Mount options, nfs exportability (and more) are all per-filesystem
attributes, and being able to vary those can be important.
For example, I do all my pkgsrc building (using pkg_comp) in a
filesystem I mount -o async - that filesystem is excluded from the
normal startup up fsck & mount, instead I have a script that is
run that attempts a fsck (fsck -p), if that succeeds, then fine,
the filesystem is just mounted (again -o async). If the fsck
indicates problems (which it almost certainly will after an unclean
shutdown, then the script just does a newfs, and then mounts).
Since pkg building does a lot of file & directory creation, and then
removing, using an async mount makes it all go a lot faster (if only
there was just as easy a way to speed up gcc...)
In any case, for the entropy-file, the point is not whether one of these
styles is better than the other, but that the system should work
(fully) with either strategy, which means the entropy file should be
somewhere that the boot code can find it (if it is to remain needed
before the system is running).
kre
