http://blog.gmane.org/gmane.comp.file-systems.tux3 hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.file-systems.tux3/886 <pre>Just curious if there's been much in the line of news or progress on Tux3. _______________________________________________ Tux3 mailing list Tux3&lt; at &gt;tux3.org http://mailman.tux3.org/cgi-bin/mailman/listinfo/tux3 </pre> Shentino 2011-03-05T03:12:34 http://permalink.gmane.org/gmane.comp.file-systems.tux3/885 <pre> Hi, In Linux 2.6.36 there has been a push down of the BKL inte VFS and similar systems in ordeer to get rid of it, (finally ). I was thinking about having a look at the tux3 driver, in order to try to 'upgrade' it to the latest kernel. Is developement dead or just stalled ? Since the mailing list certainly have been dead for a while ! Also can tux3 be built as a kernel module for a running/existing kernel binary ? It should be reasonable right ? There should be nothing to change in the kernel outside the module ? / regards, Lars Segerlund. </pre> Lars Segerlund 2010-09-08T13:11:03 http://permalink.gmane.org/gmane.comp.file-systems.tux3/884 <pre>Hallo, This is a request to update the patches to the newest kernel. the old 2.6.29 patch won't compile with the newest incarnation if the kernel thx in av Mario </pre> Mario Fetka (geos_one 2010-06-27T09:38:12 http://permalink.gmane.org/gmane.comp.file-systems.tux3/883 <pre> Tux 3 developement seems to have been on ice, is there anything that could be done to get it going again ? If one was to start looking at some part whats most important ? tolls/kernel integration/fs itself ? / regards, Lars Segerlund. </pre> Lars Segerlund 2010-01-12T11:57:09 http://permalink.gmane.org/gmane.comp.file-systems.tux3/882 <pre>_______________________________________________ Tux3 mailing list Tux3&lt; at &gt;tux3.org http://mailman.tux3.org/cgi-bin/mailman/listinfo/tux3 </pre> Balkrishnan V 2009-11-30T19:58:37 http://permalink.gmane.org/gmane.comp.file-systems.tux3/881 <pre>_______________________________________________ Tux3 mailing list Tux3&lt; at &gt;tux3.org http://mailman.tux3.org/cgi-bin/mailman/listinfo/tux3 </pre> nandan yen 2009-11-16T17:18:45 http://permalink.gmane.org/gmane.comp.file-systems.tux3/880 <pre>Greetings, I have zero knowledge as far as filesystems are concerned but I'm interested in learning what Tux3 is and how it works. I started digging into the Tux3 mailing list but, truth is, that I couldn't follow most of the threads. I also tried reading related articles like: http://lwn.net/Articles/288896/ http://tux3.org/shapor-tux3/doc/design.html but I didn't get far either. Apart from basic and unrelated stuff (like how B-trees work, etc.), can you propose me some basic reading on filesystem design so that I can, at least, follow some basic discussion on the mailing list and start checking out the code? As a matter of fact, I think that publishing such a list on the tux3.org would motivate many interested developers on 'joining' the project. Thanks :) </pre> Kadianakis George 2009-10-14T23:29:23 http://permalink.gmane.org/gmane.comp.file-systems.tux3/879 <pre>Hi, Those patches fixes the recent broken things by atomic commit. I hope this patchset fixes all of those. - add tux_new_logmap() to create proper logmap (please review and check) - create -&gt;logmap for some places - use defer btree root allocation for itable (with FIXME) And also this cleans inode stuff up, and as usual, is including various small bugfixes. static-http://userweb.kernel.org/~hirofumi/tux3/ Please review, and pull if ok. Thanks. </pre> OGAWA Hirofumi 2009-08-15T22:21:00 http://permalink.gmane.org/gmane.comp.file-systems.tux3/877 <pre> About sponsorship, I guess Daniel just worried about me. But, it's not argument on lkml. So, let's stop argument about sponsorship. Thanks. </pre> OGAWA Hirofumi 2009-08-10T14:19:05 http://permalink.gmane.org/gmane.comp.file-systems.tux3/874 <pre> Hi Ingo, We were already sorta-kinda invited to merge, as I read it, having received advice to merge early while the code base remains small instead of adding more features and risking premature bloat. I seem to recall there was a dissenter at that time on the basis of lack of atomic commit, and we chose to follow the latter advice instead of the former, arguably a mistake. With 20-20 hindsight, we should have gone for a merge immediately after the SCALE 7X demo, at which time Tux3 was reliably but without atomic commit. Instead, we decided to heed those asking for atomic commit before merge. This turned out to be a bad idea, because my available time soon became severely constrained. Work on atomic commit has progressed over the last few months, but slowly. If we had merged back in February this work would have progressed faster and been done by now. As it is, we will probably forge on with the atomic commit work rather than changing course and looking for a merge right away, because there has been considerable progress in that direction. Also, my time is not quite as constrained as it was - still constrained, but not quite as severely as recently. Meanwhile Hirofumi has dauntlessly forged on, extracting design details from me, adding some of his own, generally subjecting everything to minute scrutiny, and in the process turning out a significant volume of high quality code. If I had to state what the best thing that could happen to Tux3 is, it would be: somebody steps up to sponsor Hirofumi. He has done all that work strictly as a volunteer without support of any kind, and he could use some. Not to mention the fact that as FAT maintainer we would be well served to have Hirofumi in a comfort zone, given recent developments on that front. My "invite to merge" comment was made in the context of various comments about insufficiently rapid progress, and should not be taken out of context. We are well aware of the traditional merging procedure. We certainly are not waiting for any maintainer action, but rather for more progress from ourselves. There are various possibilities to speed that up. See "sponsor Hirofumi" above. I myself do not need sponsorship at this point, what I need is more time on my hands, and only I can do anything about that. (As of today, I do have a little more time available, hence this post.) In fact, our merge process has been in progress since February. As we see it, it goes like this: 1) Implement and verify atomic commit correctness at least for a large subset of filesystem operations. 2) Clean the kernel part of the code base to a respectable state. 3) Commence our post-address-repost cycle with intent to merge. We are at step 1 and I can't say how long it will take to get to step 2. It is on the way. Any help we get will hurry it along. I will very briefly address Ted's question, which amounts to: "why do we want Tux3?" I think Tux3 fills an empty niche in our filesystem ecology where a simple, clean and modern general purpose filesystem should exist and there is none. In concrete terms, Tux3 implements a single-pointer-per-extent model that Btrfs and ZFS do not. This allows a very simple *physical* design, with much complexity pushed to the *logical* level where things generally behave better. A simple physical design offers many benefits, including making it easier to take a run at that holiest of holy grails, online check and repair. In even more concrete terms, Tux3 already demonstrates a tiny memory footprint, unlike Btrfs or ZFS. Its CPU footprint is also tiny. As such, Tux3 could easily run on a cellphone or smaller device, while offering a full range of "big filesystem" capabilities. (Note that Zumastor already proves we know how to do replication properly: http://zumastor.org/.) Regards, Daniel </pre> Daniel Phillips 2009-08-08T23:47:21 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.file-systems.tux3