Page 1 of 2 12 LastLast
Results 1 to 10 of 19

Thread: Tux3 Comes Back To Life, Brings Competition To EXT4

  1. #1
    Join Date
    Jan 2007
    Posts
    14,829

    Default Tux3 Comes Back To Life, Brings Competition To EXT4

    Phoronix: Tux3 Comes Back To Life, Brings Competition To EXT4

    It's been a few years since last having anything to talk about with regard to the Tux3 file-system, but with the new year comes news on Tux3. This file-system has advanced and is more competitive now with EXT4...

    http://www.phoronix.com/vr.php?view=MTI2NjE

  2. #2
    Join Date
    Dec 2008
    Location
    Creve Coeur, Missouri
    Posts
    399

    Default

    Remember how fast EXT4 was before it was actually safe to use? Anyway, I'd like to see if it is actually workable before it gets rolled into several major distributions and it is found out that it looses data whenever you improperly shut down.

  3. #3
    Join Date
    Sep 2008
    Posts
    264

    Default

    Tux3 is a versioning file-system
    explanation please. Are we speaking of something like Windows 7 file recovery? Or build-in SVN style (which would be kind of weird)?

  4. #4

    Default

    Quote Originally Posted by LinuxID10T View Post
    Remember how fast EXT4 was before it was actually safe to use? Anyway, I'd like to see if it is actually workable before it gets rolled into several major distributions and it is found out that it looses data whenever you improperly shut down.
    It still can be that fast (and mostly safe) if your computer has backup power.

  5. #5
    Join Date
    Jun 2011
    Posts
    840

    Default

    Quote Originally Posted by LinuxID10T View Post
    Remember how fast EXT4 was before it was actually safe to use? Anyway, I'd like to see if it is actually workable before it gets rolled into several major distributions and it is found out that it looses data whenever you improperly shut down.
    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)

    ...anyway, i am guessing you and the vast majority of users never had to worry about the EXT4 bug that you are talking about. It only affected a _very_ small number of people with _specific_ configurations required to trigger that bug. and fyi - you won't see tux3 rolled into many (more likely no) distros as the default file-system (if ever....imho, very unlikely).
    Last edited by ninez; 01-01-2013 at 02:54 PM.

  6. #6
    Join Date
    Dec 2008
    Location
    Creve Coeur, Missouri
    Posts
    399

    Default

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

    ...anyway, i am guessing you and the vast majority of users never had to worry about the EXT4 bug that you are talking about. It only affected a _very_ small number of people with _specific_ configurations required to trigger that bug. and fyi - you won't see tux3 rolled into many (more likely no) distros as the default file-system (if ever....imho, very unlikely).
    Well, it is all fun and games until you lose a large section of a paper to it :P From a programming prospective, the default way that EXT4 came out was not at all data safe. I mean, I could understand if you were running on backup power or from a device where it is not really that necessary, but it is an absolute must for a typical desktop or laptop.

  7. #7
    Join Date
    Dec 2012
    Posts
    534

    Default

    Quote Originally Posted by LinuxID10T View Post
    Well, it is all fun and games until you lose a large section of a paper to it :P From a programming prospective, the default way that EXT4 came out was not at all data safe. I mean, I could understand if you were running on backup power or from a device where it is not really that necessary, but it is an absolute must for a typical desktop or laptop.
    This is why I like CoW FSes like Btrfs. No need to compromise performance to guarantee safe writes. I hope they officially start calling btrfs stable this year, because it is great not just for datacenters but for regular users too.

  8. #8
    Join Date
    Jun 2011
    Posts
    840

    Default

    Quote Originally Posted by LinuxID10T View Post
    Well, it is all fun and games until you lose a large section of a paper to it :P From a programming prospective, the default way that EXT4 came out was not at all data safe. I mean, I could understand if you were running on backup power or from a device where it is not really that necessary, but it is an absolute must for a typical desktop or laptop.
    True enough. That being said, i don't use stable_page_writes on a single machine of mine, not desktop, not laptop... it creates to much of a bottleneck and blows the big one. (here's hoping 3.8/3.9 fixes the situation. we will see). 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).

    either way. i think ext4 has room for improvements, and i have no idea when i will actually use Btrfs...someday

  9. #9
    Join Date
    Jan 2013
    Posts
    20

    Default

    Quote Originally Posted by Detructor View Post
    explanation please. Are we speaking of something like Windows 7 file recovery? Or build-in SVN style (which would be kind of weird)?
    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.

  10. #10
    Join Date
    Jan 2013
    Posts
    20

    Default

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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •