Re: [9fans] The creepy WORM. (was: Re: Thinkpad T61 Installation Experience)

[Bakul Shah <bakul@bitblocks.com>]

On Sat, 19 May 2012 00:45:58 +0200 Francisco J Ballesteros <nemo@lsub.org>  wrote:

> > Just curious.
> > If the tree doesn't fit in memory, how do you decide who to
> > kick out? LRU? Sounds much like a cache fs. What does it buy
> > you over existing cache filesystems? Speaking more generally,
> > not just in the plan9 context.
>
> lru for clean blocks. but you really have the tree you use in memory, all if
> it fits.  what it buys is simplicity, thus reliability, and speed.
> instead of a single program doing everything, you have several trying to use
> their memory and to avoid copying blocks in the main server.
> plus, it's going to be modified to exploit the upcoming nix zero copy framework.

This last point is more or less independent of the FS (as long
as an io buffer is page aligned and io count is a multiple of
page size).

> it's not cow. you reuse the memory of a frozen block instead of copying.
> you just melt it and reuse it.

> all this is in memory. cow happens only on the disk, but you don't wait for that.
> that's the main difference wrt others.

How often would you flush to disk? You still need to worry about the order
of writing metadata.

> >>          When the disk gets full, all reachable blocks are marked and
> >>          all other blocks are considered available for growing the
> >>          log (this is a description of semantics, not of the imple-
> >>          mentation). Thus, the log is circular but jumps to the next
> >>          available block each time it grows.  If, after the mark pro-
> >>          cess, the disk is still full, the file system becomes read
> >>          only but for removing files.
> >
> > Why does circularity matter? It would make more sense to allocate
> > new blocks for a given file near its existing blocks regardless of
> > writing order.
>
> for simplicity, I removed most of the fanciest things I had before in place in
> previous versions that could be a source of bugs. there are no ref. counters,
> for example. it's designed to operate on
> main memory, and it seems it does well even though the disk algorithms are
> naive.

You do have to keep track of free disk blocks. On disk. So a linked list
would require you visit every freed block.

> > Why not just use venti or some existing FS underneath than
> > come up with a new disk format?
>
> to avoid complexity, latency, and bugs.

I think an incore FS the easy case but you will have to face
the issues of corner/boundary cases, various error conditions
and efficiency when dealing with real disks. These things are
what introduce complexity and bugs. "Soft updates" in FFS took
quite a while shake out bugs.  zfs took a long time.  Hammer
fs of DragonFly took a while. Pretty much every FS design has
taken a while to be rock solid.  Far longer than the original
estimates of the designers I think.

> that was the motivation, exploiting large main memories and keeping things
> simple and reliable. Time will tell if we managed to achieve that or not :)

Ah. I have been looking at SBCs with memories in the 128MB to
512MB range! Can't afford an incore FS!

But even if there is gigabytes of memory why would I want to
dedicate a lot of it to a filesystem? Most of the FS data is
going to be "cold" most of the time. When you suddenly need
lots of memory for some memory intensive computation, it may
be too late to evacuate the memory of your FS data. But
memory is just a file cache, this data can be thrown away any
time if you need more space.  And by making sure the cache
holds a bounded amount of dirty data, you lose no more than
that amount of data in case of a crash.

> sorry I wrote in Sioux this time. its been a long day here :)

Thanks for taking the time. Always nice to see yet another
attempt at getting this right :-)