On Tue, Jan 8, 2019 at 12:14 PM gius db <gius...@gmail.com> wrote: > > Il giorno mar 8 gen 2019 alle ore 00:11 Filipe Manana > <fdman...@gmail.com> ha scritto: > > ]zac[ > > > [ 1558.056931] Call Trace: > > > [ 1558.057011] __btrfs_run_delayed_refs+0x216/0x10b0 [btrfs] > > > [ 1558.057011] ? btrfs_free_tree_block+0x82/0x2c0 [btrfs] > > > [ 1558.057011] btrfs_run_delayed_refs+0x78/0x180 [btrfs] > > > [ 1558.057011] btrfs_should_end_transaction+0x3e/0x60 [btrfs] > > > [ 1558.057011] btrfs_drop_snapshot+0x3cf/0x820 [btrfs] > > > [ 1558.057011] ? btree_submit_bio_start+0x20/0x20 [btrfs] > > > [ 1558.057011] btrfs_clean_one_deleted_snapshot+0xba/0xe0 [btrfs] > > > [ 1558.057011] cleaner_kthread+0x129/0x160 [btrfs] > > > [ 1558.057011] kthread+0x112/0x130 > > > [ 1558.057011] ? kthread_create_worker_on_cpu+0x70/0x70 > > > [ 1558.057011] ret_from_fork+0x35/0x40 > > > [ 1558.057011] Code: 10 48 8b 40 50 f0 48 0f ba a8 30 23 00 00 02 0f 92 > > > c0 41 > > > 59 84 c0 0f 85 cc a4 09 00 44 89 ee 48 c7 c7 98 9e 75 c0 e8 58 33 a0 e7 > > > <0f> > > > 0b e9 b6 a4 09 00 48 89 df e8 bf 0c ff ff 49 8b 74 24 28 4d > > > [ 1558.057011] ---[ end trace c4eefd1fdc016ceb ]--- > > > [ 1558.057734] BTRFS: error (device sda3) in __btrfs_free_extent:7007: > > > errno=-2 No such entry > > > [ 1558.057742] BTRFS info (device sda3): forced readonly > > > [ 1558.057757] BTRFS: error (device sda3) in btrfs_run_delayed_refs:3076: > > > errno=-2 No such entry > > > Very recently, a fix for this went into kernel 5.0-rc1: > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0568e82dbe2510fc1fa664f58e5c997d3f1e649e > ]zac[ > > Thanks for the answer. > > If I understand correctly the problem is caused by the concurrence of > the cleanup process (which is started a few seconds after the end of > the snapshot deletion) with the other operations on the filesystem. > > It matches what I seem to have noticed (problem that occurs after a > snapshot deletion, occurs randomly due to a race condition, etc..). > > P.S. I suppose the 4.x.x kernel will not be corrected.
Why do you suppose that? The patch has a tag (see the bottom of the changelog) to signal it should be added to stable kernels 4.4+: CC: sta...@vger.kernel.org # 4.4+ -- Filipe David Manana, “Whether you think you can, or you think you can't — you're right.”
