On Friday 02 January 2009 12:17, Martin Steigerwald wrote: > Am Mittwoch 31 Dezember 2008 schrieb Justin P. Mattock: > > I guess this is what is confusing to me: > > atomic commit, btree-based versioning. > > Ah, the buzz words. ;) > > The tux3 mailing list contains quite some design notes about these > concepts. I think others can give better answers about these concepts - I > think I understood what it is for, not the implementation details. But > basically "atomic commit" is a strategy to have the filesystem always in > a consistent state Right. Atomic commit is a term that came from the database world and was first applied to filesystems in an LKML message from Victor Yodaiken back in 1998 as I dimly recall, and I adopted it to describe the tree ased atomic update strategy I was developing for Tux2 at the time. Tux3 uses a new logging variant that is supposed to avoid the write-twice behaviour of journalling and the recursive copy behavior of WAFL, ZFS and Btrfs, so should be pretty good at synchronous write loads and generally reduce write traffic. > and btree-based versioning allows to keep different > versions of a file / directory around. And unlike other filesystem tux3 > has this per inode and not for the complete filesystem. At least if I > understand correctly. You do. "Btree-based" and "versioning" are separate buzzwords. Tux3 is a btree of btrees: the inode table is a btree, containing files that are btrees. It was conceived to demonstrate a new method of versioning files that puts the versioning information at the btree leaves instead of having multiple independently rooted trees sharing subtrees: Versioned pointers: a new method of representing snapshots http://lwn.net/Articles/288896/ This approach lends itself to per-object versioning: each data pointer and each inode attribute has its own version label. Making it work per file and even per directory is a matter of clever mapping tricks to turn global version numbers into per pointer version numbers. But note that versioning support is still just a nice demo: the focus has shifted to Tux3 as general purpose filesystem, with versioning seen as a feature to be integrated after the basic Ext3-class functionality is solid and reviewed. > But at least it should clear that tux3 is a filesystem and not a video > game ;). It's kind of like a video game where you sneak through IRC channels trying to frag bugs with your BFG. Regards, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
