Am Mittwoch 31 Dezember 2008 schrieb Justin P. Mattock: > Martin Steigerwald wrote: > > Am Mittwoch 31 Dezember 2008 schrieb Justin P. Mattock: > >> Daniel Phillips wrote: > >>> On Tuesday 30 December 2008 23:34, sniper wrote: > >>>> Great, I have mounted tux3 filesystem under UML with stuffs in > >>>> this mail, but I still can't debug it with gdb. Anyone gives me > >>>> suggestion? > >>> > >>> You just have to give a "cont" command a bunch of times and you > >>> will eventually get to a command prompt. The reason for this is, > >>> uml uses the segfault interrupt as part of its machine simulation, > >>> and there is no exsiting way for uml and gdb to communicate in such > >>> a way that uml can recognize that the interrupt came from its own > >>> code and filter it. > > > > [...] > > > >> Hmm.. seems like a redundancy; > >> Anyways I looked at you're site, but am still > >> confused at what tux3 is: what is tux3? > >> > >> (at first I thought it was a video game, but was wrong); > >> can I use tux3 to secure a linux system or is it for > >> something else? > > > > Hmmm, I thought > > > > --------------------------------------------------------------------- > > Tux3 is a write-anywhere, atomic commit, btree-based versioning > > filesystem. It is the spiritual and moral successor of Tux2, the most > > famous filesystem that was never released. The main purpose of Tux3 > > is to embody Daniel Phillips's new ideas on storage data versioning. > > The secondary goal is to provide a more efficient snapshotting and > > replication method for the Zumastor NAS project, and a tertiary goal > > is to be better than ZFS. > > --------------------------------------------------------------------- > > http://tux3.org/ > > > > was pretty clear. What are you missing? > > > > Ciao, > > 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 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. But at least it should clear that tux3 is a filesystem and not a video game ;). > irregardless about how it's worded, > I'm wondering if I should use this mechanism, > or not. Right now its still in heavy development and not of release quality. I.e. something to play around and test with if you want. Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Attachment:
signature.asc
Description: This is a digitally signed message part.
