Hammer FS: imposing a size limit on PFS?

Bill Hacker wbh at conducive.org
Wed Feb 25 19:02:10 PST 2009


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
    everything else.
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 
damaged) /usr.

'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 
'/opt'

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 
costs'.

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.
						-Matt
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' 
with hammer.

- 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 
damage.

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.

Bill






More information about the Users mailing list