2007/7/17, Eric Y. Kow <[EMAIL PROTECTED]>:
> 2) HalFS and other "embedded filesystems" allows modify and delete > very freely, but the creation of new files has a great issue: usually > those filesystems need a "fixed size" storage. Even when a filesystem > can grow, it usually can't "shrink" very easily. I haven't had a look at HalFS. Do you know this for a fact, or do you think it might be worth consulting the folks at Galois about the matter of shrinkability?
I'm not 100% sure, but looking at the documentation on their website, some past comments on this mailing list, and my general knowledge about filesystems, this seems pretty probable. I'll ask anyway Galois about it, just to be certain and to make it a "fact" on which we can base our future discussions. Out of curiosity, how does one encode something filesystem-like in
something database-like? Do you do something stupid and simple like associating paths with whatevers "foo/bar/baz" => whatever1 "foo/bar/baz/quux" => whatever2 And write a bunch of wrapper code around it (if you delete 'foo/bar/baz' go hunt after everything that starts with 'foo/bar/baz/' and delete it too)?
I've not yet decided how to approach the problem in detail, but the "stupid and simple" solution is very crude :). I don't know how many fancy things Darcs pristine needs (symbolic links, permissions and so on), but at very least I'd separate the "storage" part of the filesystem (the one with file -> contents) from the hierarchical/metadata structure (object -> type (file / dir) -> permissions -> ... -> parent). To delete a tree, you go by recursion (that's how simple filesystems do it anyway). When you delete a file from the hierarchical structure, you delete its file too. There are many more "clever" ways to make a filesystem, but using a db storage as a backend instead of raw storage, we have the luxury of not dealing with one of the primary concerns of traditional filesystems: extents allocation (i.e. tracking the fragments of each file). By the way, I've omitted an important thing from the last mail: sqlite supports incremental access to BLOBs, so it's possible to say "read/write the bytes from 100 to 1000 of this 1 gb file", like a "true" filesystem. Anyway, I was thinking about implementing a little "filesystem library" in Haskell using sqlite (maybe some other project will find it useful, and help to mantain it), with some common I/O commands, see how well it performs, and then (if all goes well) integrate it in darcs. It won't surely perform nearly as well as a filesystem, but I don't think that pristine copy performance is the real showstopper in darcs performance; its transactional behaviour and consistency are far more important. Salvatore
_______________________________________________ darcs-devel mailing list darcs-devel@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-devel
