Re: [Tux3] Tux3 report: A Golden Copy

[Martin Steigerwald <Martin@Lichtvoll.de>]

[-- Attachment #1: Type: text/plain, Size: 2936 bytes --]

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 #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]