[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-fs
Subject:    Re: [FiST] Re: Overlayfs for FiST?
From:       Erez Zadok <ezk () cs ! sunysb ! edu>
Date:       2003-04-25 20:11:46
Message-ID: 200304252011.h3PKBkUQ011637 () agora ! fsl ! cs ! sunysb ! edu
[Download RAW message or body]

In message <20030424033353.GA4596@afields.ca>, Allan Fields writes:
> Hi,
> 
> In my opinion...	(O.K. I'll take a dive into this.)
> 
> This all sounds a lot like (Free)BSD's unionfs.  I have tried using
> unionfs for various tasks, including some related to security.  It

Functionally, yes.  But IMHO, the fbsd unionfs made the mistake of using a
single stack design for the union.  It doesn't scale well, and it gives you
a limited ability to control the unioning-related algorithms: you have an
implied linear search list.

I think that a true fan-out stacking template will be a lot more flexible: a
file system ->method() would be able to _directly_ access any of the nodes
immediately below it, in any order.  Once such an infrastructure is in
place, you find that the various file systems that can be created are
permutations on a number of policies that one might decide on:

- if on error at branch N you move to search branch N+1, you got yourself a
  failover file system.

- if upon lookup you select one of N branches by a given algorithm (say,
  random) you get a load-balancing file system.

- if upon file-system-modifying operations you schedule the event to proceed
  onto all N branches, you have a replication file system.

- if, to process certain file system methods (esp. readdir), you invoke it
  on all N branches, you get a unioning file system.

The beauty of this is that I believe the fan-out template infrastructure can
remain pretty fixed (modulo getting it to work in the first place :-) And
the types of file systems will be determined by (implementation) policy
decisions, not necessarily hard-coded into the fan-out template.

Erez.

[prev in list] [next in list] [prev in thread] [next in thread]