Re: btrfs partition converted from ext4 becomes read-only minutes after booting: WARNING: CPU: 2 PID: 2777 at ../fs/btrfs/super.c:260 __btrfs_abort_transaction+0x4b/0x120

[Qu Wenruo <quwenruo@cn.fujitsu.com>]

Robert Munteanu wrote on 2015/07/30 16:16 +0300:
>> The disk image (still) contains sensitive data so I can't share it
>> unfortunately. What I can do is keep it untouched until Friday evening
>> EEST and run any debugging commands that you might think of to trace
>> down the source of the errors. Alternatively, if there's an easy and
>> safe fix and debugging is not worth it, I'm happy to apply that fix as
>> well.
>
>
> Based on the results of running btrfs check --repair on an image file
> taken from the actual disk I ran a btrfs check --repair on the
> physical partition
>
> The output was ( again, re-typed so might contain typos )
>
> # btfrs check --repair /dev/sda1
> enabling repair mode
> repair mode will force to clear out log tree, Are you sure [y/N]: y
> Checking filesystem on /dev/sda1
> UUID: ...
> checking extents
> Fixed 0 roots.
> checking free space cache.
> cache and super generation don't match, space cache will be invalidated
> checking fs roots
> Fixed discount file extends for inode: 14214570 in root: 5
> root 5 inode 14214570 errors 100, file extend discount
> Found file extent holes:
> Fixed discount file extends for inode: 14214570 in root: 5
> root 5 inode 14214570 errors 100, file extend discount
> Found file extent holes:
Any full output about it?

Not sure if it real loops, but maybe the inode number changed in later 
output?

Thanks,
Qu

>
> The previous 3 lines repeat a lot, every 10 seconds maybe. After 30
> minutes I got bored and stopped the process, as it looks like it's
> looping at some condition that without making any progress. At any
> rate, something worked well and I can now mount the volume again from
> the rescue disk and boot from a read-only snapshot.
>
> Cheers,
>
> Robert
>