On Tue, May 01, 2018 at 04:02:34PM +0200, David Sterba wrote:
> On Fri, Apr 27, 2018 at 12:21:49PM +0300, Nikolay Borisov wrote:
> > After investigating crashes on generic/176 it turned that the culprit in
> > fact
> > is the random failure induced by generic/019. As it happens, if on unmount
> >
On Tue, May 08, 2018 at 08:16:37AM +0300, Nikolay Borisov wrote:
> >> properly cleanup delalloc inodes and as a result cleans up the code a bit.
> >>
> >> I've given it a good bashing through xfstest (4 full xfstest cycles + 100
> >> iterations of generic/475 since it was hitting some early asser
On 8.05.2018 01:58, David Sterba wrote:
> On Fri, Apr 27, 2018 at 12:21:49PM +0300, Nikolay Borisov wrote:
>> After investigating crashes on generic/176 it turned that the culprit in fact
>> is the random failure induced by generic/019. As it happens, if on unmount
>> the
>> filesystem is in B
On Fri, Apr 27, 2018 at 12:21:49PM +0300, Nikolay Borisov wrote:
> After investigating crashes on generic/176 it turned that the culprit in fact
> is the random failure induced by generic/019. As it happens, if on unmount
> the
> filesystem is in BTRFS_FS_STATE_ERROR then btrfs_error_commit_super
On Fri, Apr 27, 2018 at 12:21:49PM +0300, Nikolay Borisov wrote:
> After investigating crashes on generic/176 it turned that the culprit in fact
> is the random failure induced by generic/019. As it happens, if on unmount
> the
> filesystem is in BTRFS_FS_STATE_ERROR then btrfs_error_commit_super