assertion failed: last_size == new_size, file: fs/btrfs/inode.c

assertion failed: last_size == new_size, file: fs/btrfs/inode.c

[Dave Jones]

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: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
CPU: 3 PID: 15655 Comm: trinity-c25 Not tainted 4.10.0-think+ #9 
task: ffff8804fb128040 task.stack: ffffc90008534000
RIP: 0010:assfail.constprop.74+0x1c/0x1e [btrfs]
RSP: 0018:ffffc90008537c58 EFLAGS: 00010282
RAX: 000000000000004b RBX: 0000000000001000 RCX: 0000000000000001
RDX: 0000000000000000 RSI: ffffffff81cb4173 RDI: 00000000ffffffff
RBP: ffffc90008537c58 R08: 0000000000000000 R09: 0000000000000001
R10: 0000000000000000 R11: 0000000000000000 R12: ffff8804fe821348
R13: ffff88047eb5bb88 R14: ffff8804fe821348 R15: 0000000000000005
FS:  00007f99b77a6b40(0000) GS:ffff880507e00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f99b77a9010 CR3: 000000048c4bf000 CR4: 00000000001406e0
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:00007ffd992b7768 EFLAGS: 00000246
 ORIG_RAX: 000000000000004d
RAX: ffffffffffffffda RBX: 000000000000004d RCX: 00007f99b70d00f9
RDX: 0003680201d80849 RSI: 0000000000000d95 RDI: 0000000000000187
RBP: 00007f99b76f0000 R08: 0000000000000001 R09: 0000000000000fd7
R10: 0000000000000006 R11: 0000000000000246 R12: 0000000000000002
R13: 00007f99b76f0048 R14: 00007f99b77a6ad8 R15: 00007f99b76f0000
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: ffffc90008537c58

Re: assertion failed: last_size == new_size, file: fs/btrfs/inode.c

[Liu Bo]

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: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
> CPU: 3 PID: 15655 Comm: trinity-c25 Not tainted 4.10.0-think+ #9 
> task: ffff8804fb128040 task.stack: ffffc90008534000
> RIP: 0010:assfail.constprop.74+0x1c/0x1e [btrfs]
> RSP: 0018:ffffc90008537c58 EFLAGS: 00010282
> RAX: 000000000000004b RBX: 0000000000001000 RCX: 0000000000000001
> RDX: 0000000000000000 RSI: ffffffff81cb4173 RDI: 00000000ffffffff
> RBP: ffffc90008537c58 R08: 0000000000000000 R09: 0000000000000001
> R10: 0000000000000000 R11: 0000000000000000 R12: ffff8804fe821348
> R13: ffff88047eb5bb88 R14: ffff8804fe821348 R15: 0000000000000005
> FS:  00007f99b77a6b40(0000) GS:ffff880507e00000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007f99b77a9010 CR3: 000000048c4bf000 CR4: 00000000001406e0
> 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:00007ffd992b7768 EFLAGS: 00000246
>  ORIG_RAX: 000000000000004d
> RAX: ffffffffffffffda RBX: 000000000000004d RCX: 00007f99b70d00f9
> RDX: 0003680201d80849 RSI: 0000000000000d95 RDI: 0000000000000187
> RBP: 00007f99b76f0000 R08: 0000000000000001 R09: 0000000000000fd7
> R10: 0000000000000006 R11: 0000000000000246 R12: 0000000000000002
> R13: 00007f99b76f0048 R14: 00007f99b77a6ad8 R15: 00007f99b76f0000
> 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: ffffc90008537c58
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@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

[Dave Jones]

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

Re: assertion failed: last_size == new_size, file: fs/btrfs/inode.c

[Liu Bo]

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

Re: assertion failed: last_size == new_size, file: fs/btrfs/inode.c

[Dave Jones]

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

Re: assertion failed: last_size == new_size, file: fs/btrfs/inode.c

[Liu Bo]

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

Re: assertion failed: last_size == new_size, file: fs/btrfs/inode.c

[Liu Bo]

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

Re: assertion failed: last_size == new_size, file: fs/btrfs/inode.c

[Dave Jones]

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

Re: assertion failed: last_size == new_size, file: fs/btrfs/inode.c

[Liu Bo]

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

Re: assertion failed: last_size == new_size, file: fs/btrfs/inode.c

[David Sterba]

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.

Re: assertion failed: last_size == new_size, file: fs/btrfs/inode.c

[Liu Bo]

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