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). > 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
