Tux3 Comes Back To Life, Brings Competition To EXT4

[alelinuxbsd]

I like very much the potentiality of this project so i wish that reach quickly a good stage of development so that it can be seriously considered even as an alternative to ext4 (thanks eg. to snapshots).
Since will more light respect Btrfs but with similar enterprise functionalities.

[danielbot]

Slowest thing about EXT4 in the linux kernel is -> stable_write_page ~ it's the reason why Google, Samsung, Mao Bao, Oracle, etc ~ ALL revert that feature on modern kernels for their purposes (think every android device, some google/oracle infrastructure/etc), it has a nasty performance impact on EXT4, especially where high-performance/time-critical operations are desired. You end up with jbd2/sdaX/X spending ridiculous amounts of time on [poll_schedule_timeouts], which KILLS performance for some applications and drags/slows down the whole system. (when using stable_write_page)

Tux3 implements the equivalent of "stable_write_page" without a performance hit, in fact we see a huge performance boost, about 40%. We call it "page fork" and it was originally designed more than four years back, but we only got to test it ten days ago, when enough other machinery fell into place to get meaningly measurements. Full credit to Hirofumi for bringing this tricky thing to reality.

[danielbot]

Using EXT4 has been a good experience over the last several years; the only data loss that i ever really had happen was a drive that failed from other causes... so i am guessing if in all these years i haven't been affected on any machine, and am currently not having those kinds of issues ~ i must be doing something right, really lucky, which i doubt (or the bugs in ext4 are really hard to trigger / require very unusual circumstances).

Your experience mirrors many other's, including mine. This is heartening for us, because it proves that an aggressively optimized filesystem code base can be brought to 100% reliabililty (rounding up) in a timeframe that keeps it relevant.

[ninez]

Your experience mirrors many other's, including mine. This is heartening for us, because it proves that an aggressively optimized filesystem code base can be brought to 100% reliabililty (rounding up) in a timeframe that keeps it relevant.

I agree to the point where i have to patch it, to get my applications to work.

[Detructor]

Versioning as in snapshotting, like Windows "previous versions" except way nicer and more efficient, and built into the filesystem instead of the virtual block device. Multiple read/write snapshots and snapshots of snapshots. The performance sweet spot is targetted at a few tens of simultaneous snapshots, with a planned limit of 512 simultaneous snapshots, though we might increase that to 32K. Basic algorithms for this are designed, prototyped and stress tested, but not added to Tux3 yet.

WANT! Even if it was much slower than ext4, I'd still take it.

[ninez]

Versioning as in snapshotting, like Windows "previous versions" except way nicer and more efficient, and built into the filesystem instead of the virtual block device. Multiple read/write snapshots and snapshots of snapshots. The performance sweet spot is targetted at a few tens of simultaneous snapshots, with a planned limit of 512 simultaneous snapshots, though we might increase that to 32K. Basic algorithms for this are designed, prototyped and stress tested, but not added to Tux3 yet.

I assume Danielbot - that you are involved with Tux3?

if so, i have some questions - i may try Tux3 for one of the systems i am building...

Tux3 not being screwed by the stable pages write stuff is good. I am wondering;

- has Tux3 been extensively tested/used in Linux RT environments, at all?
- How well does it behave in an RT environment, running Windows Applications?
- how much access do you have to adjust/tweak/experiment via sysctl, etc?

if you can answer any of these questions and/or point me to the docs that you think might be of interest to me, that would be great. I know that there are supposed to be some improvements regarding the stable page write stuff in EXT4 (that is supposed to solve these issues, afaik) that is coming down the pipe / being investigated, but for my own systems - i am starting to be interested in exploring other file-systems for more high-performance RT uses, anyway. (might as well cover all bases).

I have a little project i have started; L_ProAudio

Tux3 wouldn't help with that directly; being as the vast majority of users will be using EXT4 (since it's installed) . L_Pa-Wine, the new high-performance/properly mapped Windows PRIOs to linux PRIOs/multi-threaded version of Wine. (and my kernel that attempts to integrate better with Wine - and does). but it could be of use for my own H/W, if it yeilds good performance (which it the critical part). Some of your other features have appeal as well.

