On 31 December 2016 at 15:42, Carlos E. R.
Did you do all of the above before trying btrfs check --repair?
Well, I find that procedure too complex. One of the reasons I refuse to use btrfs.
While I understand that, I see the problem as the price of progress The same way that the correct management of an mdraid or LVM volume group requires more tooling and expertise than a traditional partition, btrfs (which is a filesystem with functionality matching and exceeding in some areas those of LVM and mdraid) has a similar requirement for more tooling and expertise when resolving issues on it I think if people use btrfs and expect a 'basic' ext4-like experience, then they're going to be sorely disappointed. But on the flipside, the additional features of btrfs enable very broad features with a system-wide impact, such as snapshot and restore, or transactional updates. Clinging to 'traditional' filesystems indefinately holds you back from experiencing modern capabilities you can't get on Linux any other way And before people point out that ZFS already has the features that enable this stuff with btrfs - yes, you're right. But ZFS has licencing issues. And even if it didn't, ZFS has a practically identical level of tooling and expertise required - you cannot just go doing a fsck on zfs and expecting it to work either. And before people point out that XFS is on the way to having some of those features - sure, and when it does, expect the tooling and expertise problem to raise even higher - XFS already has more concerns with it's repair than traditional ext, which is why fsck for xfs does nothing at all and, just like btrfs, you need to use different tools.
IMO, btrfs should have a single tool that automatically analyzes a btrfs filesystem and automatically decides on the best course of action, perhaps asking the user some simple questions.
That's a good idea, +1 from me, know anyone who could write it?
You mention, for instance:
mount -o ro,recovery to mount a filesystem with issues
But you need another running system to do that... and Leap doesn't have a rescue image anymore. The OP mentions having to use a Debian live image instead.
A Leap system that fails to boot its btrfs root automatically goes into its rescue system - which has the tooling required And we have a Tumbleweed Live Rescue Image So this is not a problem and you're straying into territory that makes it sound like you're just searching for things to complain about :)
A lot of the horror stories I've seen regarding btrfs are due to misuse / abuse of btrfs far more than actual issues or bugs,
Well, you can not expect users to be knowledgeable about filesystem nuances, specially being btrfs that advanced and complex.
Sure I can - there is lots of good documentation about it out these days: https://www.suse.com/documentation/sles-12/stor_admin/data/sec_filesystems_m... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org