> On 1 Aug 2019, at 4:43 PM, Qu Wenruo <quwenruo.bt...@gmx.com> wrote:
>
>
>
> 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.
>
Yep I suspect the same.
Swami, Do you have the kernel logs around this time frame?
>>
>> - 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
