3 ms·
Lots of gotchas yes, but it's about as rare to see data loss on Btrfs as it is on say linux-raid@ list for mdadm or LVM and those are much more mature. More oft
by cmurf 11y ago
Lots of gotchas yes, but it's about as rare to see data loss on Btrfs as it is on say linux-raid@ list for mdadm or LVM and those are much more mature. More often is the case of some suboptimal behavior and the recommendation to get the data off the volume and onto a newly created one. Very inconvenient for some users to be sure, but also not data loss. About the worst I've seen lately that wasn't hardware related needed data scraped using btrfs restore (the tool the extracts data from an unmountable filesystem).
- rleigh 11y agoThis hasn't been my experience. When an md array has lost a disk, I have added a new one and the array has transparently resynched in the background. No interruption in service or loss of data. When a Btrfs array has lost a disk, Btrfs oopsed the kernel, and stopped working. When I rebooted with the hardware problem resolved, it toasted both the outdated mirror and the up-to-date disk, causing irretrievable dataloss. Any attempt to boot the system led to Btrfs causing an immediate kernel panic. I had to put the disks into a system without Btrfs kernel support and use dd to zero out the Btrfs partitions before I could use them again. That was admittedly a few years back, but it's still a long way from production use in many respects, while ZFS has been in production use for years and is well documented, has good tools, and is very robust. After several years of Btrfs problems, I gave up on it and moved to ZFS, initially on Linux and then on FreeBSD due to it being better integrated.
- Filligree 11y agoJust incidentally, 'wipefs -a' should clear out the partitions in a much speedier manner.