Re: Hammer FS: imposing a size limit on PFS?

[Bill Hacker <wbh@xxxxxxxxxxxxx>]

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