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

[Bakul Shah <bakul@bitblocks.com>]

On Fri, 18 May 2012 23:13:54 +0200 Nemo <nemo@lsub.org>  wrote:
>           Creepy is a prototype file server for Nix. It maintains a
>           mutable file tree with unix semantics, kept in main memory,
>           served through 9P, see intro(5), and through IX.

Creepy? It has become a "creepy" word now!

>           Creepy/9pix is the main file server program. It serves a
>           file tree through 9P and IX.  The tree kept in memory is
>           mutable. But frozen versions of the tree are written to
>           disk, both upon request and also on a periodic basis, to
>           survive power outages and other problems, and to be able to
>           operate on trees that do not fit on main memory.  The
>           tree(s) stored on disk are frozen and cannot be changed once
>           written.

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.


>           The disk is organized as a log of blocks. When a new version
>           of the tree must be written to disk, all blocks that changed
>           are given disk addresses and are appended to the log. Once
>           written, they are frozen.  If new changes are made to the
>           tree, blocks are melted and forget their previous addresses:
>           each time they are written again, they are assigned new
>           ones.

I don't understand use of the words frozen & melted here.  How
is this different from how things work now? Something worse
than what venti or zfs do, which is to leave the old blocks
alone and allocate new space for new blocks.

>           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.

Why not just use venti or some existing FS underneath than
come up with a new disk format?

Sounds like a fun project but it would be nice to see the
rationale for it.

Thanks!