[Noisebridge-discuss] M.A.I.D. was: Freespace / slackspace file system

[Andy Isaacson]

On Fri, Sep 25, 2009 at 01:06:30AM -0700, Sai Emrys wrote:
> Yep. Ideally your daemon would have some sort of hook into the file
> system so it could spy on its allocations, compare those to its own
> table of "soft-allocated" space, and further replicate stuff that
> falls below some replication threshold.

Having the cover filesystem and the hidden filesystem mounted (and
writing!) simultaneously is going to be challenging.  If ssfs starts
writing to a formerly-slack block at the same time the ext3 filesystem
allocates the block and starts writing to it, you're likely to corrupt
the ext3 datablock.  You want to avoid breaking the host filesystem,
which is a bit challenging without modifying the host filesystem code.
You'll probably have to do some modification to the host fs code
(possibly just by having a hook loaded when you install the ssfs module)
but you don't want any of the modified metadata to land on disk since
that might give away that you've got something in your slack space.

> If not, it'd have to either scan occasionally (which is slow and not
> as quickly reactive) or just give up and be willing for stuff to
> disappear.
> 
> I think of it like memcache in that regard - you put stuff in, and if
> it's there it's fastish, but if it's not there (any more?) then you

I like this analogy a lot, it makes ssfs much more feasible I think.
Treating it as a local cache of data that has another canonical location
is much more feasible than providing a POSIX-style guarantee of
presence.  Even if it's not feasible to implement a "real filesystem"
that you can mount, cat, vi, etc, it could be interesting to store data
on it with a put/get paradigm (similar to AWS S3).

-andy