A Patch That Can Make Btrfs 5~10% Faster

[phoronix]

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

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

[jwilliams]

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

[RealNC]

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

[renkin]

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.

[rrohbeck]

Check out these patches to disable COW for specific data files (like DBs and VMs) that are better written in-place. I just built the patched chattr and I'm defragmenting and rebalancing my VM subvolumes right now.
http://www.spinics.net/lists/linux-btrfs/msg09604.html
http://www.spinics.net/lists/linux-btrfs/msg09605.html

[jwilliams]

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!

[GreatEmerald]

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.

[jwilliams]

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.

[renkin]

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.

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 (torva...@kruuna.helsinki.fi)
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?

[mgmartin]

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.