Re: Massive filesystem corruption since kernel 5.2 (ARCH)

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

On 2019/8/1 下午4:07, Swâmi Petaramesh wrote:
> On 8/1/19 8:36 AM, Qu Wenruo wrote:
>> Could you give more detailed history, including each reboot?
>> Like:
>>
>> CASE 1
>> # Upgrade kernel (running 5.1)
>> # Reboot
>> # Kernel mount failure (running 5.2)
>
> No, it never was a “kernel mount failure”, it was more of :
>
> - Running 5.1 OK
>
> - Upgrade to 5.2
>
> - Reboot without noticing problem on kernel 5.2.1-arch1-1
>
> - Performed usual remote rsync backup using kernel 5.2.1-arch1-1 WITHOUT
> any error at 23:20 on july, 16
>
> - Quite unfortunately I do not backup /var/log in frequent rsync backups...
>
> - Machine does its usual cronned snapper snapshots auto-delete
>
> - Turned off machine for the night

So it looks like damage is done at this point.

It looks like some data doesn't reach disk properly.

>
> - Next days, boot machine as usual (without paying attention to
> scrolling messages)
>
> - Machine boots. Cinnamon GUI fails loading. Wonders. Reboot.
>
> - Notice BTRFS error messages on console at boot. Still no GUI.
>
> - Reboot in systemd rescue mode. Run "btrfs check -f" in read-only mode.
>
> - Get LOADS of error messages.
>
> - Tells myself « Jeez the damn thing screwed up ! »
>
> - Reboot in multi-user.target console mode
>
> - Notice BTRFS errors again.
>
> - Connect external USB HD for performing an emergency full backup of
> what can be.
>
> - Lack enough space on external USB HD. Delete a load of old snapshots
> to make enough space.

Indeed looks like some btrfs bug in 5.2 now.

So far, the common workload involves snapshot deletion and proper shutdown.

I need to double check the snapshot deletion with dm-logwrites.

Thanks for the detailed history, this helps more than the btrfs
check/log message.

Thanks,
Qu