| 1 |
On Sat, Oct 7, 2017 at 12:12 PM, Neil Bothwick <neil@××××××××××.uk> wrote: |
| 2 |
> On Sat, 7 Oct 2017 07:06:24 -0400, Rich Freeman wrote: |
| 3 |
> |
| 4 |
>> btrfs isn't horrible, but it basically hasn't been optimized at all. |
| 5 |
>> The developers are mainly focused on getting it to not destroy your |
| 6 |
>> data, with mixed success. An obvious example of this is that if you |
| 7 |
>> read a file from a pair of mirrors, the filesystem decides which drive |
| 8 |
>> in the pair to use based on whether the PID doing the read is even or |
| 9 |
>> odd. |
| 10 |
>> |
| 11 |
>> Fundamentally I haven't seen any arguments as to why btrfs should be |
| 12 |
>> any worse than zfs. It just hasn't been implemented completely. But, |
| 13 |
>> if you want a filesystem today and not in 10 years you need to take |
| 14 |
>> that into account. |
| 15 |
> |
| 16 |
> I switched from ZFS to btrfs a few years ago when it appeared that ZFS |
| 17 |
> wasn't really going anywhere while btrfs was under active development. It |
| 18 |
> looks like I backed the wrong horse and should investigate switching back. |
| 19 |
> |
| 20 |
|
| 21 |
Well, they're both FOSS, and honestly I feel like btrfs has more |
| 22 |
potential, but zfs is much more usable today. Btrfs has features |
| 23 |
which make it a lot more flexible in smaller installs (like being able |
| 24 |
to remove disks, and treating snapshots as full citizens). However, |
| 25 |
zfs generally can get the job done and is far less likely to eat your |
| 26 |
data in the process. I was also a btrfs hold-out for a long time, and |
| 27 |
I look forward to using it again some day, but it hasn't matured like |
| 28 |
I originally hoped. |
| 29 |
|
| 30 |
-- |
| 31 |
Rich |
Archives