zfs allocating allocated segment #6356
Comments
|
I verified it on zfs 0.7.0 release version, it was fixed, marks resolved. |
Somehow i doubt that this was fixed, but as per reporter comment marking resolved: we can continue investigating this in the context of the other issues. |
13 tasks
behlendorf
pushed a commit
that referenced
this issue
Aug 21, 2017
Since OpenZFS 7578 (1b7c1e5) if we have a ZVOL with logbias=throughput we will force WR_INDIRECT itxs in zvol_log_write() setting itx->itx_lr offset and length to the offset and length of the BIO from zvol_write()->zvol_log_write(): these offset and length are later used to take a range lock in zillog->zl_get_data function: zvol_get_data(). Now suppose we have a ZVOL with blocksize=8K and push 4K writes to offset 0: we will only be range-locking 0-4096. This means the ASSERTion we make in dbuf_unoverride() is no longer valid because now dmu_sync() is called from zilog's get_data functions holding a partial lock on the dbuf. Fix this by taking a range lock on the whole block in zvol_get_data(). Reviewed-by: Chunwei Chen <tuxoko@gmail.com> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: loli10K <ezomori.nozomu@gmail.com> Closes #6238 Closes #6315 Closes #6356 Closes #6477
tonyhutter
pushed a commit
that referenced
this issue
Aug 22, 2017
Since OpenZFS 7578 (1b7c1e5) if we have a ZVOL with logbias=throughput we will force WR_INDIRECT itxs in zvol_log_write() setting itx->itx_lr offset and length to the offset and length of the BIO from zvol_write()->zvol_log_write(): these offset and length are later used to take a range lock in zillog->zl_get_data function: zvol_get_data(). Now suppose we have a ZVOL with blocksize=8K and push 4K writes to offset 0: we will only be range-locking 0-4096. This means the ASSERTion we make in dbuf_unoverride() is no longer valid because now dmu_sync() is called from zilog's get_data functions holding a partial lock on the dbuf. Fix this by taking a range lock on the whole block in zvol_get_data(). Reviewed-by: Chunwei Chen <tuxoko@gmail.com> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: loli10K <ezomori.nozomu@gmail.com> Closes #6238 Closes #6315 Closes #6356 Closes #6477
SidBB
pushed a commit
to catalogicsoftware/zfs
that referenced
this issue
Aug 31, 2017
Since OpenZFS 7578 (1b7c1e5) if we have a ZVOL with logbias=throughput we will force WR_INDIRECT itxs in zvol_log_write() setting itx->itx_lr offset and length to the offset and length of the BIO from zvol_write()->zvol_log_write(): these offset and length are later used to take a range lock in zillog->zl_get_data function: zvol_get_data(). Now suppose we have a ZVOL with blocksize=8K and push 4K writes to offset 0: we will only be range-locking 0-4096. This means the ASSERTion we make in dbuf_unoverride() is no longer valid because now dmu_sync() is called from zilog's get_data functions holding a partial lock on the dbuf. Fix this by taking a range lock on the whole block in zvol_get_data(). Reviewed-by: Chunwei Chen <tuxoko@gmail.com> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: loli10K <ezomori.nozomu@gmail.com> Closes openzfs#6238 Closes openzfs#6315 Closes openzfs#6356 Closes openzfs#6477
Fabian-Gruenbichler
pushed a commit
to Fabian-Gruenbichler/zfs
that referenced
this issue
Sep 29, 2017
Since OpenZFS 7578 (1b7c1e5) if we have a ZVOL with logbias=throughput we will force WR_INDIRECT itxs in zvol_log_write() setting itx->itx_lr offset and length to the offset and length of the BIO from zvol_write()->zvol_log_write(): these offset and length are later used to take a range lock in zillog->zl_get_data function: zvol_get_data(). Now suppose we have a ZVOL with blocksize=8K and push 4K writes to offset 0: we will only be range-locking 0-4096. This means the ASSERTion we make in dbuf_unoverride() is no longer valid because now dmu_sync() is called from zilog's get_data functions holding a partial lock on the dbuf. Fix this by taking a range lock on the whole block in zvol_get_data(). Reviewed-by: Chunwei Chen <tuxoko@gmail.com> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: loli10K <ezomori.nozomu@gmail.com> Closes openzfs#6238 Closes openzfs#6315 Closes openzfs#6356 Closes openzfs#6477
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
ENV:
zfs version: 0.7.0 rc5.
kernel version: 4.4.66
configuration: one pool with 4Xraidz1(5 hdds), one 1TB zvol(default setting), exported it with scst 3.2.0，16Gb emulex LPE 16002B.
client: linux mutipath, ext4 file system created on the mutipath device.
test tool: vdbench, blocksize, width=2,files=100,size=128k, xfersize=1m,fileio=sequential, operation=write,openflags=o_sync, threads=8
issue: when i run io test after a while, it has no IOs on client. and i check the storage, find the dump stack:
[ 3742.848692] PANIC: zfs: allocating allocated segment(offset=92815952896 size=163840)
[ 3742.848692]
[ 3742.849914] Showing stack for process 19929
[ 3742.849918] CPU: 4 PID: 19929 Comm: txg_sync Tainted: P O 4.4.66-v64 #1
[ 3742.849919] Hardware name: Supermicro X10DRi/X10DRi, BIOS 2.0 12/28/2015
[ 3742.849921] 0000000000000000 0000000000028000 ffffffff812ad192 0000000000000000
[ 3742.849924] ffffffff8165b340 0000000000028000 ffff881040c0dc00 0000000000000003
[ 3742.849927] ffffffffa0318317 6c6c61203a73667a 20676e697461636f 657461636f6c6c61
[ 3742.849929] Call Trace:
[ 3742.849938] [] ? dump_stack+0x4a/0x68
[ 3742.849946] [] ? vcmn_err+0x57/0xe0 [spl]
[ 3742.849949] [] ? spl_kmem_cache_alloc+0x83/0x8a0 [spl]
[ 3742.849953] [] ? spl_kmem_cache_alloc+0x83/0x8a0 [spl]
[ 3742.849956] [] ? cache_flusharray+0xbe/0x120
[ 3742.849988] [] ? zfs_panic_recover+0x51/0x60 [zfs]
[ 3742.849991] [] ? avl_find+0x50/0x90 [zavl]
[ 3742.850013] [] ? range_tree_add+0x27f/0x2c0 [zfs]
[ 3742.850032] [] ? zio_add_child+0x101/0x130 [zfs]
[ 3742.850050] [] ? zio_create+0x453/0x500 [zfs]
[ 3742.850071] [] ? metaslab_free_dva+0x146/0x3b0 [zfs]
[ 3742.850092] [] ? metaslab_free+0x89/0xd0 [zfs]
[ 3742.850111] [] ? zio_dva_free+0x17/0x30 [zfs]
[ 3742.850129] [] ? zio_nowait+0x97/0x110 [zfs]
[ 3742.850151] [] ? spa_free_sync_cb+0x44/0x60 [zfs]
[ 3742.850173] [] ? spa_sync_aux_dev+0x260/0x260 [zfs]
[ 3742.850185] [] ? bplist_iterate+0x67/0xb0 [zfs]
[ 3742.850207] [] ? spa_sync+0x419/0xcc0 [zfs]
[ 3742.850211] [] ? autoremove_wake_function+0x2a/0x50
[ 3742.850213] [] ? __wake_up+0x43/0x70
[ 3742.850233] [] ? txg_sync_thread+0x2c2/0x470 [zfs]
[ 3742.850235] [] ? __cache_free_alien+0xaf/0x130
[ 3742.850237] [] ? __wake_up_common+0x4d/0x80
[ 3742.850240] [] ? try_to_wake_up+0x2d0/0x2d0
[ 3742.850261] [] ? txg_thread_exit+0x40/0x40 [zfs]
[ 3742.850264] [] ? __thread_create+0x160/0x160 [spl]
[ 3742.850267] [] ? thread_generic_wrapper+0x75/0x90 [spl]
[ 3742.850271] [] ? __thread_create+0x160/0x160 [spl]
[ 3742.850273] [] ? kthread+0xcc/0xf0
[ 3742.850275] [] ? kthread_worker_fn+0xf0/0xf0
[ 3742.850279] [] ? ret_from_fork+0x3f/0x70
[ 3742.850280] [] ? kthread_worker_fn+0xf0/0xf0
The text was updated successfully, but these errors were encountered: