Re: assertion failed: last_size == new_size, file: fs/btrfs/inode.c
On Thu, Mar 09, 2017 at 03:24:21PM +0100, David Sterba wrote: > 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, > > Where did that change? I thought that inline extent can represent only > the entire file, so any mixing of extents does not make sense to me. > Do you refer to some intermediate state where the file is being > converted from inline to non-inline, thus we could see both types of > extents at some point? > We could get that by doing the following step, xfs_io -f -c "pwrite 0 8" foo xfs_io -f -c "falloc 4 8188" foo offset 4 is rounded down to offset 0 and before allocating blocks we wait for any dirty stuff starting at offset 0, since the isize is not yet updated, the inline extent is created as is again. Now we have an inline extent from 0 to 8 and a prealloc extent from 4096 to 8192, AND its isize is 8192. Thanks, -liubo -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: assertion failed: last_size == new_size, file: fs/btrfs/inode.c
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, Where did that change? I thought that inline extent can represent only the entire file, so any mixing of extents does not make sense to me. Do you refer to some intermediate state where the file is being converted from inline to non-inline, thus we could see both types of extents at some point? > so we don't need this ASSERT() anymore, will send a patch to > remove it. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: assertion failed: last_size == new_size, file: fs/btrfs/inode.c
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: assertion failed: last_size == new_size, file: fs/btrfs/inode.c
On Fri, Mar 03, 2017 at 01:04:39PM -0500, Dave Jones wrote:
> 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!
I think it's because we do ASSERT() like,
#ifdef CONFIG_BTRFS_ASSERT
__cold
static inline void assfail(char *expr, char *file, int line)
{
pr_err("assertion failed: %s, file: %s, line: %d\n",
expr, file, line);
BUG();
}
#define ASSERT(expr)\
(likely(expr) ? (void)0 : assfail(#expr, __FILE__, __LINE__))
#else
#define ASSERT(expr)((void)0)
#endif
Thanks,
-liubo
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: assertion failed: last_size == new_size, file: fs/btrfs/inode.c
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. Thanks, -liubo -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: assertion failed: last_size == new_size, file: fs/btrfs/inode.c
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. Thanks, -liubo -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: assertion failed: last_size == new_size, file: fs/btrfs/inode.c
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: assertion failed: last_size == new_size, file: fs/btrfs/inode.c
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/ Thanks, -liubo -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: assertion failed: last_size == new_size, file: fs/btrfs/inode.c
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.) Thanks, -liubo > Dave > > assertion failed: last_size == new_size, file: fs/btrfs/inode.c, line: 4619 > [ cut here ] > kernel BUG at fs/btrfs/ctree.h:3422! > invalid opcode: [#1] PREEMPT SMP DEBUG_PAGEALLOC > CPU: 3 PID: 15655 Comm: trinity-c25 Not tainted 4.10.0-think+ #9 > task: 8804fb128040 task.stack: c90008534000 > RIP: 0010:assfail.constprop.74+0x1c/0x1e [btrfs] > RSP: 0018:c90008537c58 EFLAGS: 00010282 > RAX: 004b RBX: 1000 RCX: 0001 > RDX: RSI: 81cb4173 RDI: > RBP: c90008537c58 R08: R09: 0001 > R10: R11: R12: 8804fe821348 > R13: 88047eb5bb88 R14: 8804fe821348 R15: 0005 > FS: 7f99b77a6b40() GS:880507e0() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: 7f99b77a9010 CR3: 00048c4bf000 CR4: 001406e0 > Call Trace: > btrfs_truncate_inode_items+0xbee/0x11e0 [btrfs] > ? debug_smp_processor_id+0x17/0x20 > btrfs_truncate+0x102/0x2a0 [btrfs] > btrfs_setattr+0x246/0x3b0 [btrfs] > notify_change+0x256/0x440 > do_truncate+0x73/0xc0 > do_sys_ftruncate.constprop.19+0x111/0x170 > ? __this_cpu_preempt_check+0x13/0x20 > SyS_ftruncate+0xe/0x10 > do_syscall_64+0x66/0x1d0 > entry_SYSCALL64_slow_path+0x25/0x25 > RIP: 0033:0x7f99b70d00f9 > RSP: 002b:7ffd992b7768 EFLAGS: 0246 > ORIG_RAX: 004d > RAX: ffda RBX: 004d RCX: 7f99b70d00f9 > RDX: 0003680201d80849 RSI: 0d95 RDI: 0187 > RBP: 7f99b76f R08: 0001 R09: 0fd7 > R10: 0006 R11: 0246 R12: 0002 > R13: 7f99b76f0048 R14: 7f99b77a6ad8 R15: 7f99b76f > Code: 48 83 c4 18 5b 41 5c 41 5d 41 5e 41 5f 5d c3 55 89 f1 48 c7 c2 b1 f7 11 > a0 48 89 fe 48 89 e5 48 c7 c7 f0 52 12 a0 e8 03 b7 0b e1 <0f> 0b 55 89 f1 48 > c7 c2 a8 fa 11 a0 48 89 fe 48 89 e5 48 c7 c7 > RIP: assfail.constprop.74+0x1c/0x1e [btrfs] RSP: c90008537c58 > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: assertion failed: last_size == new_size, file: fs/btrfs/inode.c
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. Dave -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
assertion failed: last_size == new_size, file: fs/btrfs/inode.c
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. Dave assertion failed: last_size == new_size, file: fs/btrfs/inode.c, line: 4619 [ cut here ] kernel BUG at fs/btrfs/ctree.h:3422! invalid opcode: [#1] PREEMPT SMP DEBUG_PAGEALLOC CPU: 3 PID: 15655 Comm: trinity-c25 Not tainted 4.10.0-think+ #9 task: 8804fb128040 task.stack: c90008534000 RIP: 0010:assfail.constprop.74+0x1c/0x1e [btrfs] RSP: 0018:c90008537c58 EFLAGS: 00010282 RAX: 004b RBX: 1000 RCX: 0001 RDX: RSI: 81cb4173 RDI: RBP: c90008537c58 R08: R09: 0001 R10: R11: R12: 8804fe821348 R13: 88047eb5bb88 R14: 8804fe821348 R15: 0005 FS: 7f99b77a6b40() GS:880507e0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7f99b77a9010 CR3: 00048c4bf000 CR4: 001406e0 Call Trace: btrfs_truncate_inode_items+0xbee/0x11e0 [btrfs] ? debug_smp_processor_id+0x17/0x20 btrfs_truncate+0x102/0x2a0 [btrfs] btrfs_setattr+0x246/0x3b0 [btrfs] notify_change+0x256/0x440 do_truncate+0x73/0xc0 do_sys_ftruncate.constprop.19+0x111/0x170 ? __this_cpu_preempt_check+0x13/0x20 SyS_ftruncate+0xe/0x10 do_syscall_64+0x66/0x1d0 entry_SYSCALL64_slow_path+0x25/0x25 RIP: 0033:0x7f99b70d00f9 RSP: 002b:7ffd992b7768 EFLAGS: 0246 ORIG_RAX: 004d RAX: ffda RBX: 004d RCX: 7f99b70d00f9 RDX: 0003680201d80849 RSI: 0d95 RDI: 0187 RBP: 7f99b76f R08: 0001 R09: 0fd7 R10: 0006 R11: 0246 R12: 0002 R13: 7f99b76f0048 R14: 7f99b77a6ad8 R15: 7f99b76f Code: 48 83 c4 18 5b 41 5c 41 5d 41 5e 41 5f 5d c3 55 89 f1 48 c7 c2 b1 f7 11 a0 48 89 fe 48 89 e5 48 c7 c7 f0 52 12 a0 e8 03 b7 0b e1 <0f> 0b 55 89 f1 48 c7 c2 a8 fa 11 a0 48 89 fe 48 89 e5 48 c7 c7 RIP: assfail.constprop.74+0x1c/0x1e [btrfs] RSP: c90008537c58 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
