Announcement

Collapse
No announcement yet.

A Patch That Can Make Btrfs 5~10% Faster

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

  • A Patch That Can Make Btrfs 5~10% Faster

    Phoronix: A Patch That Can Make Btrfs 5~10% Faster

    A patch has been sent over to the Btrfs developers that can result in the next-generation Linux file-system being 5~10% faster in writes by introducing an extent buffer cache for each i-node...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    still no btrfsck

    I noticed the promised repair-capable btrfsck did not come out by Feb 14 as promised. Yet another deadline missed.

    Comment


    • #3
      Performance improvements are nice, but a patch that allows fsck would be more useful. Data safety > speed.

      Comment


      • #4
        Originally posted by jwilliams View Post
        I noticed the promised repair-capable btrfsck did not come out by Feb 14 as promised. Yet another deadline missed.
        btrfsck is going through QA internally at Oracle. It needs to be _safe_ before being released. Another thing is that Feb 14 was likely a deadline for Oracle (for proper QA) more so than a deadline for public release.

        Comment


        • #5
          Originally posted by renkin View Post
          btrfsck is going through QA internally at Oracle. It needs to be _safe_ before being released. Another thing is that Feb 14 was likely a deadline for Oracle (for proper QA) more so than a deadline for public release.
          Strange for something that I thought would be open source. Release the source code and let everyone who wants to try it do the testing!

          Comment


          • #6
            Originally posted by jwilliams View Post
            Strange for something that I thought would be open source. Release the source code and let everyone who wants to try it do the testing!
            You don't want to release the source code of something that could (and without proper testing, most likely would) destroy the testers' drives... Better to make sure it's safe at least in local testing before that, and then release to public testing, and only after that declare it stable.

            Comment


            • #7
              Originally posted by GreatEmerald View Post
              You don't want to release the source code of something that could (and without proper testing, most likely would) destroy the testers' drives... Better to make sure it's safe at least in local testing before that, and then release to public testing, and only after that declare it stable.
              Then it will never be released, eternal vaporware.

              Good open source follows the release early, release often philosophy, even during alpha testing. More people looking at the code is better.

              Comment


              • #8
                Originally posted by jwilliams View Post
                Then it will never be released, eternal vaporware.

                Good open source follows the release early, release often philosophy, even during alpha testing. More people looking at the code is better.
                Originally posted by Linus Torvalds
                Hello everybody out there using minix -
                I'm doing a (free) operating system (just a hobby, won't be big and
                professional like gnu) for 386(486) AT clones. This has been brewing
                since april, and is starting to get ready. I'd like any feedback on
                things people like/dislike in minix, as my OS resembles it somewhat
                (same physical layout of the file-system (due to practical reasons)
                among other things).
                I've currently ported bash(1.08) and gcc(1.40), and things seem to work.
                This implies that I'll get something practical within a few months, and
                I'd like to know what features most people would want. Any suggestions
                are welcome, but I won't promise I'll implement them :-)
                Linus ([email protected])
                PS. Yes - it's free of any minix code, and it has a multi-threaded fs.
                It is NOT protable (uses 386 task switching etc), and it probably never
                will support anything other than AT-harddisks, as that's all I have :-(.
                Doesn't matter if it's open source. People get their code ready with reasonable stability/design before releasing.

                I hangout in the btrfs channel on freenode all the time, and everyday I see people come in to say "My btrfs is corrupt, where can I find the fsck utility? I tried the one from git, and it didn't work" .. Can you imagine if the read-write version of btrfsck were made public before it's ready?

                Comment


                • #9
                  Originally posted by renkin View Post
                  Doesn't matter if it's open source. People get their code ready with reasonable stability/design before releasing.

                  I hangout in the btrfs channel on freenode all the time, and everyday I see people come in to say "My btrfs is corrupt, where can I find the fsck utility? I tried the one from git, and it didn't work" .. Can you imagine if the read-write version of btrfsck were made public before it's ready?
                  I not only imagine it, I expect it from a true open source project. Open is open...stable/ready or not.

                  I spent a lot time messing with btrfs and zfs on linux the last few days. I couldn't understand why the last git commit to btrfs-progs was Dec 1 2011--especially when I see all the headlines in the news and presentations being made talking about fsck and other changes over the last few months. I was ready to play.

                  Anyone checking out btrfs code from git and compiling the code is well aware that it could blow up your hard drive and all your data along with it. The same would hold true for an fsck program included with the bundle. I see the forums posts of people seeing corruption, and anyone who starts complaining is quickly reminded of the fragile state of the entire btrfs filesystem.

                  While any open source developer is free to release and commit what they want and when, I agree with the philosophy to release often and release to the widest test audience possible. The argument that it's crazy to release a read-write version of btrfsck before it's fully tested and ready just doesn't make sense given the fact that btrfs and user space programs are already released and considered experimental as is.

                  I'm sure we'll see the btrfsck code released soon, and I have no expectation that it will be production ready or come with any guarantees my hard drives and data won't get lost. The sooner the better, so it can gain a wider test audience than any internal testing can offer.

                  disclaimer: I don't know if the btrfsck delay in release is because of internal testing or not. I believe the argument to hold off on releasing open source code to the public because it's unstable is flawed.

                  Comment


                  • #10
                    XFS?

                    If you're gonna do benchmarks, please include XFS, not just EXT4.

                    Comment

                    Working...
                    X