From mboxrd@z Thu Jan 1 00:00:00 1970 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-reply-to: Your message of "Fri, 18 May 2012 23:13:54 +0200." <9F03A819-F521-407C-A6BD-13A04A3AC877@lsub.org> References: <9F03A819-F521-407C-A6BD-13A04A3AC877@lsub.org> Date: Fri, 18 May 2012 15:22:57 -0700 From: Bakul Shah Message-Id: <20120518222257.386CFB827@mail.bitblocks.com> Subject: Re: [9fans] The creepy WORM. (was: Re: Thinkpad T61 Installation Experience) Topicbox-Message-UUID: 9266a626-ead7-11e9-9d60-3106f5b1d025 On Fri, 18 May 2012 23:13:54 +0200 Nemo 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!