> On 1 Aug 2019, at 4:43 PM, Qu Wenruo <quwenruo.btrfs@xxxxxxx> 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
