3 ms·

This test is using "single" mode -- which is basically RAID0 variant without striping. It is slower than RAID0 in many scenarios, because sequential data goes t

by theamk 4y ago

This test is using "single" mode -- which is basically RAID0 variant without striping. It is slower than RAID0 in many scenarios, because sequential data goes to one disk at a time, but it has an advantage that in case of disk loss, only fraction of files is damaged. ZFS does not really have "single" mode equivalent. The closest it has is RAID0 - it gets higher speed but all data will be lost if any drive is damaged, as data is "spread" across all disks. (It is actually hard for me to imagine why would one use that "single" mode in practice. If your data is valuable, but a slightly bigger disk and enable proper parity so _no_ data is lost (6tb vs 4tb drive difference is <$30 nowadays). If your data is not valuable, go properly striped RAID0 and enjoy speed advantage. The only reason to go with "single" is if you have a bunch of existing drives that you don't want to use, _and_ you don't care about data integrity. But even then I'd argue that MergerFS that author uses (or mhddfs) would be more robust.)

xk3 4y ago
> It is actually hard for me to imagine why would one use that "single" mode in practice. Yes, this is what I'm starting to discover also. Because single mode is the default I assumed for the last 9 months that it would provide similar guarantees as MergerFS. But that was my incorrect assumption. As a result of this experiment I'm investigating MergerFS and I will likely switch from multi-disk btrfs to an array of single-disk btrfs under MergerFS. edit: actually I'm not sure I would convert my array to raid0 because the speeds I'm getting are okay. 20% of data is better than nothing. I did the same with raid0 data profile and only inlined extent files were readable
- theamk 4y ago
  I used to run a manual version of mergerfs (before it existed) - a bunch of disks, files were manually copied into one of the disks, and scripts maintained "tree of symlinks" which pointed to all the files. Later on, I needed to export this as SMB, so I've added de-referencing overlayfs to generate a single huge disk, and exported that. Worked pretty well and while manual placing required some effort, I could keep similar files together. Later on I ended up buying few more disks and creating large ZFS RAID6 array.. And it "just works" now, no need for custom scripts.

by theamk 4y ago

xk3 4y ago

> It is actually hard for me to imagine why would one use that "single" mode in practice. Yes, this is what I'm starting to discover also. Because single mode is the default I assumed for the last 9 months that it would provide similar guarantees as MergerFS. But that was my incorrect assumption. As a result of this experiment I'm investigating MergerFS and I will likely switch from multi-disk btrfs to an array of single-disk btrfs under MergerFS. edit: actually I'm not sure I would convert my array to raid0 because the speeds I'm getting are okay. 20% of data is better than nothing. I did the same with raid0 data profile and only inlined extent files were readable

theamk 4y ago
I used to run a manual version of mergerfs (before it existed) - a bunch of disks, files were manually copied into one of the disks, and scripts maintained "tree of symlinks" which pointed to all the files. Later on, I needed to export this as SMB, so I've added de-referencing overlayfs to generate a single huge disk, and exported that. Worked pretty well and while manual placing required some effort, I could keep similar files together. Later on I ended up buying few more disks and creating large ZFS RAID6 array.. And it "just works" now, no need for custom scripts.