thanks

oh, project page if you are curious https://sourceforge.net/projects/l-proaudio/

EDIT: your snapshots would also be helpful for my own H/W.

cheerz

[danielbot]

i may try Tux3 for one of the systems i am building...

Let me be very clear about this: nobody but developers will be seriously using Tux3 for at least two years. You should regard this as pure developer sport.

i- has Tux3 been extensively tested/used in Linux RT environments, at all?

No, Tux3 has not been extensively tested in any environment. Howewever the Tux3 design is realtime-friendly in the sense that it is well suited to adding algorithms that impose small bounded worst case access and update times in relation to some given load.

i- How well does it behave in an RT environment, running Windows Applications?

Windows Applications? Ah, wine. Tux3 has the right features and design to serve Wine apps properly, and VM apps for that matter. Though again, it's not ready for that as of today, even experimentally.

i- how much access do you have to adjust/tweak/experiment via sysctl, etc?

Complete access. Though we will likely provide a more elegant tweaking interface that sysctl.

iI know that there are supposed to be some improvements regarding the stable page write stuff in EXT4 (that is supposed to solve these issues, afaik) that is coming down the pipe / being investigated...

We definitely solved that issue in Tux3, which arguably should be considered "the pipe" for stable pages now.

I have a little project i have started; L_ProAudio. iTux3 wouldn't help with that directly; being as the vast majority of users will be using EXT4 (since it's installed) . L_Pa-Wine, the new high-performance/properly mapped Windows PRIOs to linux PRIOs/multi-threaded version of Wine. (and my kernel that attempts to integrate better with Wine - and does). but it could be of use for my own H/W, if it yeilds good performance (which it the critical part). Some of your other features have appeal as well... EDIT: your snapshots would also be helpful for my own H/W.

Again, just to be very clear, no end user will be using Tux3 for data they care about for quite some time yet. Until such time as Tux3 is proved 100% reliable you should think of it as a shiny developer toy.

[danielbot]

This is why I like CoW FSes like Btrfs. No need to compromise performance to guarantee safe writes.

Incidentally, Tux3 is a CoW filesystem, but without the "recursive CoW to root" performance issue.

[ninez]

Let me be very clear about this: nobody but developers will be seriously using Tux3 for at least two years. You should regard this as pure developer sport.

i do - i know it's not in wide-use.

No, Tux3 has not been extensively tested in any environment. Howewever the Tux3 design is realtime-friendly in the sense that it is well suited to adding algorithms that impose small bounded worst case access and update times in relation to some given load.

gotcha, that makes sense.

Windows Applications? Ah, wine. Tux3 has the right features and design to serve Wine apps properly, and VM apps for that matter. Though again, it's not ready for that as of today, even experimentally.

I see.... Regarding Wine, My project (and goals / networking) has already leaded to some pretty cool stuff coming down the pipe, both in upstream wine and L_pa-Wine. My wine-apps are all Proaudio and run in an RT environment, and often run as well or better than Native linux proaudio apps (and at least in the case of virtual instruments) destroys any native stuff, with few or no exceptions. ~ but ext4 is my single biggest hassle (it's slow as crap with wine, as i mentioned before).

Complete access. Though we will likely provide a more elegant tweaking interface that sysctl.

nice. ~ on both counts - important / good

We definitely solved that issue in Tux3, which arguably should be considered "the pipe" for stable pages now.

Well, i may have to give it a whirl in the next machine that i am building. (since it is no loss to me, if it fails ~ but much yield something interesting either way).

Again, just to be very clear, no end user will be using Tux3 for data they care about for quite some time yet. Until such time as Tux3 is proved 100% reliable you should think of it as a shiny developer toy.

It would be to experiment with. ie: not for production unless _proven_ to be safe and worthwhile in my environment.

I'm going to keep my eye on Tux3 ~ it might be of use to me, in the future ~ and may be worth investigating regardless.

note: i would be using it in a rackmount. not for 'Desktop' usage (in any sense).

Thanks for the reply, your insights have been helpful ~ and an interesting read.

thanks