Sort of makes ZFS on linux a moot point, eh?
|
| Author | Content |
|---|---|
| herzeleid Jul 28, 2010 2:30 PM EDT |
Some of my fellow geeks have been saying "if only we could have native ZFS on linux", to which I answer "no worries, btrfs and/or other cool new filesystems will make that a moot point". I rest my case. |
| tuxchick Jul 28, 2010 2:46 PM EDT |
I figured it was moot anyway, as long as it runs on Linux only in userspace. |
| herzeleid Jul 28, 2010 3:40 PM EDT |
@tc - I agree there - userspace is nice for novelties and light use, but heavy I/O would not be a good thing to depend on userspace filesystems for. But in the light of maturity and continuing performance advances in ext4 and btrfs, even if the license issues were cleared up so that ZFS could be included in the kernel, the reaction would be not so much "yay, finally an awesome filesystem" as , "hmm, another interesting new filesystem choice, maybe I'll play with it one of these days" |
| gus3 Jul 28, 2010 6:06 PM EDT |
Quoting:userspace is nice for novelties and light use, but heavy I/O would not be a good thing to depend on userspace filesystems for.Same goes for btrfs. My testing shows it to be the worst filesystem of all the intended "regular desktop" FS's. Even a poorly-tuned XFS with the CFQ elevator beats btrfs. |
| herzeleid Jul 28, 2010 6:53 PM EDT |
@gus3 - btrfs is in rapid development, so your old assumptions can probably be tossed right out the window. I'd love to see your xfs vs btrfs results, the phoronix performance testing code is freely available. But remember, benchmarking xfs against the btrfs from 9 months ago is no fair. |
| gus3 Jul 28, 2010 9:28 PM EDT |
@herzeleid: I'll see if I can run some tests this evening. |
| gus3 Jul 28, 2010 11:23 PM EDT |
Okay, here are some basic results based on Dbench. My tests are based on CPU speed and I/O elevator, and the filesystems were created with a simple "mkfs.fstype /dev/sda2": btrfs 5 threads, 35-40 MB/s btrfs 20 threads, 89-115 MB/s xfs 5 threads, 30-32 MB/s xfs 20 threads, 42-43 MB/s So, my initial statement that "btrfs is worse than a poorly-tuned xfs" was off-the-mark. But, with an external journal on a separate controller, xfs blows everything else out of the water: xfs 5 threads, 222-442 MB/s xfs 20 threads, 198-415 MB/s Thinking that maybe disk I/O that was the bottleneck, I did a quick one-off Dbench run on ext2. With the noop elevator at 1.0 GHz, an async (default) mount gave 240 MB/s, and a sync mount gave 27.49 MB/s. I will say this much: btrfs shows more scaling than does jfs, which saturated at 40 MB/s under nearly all my tests. On the other hand, jfs shows the best performance for populating a sparse file, which (my guess is) a common operation for databases. So I can see where jfs has its place. EDIT 2010-07-30: Based on later research which corrected my ignorance, I have removed some incorrect information from this comment, so that false information does not turn up in a web search. |
| mortenalver Jul 29, 2010 2:45 AM EDT |
Quoting:@tc - I agree there - userspace is nice for novelties and light use, but heavy I/O would not be a good thing to depend on userspace filesystems for. Is this for performance reasons only, or are there other disadvantages? |
| gus3 Jul 29, 2010 3:41 AM EDT |
Quoting:Is this for performance reasons only, or are there other disadvantages?It's one thing to cause a context switch (from user space to kernel) for each disk I/O. It's much worse to cause three context switches (user space -> kernel -> user space ->kernel) as is the case with FUSE. |
| gus3 Jul 29, 2010 11:09 PM EDT |
Just for giggles, I tried btrfs on a two-stripe volume. LVM delivered a moderate performance hit: btrfs 5 threads, 32-39 MB/s btrfs 20 threads, 75-103 MB/s Using "iostat", I confirmed that the I/O was spread mostly evenly across both controllers. Something is not right in btrfs. |
| gus3 Jul 30, 2010 12:51 AM EDT |
Okay, does someone have a crow buffet where I can dish up a healthy serving for myself? It seems btrfs does have RAID striping support built-in: https://btrfs.wiki.kernel.org/index.php/Using_Btrfs_with_Mul... After following the advice from that page, I re-ran my benchmarks (under slightly degraded conditions, that is, with full desktop rather than runlevel 1) and got the following results: btrfs 5 threads, 39-43 MB/s btrfs 20 threads, 91-119 MB/s Adding "-o compress-force" got the following: btrfs 5 threads, 39-45 MB/s btrfs 20 threads, 95-132 MB/s There is still work to be done with btrfs, but these numbers are much better than I expected. I will therefore edit my 2010-07-28 benchmarks comment. |
| herzeleid Jul 30, 2010 1:42 PM EDT |
Very interesting! I'm hopeful they'll be able to wring even better performance out of btrfs in the next 12 months. |
| chalbersma Jul 30, 2010 3:10 PM EDT |
You know I'm wondering what tuning options they set for the ZFS benchmarks.... |
| gus3 Jul 30, 2010 5:02 PM EDT |
But XFS with an external journal and deadline scheduling, still beats the pants off everything else. |
Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]
Becoming a member of LXer is easy and free. Join Us!