On Mon, 26 Sep 2011, Brett Glass wrote:
At 12:03 PM 9/26/2011, Benjamin Kaduk wrote:
On Mon, 26 Sep 2011, John Baldwin wrote:
I can't speak to the "one-big-fs" bit (there was another thread long ago
about
that). However, as to the partitioning bit, bsdinstall is defaulting to
using
The question of how to layout and split filesystems was discussed at the
filesystems working group of the devsummit at BSDCan this may.
(http://wiki.freebsd.org/201105DevSummit/FileSystems down to "Filesystem
Layout" near the bottom) Though "one big root" did not garner a huge
amount of support, neither were there particularly compelling arguments
against it (if I remember correctly). It's certainly easier to write an
autopartitioner for, so I don't really blame Nathan for having chosen it
initially.
My personal preference would be to place portions of the directory tree which
contain critical configuration information and are not written in normal use
-- e.g. /etc and /boot -- in one or more separate partitions. This would make
it possible to mount them read-only unless the system configuration was being
changed, new software was being installed, or a new kernel was being
generated. This would protect them not only from malicious tampering but also
from being scrambled by buggy userland software. And since it would not be
written during normal operation, it would survive 100% intact even if
journaling and/or serialization of metadata updates (e.g. softupdates) were
to fail.
Unfortunately, due to past history, /usr is mixed-use. It normally contains
both configuration information -- e.g. /usr/local/etc -- and more volatile
data such as users' home directories. This prevents /usr/local/etc, which
also contains mission-critical configuration information, from being
protected if you just protect /. Some proprietary Unices have fixed this
historical flaw in the traditional hierarchy by moving /usr/local/etc to
another location and them symlinking it back to where seasoned administrators
expect it to be, thus honoring POLA. The three open source, old school BSDs
(Free, Net, Open) have not done this to date, but it's something that should
be considered in the long run. It would certainly make the creation of
embedded systems easier, as well as enhancing security in multi-user systems!
If I wrote an installer, my preference would be to have it create one
partition that contained critical configuration information and software (and
could be mounted read-only) and one that contained the rest of the usual
directory tree (and could be mounted read-write). It could do the symlinking
trick mentioned above to bring parts of /usr over to the read-only
administrative partition. The only cleanup task that would remain would be to
make sure that no ports were configured to place their logs, pid files, etc.
in directories such as /usr/local/etc. (Most already do not.)
There was also general sentiment that the rise of ZFS would allow just
this sort of fine-grained partitioning, which is a huge advantage of its
ability to create datasets on the fly. This perception that ZFS is most
of the future probably contributed to the lack of strong opinions
regarding the default UFS partition scheme.
-Ben Kaduk
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
