[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <495E7AD2.3000405@gmail.com>
Date: Fri, 02 Jan 2009 12:36:34 -0800
From: "Justin P. Mattock" <justinmattock@...il.com>
To: Martin Steigerwald <Martin@...htvoll.de>
CC: tux3@...3.org, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org, Daniel Phillips <phillips@...nq.net>
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists