On Thu, Mar 02, 2017 at 06:04:33PM -0800, Liu Bo wrote: > On Thu, Mar 02, 2017 at 07:58:01AM -0800, Liu Bo wrote: > > On Wed, Mar 01, 2017 at 03:03:19PM -0500, Dave Jones wrote: > > > 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. > > > > Some updates here, I've got it reproduced, somehow a corner case ends up > > with a inline file extent following by some pre-alloc extents, along the > > way, isize also got updated unexpectedly. Will try to narrow it down. > > > > I realized that btrfs now could tolerate files that mix inline extents with > regular extents, so we don't need this ASSERT() anymore, will send a patch to > remove it. note that as well as the assertion trigger, it's always immediately followed by kernel BUG at fs/btrfs/ctree.h:3422! Dave -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
