Messages in this thread | | | Date | Fri, 02 Jan 2009 12:36:34 -0800 | From | "Justin P. Mattock" <> | Subject | Re: [Tux3] Tux3 report: A Golden Copy |
| |
Martin Steigerwald wrote: > 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, > Yeah, my bad for thinking tux3 was a video game (don't ask why); I need to get glasses!! When I was told it was a filesystem it clicked. As for the atomic commit Thanks for explanation. (I honestly had no idea what that meant); with test and playing around with this, I have an old dell inspiron hanging around, when I have the time I'll have to give it a try. Do I have to wipe out the ext3 partition on it, or is that O.K.
regards;
Justin P. Mattock
| |