Re: the 'why' of pseudofs

[Michael Neumann <mneumann@xxxxxxxx>]

Am Wed, 18 Feb 2009 05:25:10 +0800
schrieb Bill Hacker <wbh@conducive.org>:

> Folks,
> 
> Google was no help, and I have only the last 54,000 or so of the 
> DragonFlyBSD newsgroup messages to hand on on the PowerBook, wherein
> a message-body search on pfs, PFS, pseudofs turned up only about 240
> or so messages, or Mark One eyeball processing..
> 
> That now done, I find:
> 
> Several of these cover conception, gestation, birth, and education  - 
> the 'what' or 'how' of pseudofs / PFS, so to speak.
> 
> ONE of which lists the pro /con vs PFS_NOT. And that one not really 
> hard-edged.
> 
> NONE of which tell me with any degree of absolute-ish-ness, if you
> will..
> 
> ... that one cannot, or even 'should not' run a HAMMER fs *without*
> PFS mounts.
> 
> ... or nullfs mounts.
> 
> or even .... without softlinks.  Persih the htought. Or the
> confusion...
> 
> At all.
> 
> EG: 'none of the above'.
> 
> Mind - I see the rationale - even necessity - for their use in more
> than a few circumstances.
> 
> But I cannot seem to find the prohibitions against their 'non-use'.
> 
> What do you suppose breaks if I do not apply these in an initial
> setup, but rather leave them until specific needs arise, such as
> volume expansion, export, or mirroring?
> 
> I have in mind small drive(s) for /, /usr, /var/, /tmp, /home
> - perhaps not even hammerfs, those. Nothing there that was ever
> overly hard to backup, restore, of JF replace. My mailstore, for
> exampel, has never lived in any of those. Nor web pages. Nor
> Databases.
> 
> It is on separate, much larger, drive(s) for /data, /mail, /web, /pub 
> and such - where 'mission critical' clients live and play.
> 
> UFS(1), / FFS(1)  - not UFS2/FFS2 has made for less hassle when
> hardware goes pear-shaped or OS migration is afoot.
> 
> Enter (BF)HAMMER
> 
> But what concept am I missing here? Nice-to-have? Or absolute
> necessity?

PFS is the smallest unit of mirroring, and the unit to which you can
apply specific retainment policies. For example while you do not want
to retain much history for /tmp, you might want to do so for /home.
When it comes to mirroring, you clearly do not want to mirror changes to
PFS /tmp, while you want to mirror changes to PFS /home. If everything
would lie on a single huge filesystem "/", we could not decide what to
mirror and what not. That's the major design decision. 

You might ask, why not simply specify which directories to mirror 
and which to leave out (without considering PFS)? The issue here is,
that, AFAIK, mirroring works on a very low level, where only inode
numbers are available and not full pathnames, so something like:
  
  tar -cvzf /tmp/backup.tgz --reject="/tmp;/var/tmp"

would not work, or would be slow.

Another issue is locality. Metadata from one PFS lies more close
together and as such is faster to iterate.

Regards,

  Michael