Duncan <1i5t5.duncan <at> cox.net> writes: > > Nikolai Grigoriev posted on Tue, 26 Aug 2014 19:39:08 -0400 as excerpted: > > > Kernel: 3.8.13-35.3.5.el6uek.x86_64 #2 SMP Fri Aug 8 21:58:11 PDT 2014 > > x86_64 x86_64 x86_64 GNU/Linux > > > Btrfs v0.20-rc1 > > I've no answer for your question, but you know how old both your kernel > and btrfs-progs versions are, for a filesystem under as heavy development > as btrfs is, right?
Yes. As much as I'd like to run latest & greatest the company sticks to OEL 6.5 so I have to play within the limits. The primary reason why I asked the question is because I have noticed that "btrfs does it much better :)" and wanted to understand why. Either to understand ext4 limitations vs btrfs or to understand the issues with my ext4 configuration. Actually, I have found the answer later last night. I have found that btrfs has its own readahead implementation. So I've got an idea to disable it and see if it makes it slower. And, indeed, I can confirm that in my specific test scenario the readahead with 4Mb (default) buffer was making lots of difference. I think it was mostly due to RAID-0 with 2 SSDs. But even on a single filesystem it does make a difference. Then I have also realized that since it was due to readahead, it won't be a big game changer for Cassandra as it does lots of random reads. But thanks anyway for the detailed explanation of BTRFS status. I'll surely use it as soon as I can. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
