Tux3 File System Could Finally Make It Into the Mainline Linux Kernel 121
An anonymous reader writes "The Tux3 file-system that's been in development since 2008 as the public replacement to the patent-blocked Tux2 file-system is now under review for inclusion into the Linux kernel. Tux3 tries to act as a 'light, tight, modern file-system. We offer a fresh approach to some ancient problems,' according to its lead developer, Daniel Phillips. Tux3 strives for minimal resource consumption but lacks enterprise-grade reliability at this point. Tux3, at the end of the day, tries to be 'robust, fast, and simple' with the Linux FS reportedly being as fast as other well known file-systems. Details on the project are at Tux3.org."
Ambitious but not much has happened in 6 yrs (Score:4, Insightful)
and they expect to be competitive with ZFS?? They have a LOT of work to do.
Re: (Score:1, Interesting)
and they expect to be competitive with ZFS?? They have a LOT of work to do.
It's just another run of the mill linux filesystem which is to say completely useless.
The only real viable filesystems on linux are XFS, followed by EXT 4 and BTRFS (only in experimental form).
Re: (Score:2)
I only use XFS and ZFS on Linux these days, with exception of ext2 on some /boot volumes. Nobody has shown me a compelling reason to deviate from what works.
Re:Ambitious but not much has happened in 6 yrs (Score:4, Interesting)
Obviously, x86_64 platforms don't have this issue, but I was operating an i386 server since 2008 until just a few months ago and I found it to be extremely annoying and (at first) difficult to figure out what was happening. There is surprisingly little information about XFS and 64-bit file syscall issues when all you have is strace spouting EOVERFLOW at you and don't immediately pin the issue to the filesystem in use.
Re: (Score:2)
That's a darn good find, and definitely a really annoying issue. You're correct that 99% of the stuff I manage is x86-64; I've only got a couple of legacy x86 systems floating around, and fortunately in this case they don't use XFS. I can only imagine the amount of $head_desk you went through before realizing what the root cause was in the case you described.
Re: (Score:2)
Re:Ambitious but not much has happened in 6 yrs (Score:5, Insightful)
Re: (Score:2)
Re: (Score:3, Insightful)
One such example is bt
Re: (Score:1)
Could you elaborate on your example? I not understanding what commands make it possible to mount a volume "under multiple parents" how this differs from shared or bind mounts. I can mount an XFS volume on two separate mountpoints, not a big deal. Btrfs volumes can't be snapshot, just their subvolumes, maybe that's what you're referring to? The lack of recursively snapshotable nested subvolumes?
Btrfs and ZFS are different
Re: (Score:3)
There are valid reasons to want to mount a volume in more than one place. For example, strong namespace based isolation for sensitive processes/users.
Over all, btrfs is much more flezible than ZFS. In the end, it looks like it will be the superior filesystem. For example, it has a much greater flexibility in changing the underlying storage over time. Why should gradually upgrading the underlying pool be a disruptive process. It seems natural that as drives age out to replace them with bigger drives. Ideally
Re:Ambitious but not much has happened in 6 yrs (Score:4, Interesting)
Different tools for different jobs.
Re: (Score:2)
> ZFS is great, but it's not perfect
Serious question: I'm curious as to what those would be?
The license?
Re: (Score:3)
The license is an annoyance, but can be lived with, more or less.
I would like to see more flexibility in re-structuring the zpool. I see no intrinsic reason why a pool can't start out without redundancy and then have it added after the fact (the equivilent of bringing a soft raid up in degraded mode and adding in the other devices later) or have the geometry changed later. It should be perfectly feasible to start small and over time add more disks and replace small disks with larger ones. I would really lik
Re: (Score:2)
Memory requirements, for one. ZFS is probably a terrible choice for tizen, or firefox os, or raspbian.
Re: (Score:1)
"Monoculture is never a good thing." Sentences with "sth. is never/always X" are generally not trustworthy... Always doubt. Maybe monoculture sometimes IS a good thing, who knows?
Re: (Score:2)
Re: (Score:2)
Indeed, different aims. Tux3 has the modest goal of being a light, tight and fast filesystem without ambition of also being a volume manager.
Re: (Score:2)
There are more i/o workloads and problem domains than the enterprise grade storage system that zfs is designed for. Its like declaring that the Honda fit can never compete with a dump truck.
Re: (Score:2)
This particular Honda Fit is not even properly assembled so it couldn't even bring a new set of tires for the dump truck.
Did you miss the part where it was stated "and a tertiary goal is to be better than ZFS"
The implication is that it will eventually be a ZFS replacement. My point is that they are so far behind and have accomplished so little to date, that will NEVER happen.
If they prove me wrong, good for them. I'm always on the lookout for a better tool or way to do things but I stand by my remark that t
Re: (Score:2)
Yes, I did miss that part where they pointed to zfs as an aspiration. Strange, weird, and just wrong.
TFS misses one point (Score:5, Informative)
From TFA: "Tux3 is yet another interesting open-source file-system designed for specialized cases."
NIHFS? (Score:5, Interesting)
First off, I think that 'better than ZFS' is a good and legitimate goal, seeing as how ZFS is very, very good, but not perfect.
That said, there's also BTFS and HAMMER aiming to be 'better than ZFS'.
I know: everyone wants to scratch their own itch, and there is no reason that multiple projects in the same area should necessarily been see as competing, and if I'm unhappy about it, I should just go write my own instead of complaining. Did I cover everything? :)
I just wonder sometimes if Linux wouldn't have moved beyond EXT4, X11, and the desktop environment wars if the 'not invented here' syndrome were just a little less prevalent.
At least... (Score:1)
At least it'll be moving past X11 in a year or two :). But then people with no understanding are arguing that Wayland is NIH-X11 -- it's so confusing having to understand nuance!
Choice (Score:4, Insightful)
Oh, please. A modern Linux distro actually needs to provide hotplug that actually works, a tear-free desktop experience, reliable service termination/startup/restarts, etc.
Stop living in the past.
Re: (Score:3)
Re: (Score:2)
Re: (Score:2, Troll)
If you don't like shiney, then there's always the console. For everyone else who likes desktops for stuff like videos or web browsing, annoyances like tearing is a distraction, like a 3 year old throwing a temper tantrum. Tearing was an issue fixed back in the 90s.
I've used X11 and later Xorg for about the last 15 years. I've never had issues with tearing or any other visual artifacts. Back in the day I certainly had a real good time with modelines (fun!) but I've never had problems with tearing.
Am I the only one who hears complaints like this and scratches his head wondering what the fuss is all about? Lots of these mysterious complaints have never happened to me. I don't believe you are being dishonest, I just would like a more in-depth explanation about wha
Re: (Score:2)
So what's you're saying is that a modern Linux distro should be more like FreeBSD?
Re: (Score:2)
That's a bit rich after some of your earlier posts about X and Wayland. I suggest you join the wayland mailing list and get some understanding before making such comments.
Re: (Score:1)
When anything has a claim to fame of "trying to be better than $GOLD_STANDARD", I am skeptical. There must be very compelling reasons to not just stick with what is tried and true. ZFS is the cat's meow, "trying to be better than" when we're talking about something as critical as a filesystem... I'll wait and see, thanks.
Re: (Score:1)
this is not the only weasel word infested post by you to this same article. ... saying $GOLD_STANDARD
who claims that zfs is $GOLD_STANDARD? and which version of zfs
are you talking about? oracle keeps putting out incompatible versions, and
then there are the various opensolaris and bsd verions.
implies something that is clearly not true --- that there is "a" zfs.
Re:NIHFS? (Score:5, Interesting)
Re: (Score:1)
I can see Tux3 used in some special cases, but there are so many filesystems that should be tossed in the Linux kernel first, IMHO. A few thoughts/ideas:
1: A successor for SquashFS except with the option of some ECC to detect corruption and optionally to fix it. That way, a compressed image can be somewhat self-healing.
2: Hooks for ZFS on Linux. Because of the license differences, it can't be included into the kernel proper, but might as well make it as easy as possible to have it used on bootup, perha
Re: (Score:1)
I'll bite. What's your native language? To a native speaker of English, that would have been "should necessarily be seen".
But attaching the tense to the "to be" isn't totally out of bounds in some languages. I think.
So, what language did you grow up thinking in?
Re: (Score:3)
Apparently, I grew up speaking 'typo'.
I suspect it's an editing error where I was writing in present tense (be seen as...), started a switch to past tense (been seen as...), and instead ended up with that ridiculous construction.
Oops.
Re: (Score:2)
I just wonder sometimes if Linux wouldn't have moved beyond EXT4, X11, and the desktop environment wars if the 'not invented here' syndrome were just a little less prevalent.
The EXT* have been the only native filesystems of Linux, and BTRFS is something recent. With ZFS, the issue is an incompatible license, since CDDL code can't legally be combined w/ GPL code. Wayland again is new and likely to be the standard, aside from Ubuntu Unity, which will use Mir, and Android, which uses SurfaceFlinger
I do agree that there is a plethora of DEs. In the beginning, there was just KDE. Between that, and FOSS ports of CDE or Motif/OpenLook, they'd have been fine. Then came GNOME (d
As an old OpenVMS fan, this isn't... (Score:3)
what I think of when someone writes "versioning filesystem".
Re: (Score:2)
As versioning goes, FILES-11 was barely good enough to be called built in un-delete. Nowhere near as good as just checking all your files into git.
Re: (Score:2)
As versioning goes, FILES-11 was barely good enough to be called built in un-delete.
Mainly because -- in my 25 years using FILES-11 -- I've never heard of versioning called "undelete".
"Persistent undo" is the best term to describe going back to a prior file version.
parent delays (Score:4, Insightful)
So tux2 was ready in 2000, and it took 14 years to rewrite it to avoid parents? Oh how much patents help innovation!
Re: (Score:1)
So tux2 was ready in 2000, and it took 14 years to rewrite it to avoid parents? Oh how much patents help innovation!
Few more years and those patents will expire and we can use both!
Re:parent delays (Score:4, Informative)
So tux2 was ready in 2000, and it took 14 years to rewrite it to avoid parents? Oh how much patents help innovation!
Few more years and those patents will expire and we can use both!
Tux3 is a better design. Tux2 was more along the lines of ZFS and Btrfs, that is, multiply-rooted trees sharing subtrees. Tux3 is a single tree with exactly one pointer to each extent. Considerably easier to check and repair. Of course we need to see if it turns out that way so please stay tuned.
Re:parent delays (Score:5, Funny)
took 14 years to rewrite it to avoid parents!
A lot of these linux developers are pretty young.
Re: (Score:1, Interesting)
Politicians could at least recognize the faster pace in the IT world compared to other technology industries, and lessen the patent terms for software patents.
I also don't know why there should be a difference between a patent troll and a large company with lots of 'defensive' patents suing other companies because of "swipe to unlock" features.
Re: (Score:3)
ZFS or fail (Score:2)
Come to the 21st century, use ZFS.
Clearly (Score:1, Funny)
Since Trolling is an art, and stuff.
Re: (Score:2)
Re: (Score:1)
yes, if zfs worked correctly, it would be the ultimate evolution of 70s technology --- a non-distributed file system that may take an indeterminate time to export and recover. but it doesn't. i've seen customers lose lots of data with zfs. i have not had this experience with other file systems.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
It's old and mature -- so let's come up (Score:3)
Is the general problem of the GNU- and Linux world.
Backstory (Score:4, Interesting)
This is the story of the patents involved. [swpat.org] It's not so much that there was any litigation, but rather the ongoing threat that there would be (for arguably stuff that was already being done.)
Untested and unused always tests as faster (Score:1)
Systems that no one uses always test out faster than ones that actually work, deal with edge cases, do reliable recovery from hard crashes, etc. That's why ReiserFS was always faster, but kept hiding the corpses in the woods and pretending complete ignorance of having destroyed your data.
http://en.wikipedia.org/wiki/Hans_Reiser
Come on, how could you not trust yet another "fan boi" burdened filesystem that's never been been shown as stable?
Waste of time and effort (Score:1)
Aw, come on.
A local file system won't really rock one's boat anymore these days. Today it's all about global name space and distributed file systems, ideally made highly available and replicated synchronously in real time on kernel level.
This one was a real waste of time and developer resources.
Re: (Score:2)
Those shiny distributed file systems run on top of boring local filesystems.
YASF (c) forver by me (Score:3)
YASF or Yet Another File System.
Well someone has yet another personal project they want us all to take seriously. Really? I mean Really?
Of the numerous file systems out there, and I have tried a whole boat load of them, the one that is the most mature, most reliable, arguably the fastest is... Wait for it... From the company that everyone loves to hate...
Is NSS from Novell. It has more posix features then all of the rest of them, it is insanely fast, it provides undelete and complete repeatability and Novell has open sourced it. Nuff said.
Re: (Score:3)
Not sure if trolling.. but I looked it up, and on the paper it seems interesting, but for use today it has limitations: 2 TB maximum device size, 8 TB maximum volume size. So that's a non-contender. Seems quite advanced for its day, though (introduced 1998).
Re: (Score:2)
Nope, not trolling..
Since it is open source and has all those goodies it would seem to me that increasing the volume size capabilities would not be nearly as tall an order as starting over from scratch.
Re: (Score:1)
> YASF or Yet Another File System.
Woldn't that be "Yet Another Sile Fystem"? Or something?
Look: I don't know who this Flying Guy is nor what he has done for me recently. But Daniel Philips... this is an awesomely smart guy, and friendly and all. And he has contributed to free software which I use every day.
Now imagine how much weight your rant has in my eyes. This might be a view shared by many.
Ready for mainline? (Score:2)
To be taken serously, the home page needs to mention something more recent than 2008 in the "on the web" section. And the "we're active, see the git log" link needs to point somewhere other than a 404....
Re: (Score:2)
Thanks for the bug report :)
Re: (Score:2)
Daniel phillips, where have I heard that name before? It was in the last few days.... :-) Ah! :-)
versioning (Score:2)
what about the cleanup?
Nilfs2 is quite cool, but the cleaner-daemon causes a lot of disk io, which is not only annoying, but makes me think about disk lifetime as well.
Re: (Score:2)
Tux3 does not need a cleaner. At the moment, Tux3 also does not have snapshots. When it does, it still won't need a cleaner, although snapshot delete will run in the background because many inodes may need to be updated. This only touches metadata, which is normally less than 1/100th of the volume so it should be OK: some activity after the snapshot delete, but otherwise, changes commit immediately to disk then the disk goes quiet.