On 2019/1/5 下午8:30, Giuseppe Della Bianca wrote: > In data venerdì 4 gennaio 2019 21:34:03 CET, Jeff Mahoney ha scritto: > ]zac[ >>> >>> root 17133 17127 0 17:17 ? 00:00:00 btrfs subvolume sync -s 2 >>> / >>> tmp/tmp.p9SiQ1GnpV >>> >>> cat /proc/17133/stack >>> [<0>] hrtimer_nanosleep+0xce/0x1e0 >>> [<0>] __x64_sys_nanosleep+0x77/0xa0 >>> [<0>] do_syscall_64+0x5b/0x160 >>> [<0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 >>> [<0>] 0xffffffffffffffff >> >> Ok, so this is it just sleeping between tree searches. > ]zac[ >> This part is actually important since we see below that we're searching >> for bytenr 76428623872 which, if present, would be in the cut portion of >> your log. > ]zac[ > > If you want, I can send you the full log (very long). > From what you wrote below it seems to me that you do not need it > > ]zac] >> >> This is the more important part. The file system has gone read-only due >> to a missing extent backref. This is corruption. > > Yes, but this is an autocorruption of btrfs, which occurred (it seems to me), > during a cleanup after a deleting of a snapshoot of an operating system > installation (perhaps interrupted by an umount).
Do you have a full history of the kernel versions? I'm not sure when the corruption happened. It's completely possible that some old kernel caused the corruption but not exposed until now. Also, would you please run "btrfs check --readonly" on the fs? It should show all corruption. And if "btrfs check" shows no corruption, then it's completely a bug in that given kernel (and even current kernel). Thanks, Qu > >> It also means that the subvolume is never going to disappear during this >> mount and 'btrfs subvol sync' will wait forever. > ]zac[ > > In my opinion this is bad. > > The infinite wait occurs during the execution of a backup script, so I will > have to find a bypass even for this problem (the sync was a patch to another > autocorruption problem). > > Gdb > >
signature.asc
Description: OpenPGP digital signature
