Il giorno mar 8 gen 2019 alle ore 13:29 Filipe Manana
ha scritto:
]zac[
> > 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 sup
Il giorno mar 8 gen 2019 alle ore 00:11 Filipe Manana
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]
> >
Il giorno lun 7 gen 2019 alle ore 14:31 Qu Wenruo
ha scritto:
]zac[
> >> It's relatively common that extent tree get corrupted before and some
> >> unfortunately operation touching the corrupted extent tree triggered
> >> some user affecting error.
> >
> > Yes, I understand, but the use of filesyt
Il giorno lun 7 gen 2019 alle ore 00:56 Qu Wenruo
ha scritto:
]zac[
> > I am quite convinced that it happens during the snapshot delete and the
> > subsequent cleanup.
> > And maybe even the umount is part of the problem.
>
> No, I mean the corruption which finally results the hang was there for a
2017-07-16 18:06 GMT+02:00 Marc MERLIN :
> On Sun, Jul 16, 2017 at 04:01:53PM +0200, Giuseppe Della Bianca wrote:
>> > On Fri, Jul 14, 2017 at 06:22:16PM -0700, Marc MERLIN wrote:
>> > > Dear Chris and other developers,
>> ]zac[
>> > Others on this thread with the same error: did anyone recover fro
