Daniel Phillips wrote: > 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 > > The game that came to mind when I first heard of tux3(I had to google a bit to find the name) was tux racer. :^) quick question: what is the state for security file labeling for SELinux on this filesystem?
regards; Justin P. Mattock _______________________________________________ Tux3 mailing list [email protected] http://mailman.tux3.org/cgi-bin/mailman/listinfo/tux3
