4 ms·
They are both check-summed and copy-on-write. This is great for consistency and storage, but the first part somewhat sucks if you've built it into your layer a
by gopalv 13y ago
They are both check-summed and copy-on-write.
This is great for consistency and storage, but the first part somewhat sucks if you've built it into your layer as well (like hadoop fs). And it makes writes & reads a tiny bit slower than it should be.
They have fat xattr inodes, which is great if you use it - but useless if something like SELinux means nothing to you.
The point where they truly excel is in a multi-disk scenario.
And in that land, the zpool array implementation makes it awesome to introduce an SSD+HD mixture with nearly the best of both systems.
BTRFS doesn't have that yet (well, bcache on the lower layer, perhaps).
But as someone who's fired up debugfs a bit too many times, if you really don't know which one you need, pick the one that ships with your distro!
- smilliken 13y ago> And in that land, the zpool array implementation makes it awesome to introduce an SSD+HD mixture with nearly the best of both systems. With an array of half SSDs and half HDs, can I configure ZFS so that I never hit the IOPS bottleneck of the HDs? How do you recommend configuring the array?
- gopalv 13y agoI have never used a setup like that - all I've done is throw an SSD in front of 3 disks. That said, the zfs log and zfs cache command supports mirror disks for log and allows more than 1 cache per pool. Using more than 1 SSD as a cache (and of course, using mirrored logs for safety) would be recommended if you had a production box with this. To repeat, I have never tried ZFS-on-Linux anywhere near a production setup - but if I had to, I would use multiple SSDs just in case one locks up its firmware.