Announcement

Collapse
No announcement yet.

Tux3 Comes Back To Life, Brings Competition To EXT4

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • ninez
    replied
    Originally posted by danielbot View Post
    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.

    Originally posted by danielbot View Post
    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.

    Originally posted by danielbot View Post
    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).


    Originally posted by danielbot View Post
    Complete access. Though we will likely provide a more elegant tweaking interface that sysctl.
    nice. ~ on both counts - important / good


    Originally posted by danielbot View Post
    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).

    Originally posted by danielbot View Post
    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

    Leave a comment:


  • danielbot
    replied
    Originally posted by zanny View Post
    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.

    Leave a comment:


  • danielbot
    replied
    Originally posted by ninez View Post
    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.

    Originally posted by ninez View Post
    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.

    Originally posted by ninez View Post
    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.

    Originally posted by ninez View Post
    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.

    Originally posted by ninez View Post
    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.

    Originally posted by ninez View Post
    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.

    Leave a comment:


  • ninez
    replied
    Originally posted by danielbot View Post
    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
    Last edited by ninez; 03 January 2013, 04:35 PM.

    Leave a comment:


  • Detructor
    replied
    Originally posted by danielbot View Post
    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.

    Leave a comment:


  • ninez
    replied
    Originally posted by danielbot View Post
    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.

    Leave a comment:


  • danielbot
    replied
    Originally posted by ninez View Post
    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.

    Leave a comment:


  • danielbot
    replied
    Originally posted by ninez View Post
    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.

    Leave a comment:


  • alelinuxbsd
    replied
    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.

    Leave a comment:


  • danielbot
    replied
    Originally posted by ninez View Post
    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 pages at the filesystem level, without the performance drawback. We call it "page fork" and in fact it speeds Tux3 up a lot, as described in the new news post.

    Leave a comment:

Working...
X