DragonFly users List (threaded) for 2009-02
Re: Hammer FS: imposing a size limit on PFS?
Matthew Dillon wrote:
Our installer support for HAMMER isn't advanced enough yet. What we
really want is a UFS /boot, swap, and then a HAMMER root that covers
I would (and have) taken that a step farther.
'once upon a time'
'/usr' was not part of the core essential. It really was 'userland'
Long since, far too many of the *system's* 'needful things' in the way
of binary and libs migrated there. Recall my push to get a decent
static-compiled editor into the root partition so we could at least edit
a FUBAR'ed /etc/rc.conf w/o having to manually mount a (potentially
'These days' one gains a bit of respect for NetBSD / OpenBSD plutting
things into /usr/pkg rather than /usr/local, if only to keep them out of
the way of 'real userland' - and even looks yearningly at Linux use of
Reality is that a 'healthy' system needs '/usr' (libs and binaries) and
'/var' (pidfiles, logs, and spools) to be mounted more or less 'at all
Ergo, one wants to push anything that really IS userland and user-app,
or 'production use' specific out into bespoke mounts.
True whether the box is to be used for familiarization, learning,
experimenting, OR 'production'.
And regardless of fs chosen....
The idea with HAMMER is you just create one big filesystem and use the
PFS functionality to break it up into separate management domains.
Currently a size limit may not be placed on a PFS.
I want my 'core' to be as damage-resistant as can be. So long as it IS
such, and can boot and mount rapidly and respond to console - better yet
ssh from afar - I have the wherewithal to manage, repair, or even nuke
and reinstall - all the rest.
Ergo, absent a 'netboot' or flash/USB boot - I submit:
'Best Current Practice';
Minimum with one device:
- A modest 'slice' for the OS install, partioned and UFS, OR 'shared'
- One or more SEPARATE partons if not SLICES for hammer-as-bulk storage,
application support, etc.
IOW - not entangled in any way with '/usr', '/var'. You can wipe it and
start over over-the-wire, as the 'core' is isolated.
Better yet - multiple devices, where second and subsequent devices where
hammer owns the entire device.
If we cannot isolate and protect the 'core' within a hammer PFS, then we
should not put it into the same PFS 'family' and open it to overflow or
JM-scar-tissue's-2CW - but we have found this 'safe' from CP/M 1.X onward.
Logs and spool aside, 'core' has slow or no rate of change.