Tux3 File System Could Finally Make It Into the Mainline Linux Kernel

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."

Comments

Ambitious but not much has happened in 6 yrs

[haruchai]

and they expect to be competitive with ZFS?? They have a LOT of work to do.

Re:Ambitious but not much has happened in 6 yrs

[Bengie]

It's a worthy goal to have. We need more competition in the FS sector. Many times competition is the inspiration for new features, even if some of these FS don't even make it off the ground. ZFS is great, but it's not perfect, and they only have so many resources to throw at new ideas to test. Monoculture is never a good thing.

Re:Ambitious but not much has happened in 6 yrs

[Bengie]

btrfs is interesting, but it's taking a long time to get anywhere and it has some big backers. I've also read some really well written blogs from sysadmins who have been Unix admins since the beginning of time, and they had some really good examples of some "Features" of btrfs that a sysadmin should never-ever use under any circumstance, and some features that are half-asses that are nearly a requirement for any good sysadmin, but cannot be done because of those other "bad" features.

One such example is btrfs allows a volume to be mounted under multiple parents. In order to handle this "awesome" feature, they had to give up the ability to atomically snapshot across volumes. In ZFS, if you mount a volume under another volume and snapshot the parent, the children will automatically be atomically included, not so with btrfs, that's an impossibility to add a feature that should never be used.

Re:Ambitious but not much has happened in 6 yrs

[dbIII]

I disagree. The different approach of ZFS means it should be far better than btrfs when you have many disks, yet it makes almost no sense at all with single disks which is where btrfs makes sense.
Different tools for different jobs.

Re:Ambitious but not much has happened in 6 yrs

[nctritech]

This is probably irrelevant for you, but I ran into issues with software running on i386 with XFS and newer kernels. Programs not compiled with -D_FILE_OFFSET_BITS=64 used the 32-bit versions of certain file-related system calls, and the default mount options for XFS changed at some point to allow 64-bit inode numbers to be created. What would happen is the program would readdir and choke the instant it hit a file or directory on an inode number greater than 2^32; the fstat calls returned EOVERFLOW and processing aborted. You'd go into a directory with GQView, for example, and mysteriously see i.e. three images and one directory where you knew there were tens of directories and hundreds of images.

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:Ambitious but not much has happened in 6 yrs

[sjames]

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, the filesystem will move things around as needed to maintain the specified level of redundancy and to utilize as much of the new storage as possible.

I am currently using ZFS because btrfs isn't yet sufficiently mature, especially wrt redundancy

Re:Ambitious but not much has happened in 6 yrs

[sjames]

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 like to be able to evacuate a disk before pulling and replacing it (given enough free capacity elsewhere in the pool.

TFS misses one point

[NotInHere]

From TFA: "Tux3 is yet another interesting open-source file-system designed for specialized cases."

NIHFS?

[BaronM]

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.

Re:NIHFS?

[Bengie]

OpenZFS. They're getting rid of "versions" and just having "Feature flags". This will allow you to create ZFS pools on one system, and just make sure what ever features that are only supported on another target system, are enable when you create the pool.

Re:NIHFS?

[BaronM]

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.

As an old OpenVMS fan, this isn't...

[Nutria]

what I think of when someone writes "versioning filesystem".

parent delays

[KiloByte]

So tux2 was ready in 2000, and it took 14 years to rewrite it to avoid parents? Oh how much patents help innovation!

Re:parent delays

[MichaelSmith]

took 14 years to rewrite it to avoid parents!

A lot of these linux developers are pretty young.

Re:parent delays

[phantomfive]

That's lucky, it took me 18 years to get free of my parents. Although it might be more accurately described as, "they kicked me out of the house." But let's not go there.

Re:parent delays

[Daniel Phillips]

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.

It's old and mature -- so let's come up

[fisted]

..with something new already.

Is the general problem of the GNU- and Linux world.

Backstory

[eclectro]

This is the story of the patents involved. 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.)

Choice

[warrax_666]

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:Choice

[K. S. Kyosuke]

If you haven't noticed, he *was* talking about simplicity. Just the MIT type, not the New Jersey one.

YASF (c) forver by me

[FlyingGuy]

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:YASF (c) forver by me

[flux]

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).