Failsystem turns to readonly after any btrfs activity related to snapshot. This could be caused by running zypper up, or happens in 3-10 minutes after booting even without any interaction with the system. Booting with official 3.11 kernel does not solve the problem.
The problem was confirmed on laptop and desktop.
Googling does not bring any solution.
On 2014-10-19 16:16, saraksh wrote:
>
> uname -a
> Linux 3.17.1-2.g5c4d099-desktop #1 SMP PREEMPT Sat Oct 18 23:36:23 UTC
> 2014 (5c4d099) x86_64 x86_64 x86_64 GNU/Linux
>
> dmesg | grep error
> 208.614518] BTRFS: error (device sda2) in update_ref_for_cow:1018:
> errno=-30 Readonly filesystem
> 208.614544] BTRFS: Transaction aborted (error -30)
> 208.614981] BTRFS error (device sda2): Error removing orphan entry,
> stopping orphan cleanup
Did you try to fsck it?
Another comment: When pasting here computer commands and such, please
use a CODE BLOCK, so that the forum software doesn’t do silly things
like converting URLS to tiny urls or otherwise hide or alter the
commands you entered. You get them by clicking on the ‘#’ button in the
forum editor. http://susepaste.org/images/15093674.jpg
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
Having a similar issue with a btrfs drive no longer booting, due to orphans. It gives error codes -5 and -22. Under 3.11 the kernel mod for btrfs panics and dies, and under anything from 3.16+ the drive always mounts ro with that error. Tried zeroing logs, running a scrub, chunk recover didn’t do anything, and I’m of course holding off doing a check --repair unless its a matter of last resort.
The contents of the drive are already backed up, at least.
The worst part is, though, that I cannot for sure know I’m using the right set of btrfsprogs against it, because my main desktop runs Arch and even it does not yet have 3.17 (at least by default).
Sure this is btrfs bug in 3.17 kernel, as simptoms are equal on laptop and desktop after uppgrading to 3.17. Thats mean that 3.17 are not ready for upcomming 13.2 opensuse release
Do NOT run “btrfs check --repair” if you value your data. The only safe way to fix this is to backup all the data, then recreate btrfs filesystem and restore backup (using kernel 3.16).
PS After hitting this bug three times (of which one happened during booting into freshly restored system after a previous corruption), I gave up and rolled back to 3.16
Just one note, 3.17 kernel destroyed btrfs on both machines I’ve had it on. And I rollbacked to 3.16.6 and it also had some issues with btrfs, like hangs crashes mentioned in dmesg etc. So I rollbacked to 3.16.3 and this one seems to be working. So if somebody uses btrfs, don’t use newer kernel than 3.16.3.
> Just one note, 3.17 kernel destroyed btrfs on both machines I’ve had it
> on. And I rollbacked to 3.16.6 and it also had some issues with btrfs,
> like hangs crashes mentioned in dmesg etc. So I rollbacked to 3.16.3 and
> this one seems to be working. So if somebody uses btrfs, don’t use newer
> kernel than 3.16.3.
Again:
Please report this in Bugzilla, ASAP, or nobody will repair the kernel.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
