From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Justin P. Mattock" Subject: Re: Tux3 report: A Golden Copy Date: Wed, 31 Dec 2008 09:41:45 -0800 Message-ID: <495BAED9.3000305@gmail.com> References: <200812301935.49303.phillips@phunq.net> <200812310000.55256.phillips@phunq.net> <495B2A02.5010701@gmail.com> (sfid-20081231_102522_624170_EF6300E3) <200812311109.12635.Martin@lichtvoll.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: linux-fsdevel@vger.kernel.org, tux3@tux3.org, sniper , Daniel Phillips , linux-kernel@vger.kernel.org To: Martin Steigerwald Return-path: In-Reply-To: <200812311109.12635.Martin@lichtvoll.de> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tux3-bounces@tux3.org Errors-To: tux3-bounces@tux3.org List-Id: linux-fsdevel.vger.kernel.org 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. irregardless about how it's worded, I'm wondering if I should use this mechanism, or not. regards; Justin P. Mattock