On Tue, Feb 28, 2017 at 05:12:01PM -0800, Liu Bo wrote:
> On Mon, Feb 27, 2017 at 11:23:42AM -0500, Dave Jones wrote:
> > On Mon, Feb 27, 2017 at 07:53:48AM -0800, Liu Bo wrote:
> > > On Sun, Feb 26, 2017 at 07:18:42PM -0500, Dave Jones wrote:
> > > > Hitting this fairly frequently.. I'm not sure if this is the same bug
> > I've
> > > > been hitting occasionally since 4.9. The assertion looks new to me at
> > least.
> > > >
> > >
> > > It was recently introduced by my commit and used to catch data loss at
> > truncate.
> > >
> > > Were you running the test with a mkfs.btrfs -O NO_HOLES?
> > > (We just queued a fix for the NO_HOLES case in btrfs-next.)
> >
> > No, a fs created with default mkfs.btrfs options.
>
> I have this patch[1] to fix a bug which results in file hole extent, and this
> bug could lead us to hit the assertion.
>
> Would you try to run the test w/ it, please?
>
> [1]: https://patchwork.kernel.org/patch/9597281/
Made no difference. Still see the same trace & assertion.
Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
