panic: allocating allocated segment #6315
Assignees
Labels
Component: ZVOL
ZFS Volumes
Comments
This was referenced Jul 22, 2017
|
Been chatting with a few people in IRC, unfortunately we were able to reproduce this with OI as a KVM guest on a linux ZOL host. @ryao has shown some interest in helping me debug this, will try to update on Monday/Tuesday. |
|
ubuntu 16.04 with kernel 4.10, qemu-kvm 1:2.5+dfsg-5ubuntu10.14 and libvirtd-bin 1.3.1-1ubuntu10 |
|
Just a follow-up, I changed the vm setup to using the zvol as a virtio device instead of ide/sata and was able to install OI. This might be a configuration problem on kvm after all. |
|
@bunder2015 is this a debug build of ZFS? If not, could you please try to reproduce this with debugging enabled? Thanks. This may just be a duplicate of #6238. |
|
I'm afraid the EFI partition on my laptop is too small to enable debugging and use stub booting at the same time. I can possibly try again after we get openzfs 7446. |
|
@bunder2015 just to be clear i was talking about the |
|
I only have 8MB to fit a kernel into, and with --enable-debug the zfs/spl modules come out to about 4.5MB (before compression). The kernel itself is 5MB compressed, when I switched to stub booting I tried to shave off as much as I could but found myself about 300KB too large. |
|
@bunder2015 if you're still willing to test this we can make this happen by changing this single ASSERT to VERIFY in diff --git a/module/zfs/dbuf.c b/module/zfs/dbuf.c
index dc2c00495..ce40364af 100644
--- a/module/zfs/dbuf.c
+++ b/module/zfs/dbuf.c
@@ -1301,7 +1301,7 @@ dbuf_unoverride(dbuf_dirty_record_t *dr)
* a zilog's get_data while holding a range lock. This call only
* comes from dbuf_dirty() callers who must also hold a range lock.
*/
- ASSERT(dr->dt.dl.dr_override_state != DR_IN_DMU_SYNC);
+ VERIFY(dr->dt.dl.dr_override_state != DR_IN_DMU_SYNC);
ASSERT(db->db_level == 0);
if (db->db_blkid == DMU_BONUS_BLKID || |
13 tasks
|
Hi sorry for the delay, been busy off and on lately and haven't had time to do any testing. Do you still want me to test this? I might have some time this afternoon. |
|
Hi, is it possible, that this is fixed in 0.7.1 as part of #6414 work? |
|
Nevermind, it still crashes. Debian stretch (9.1) ZFS 0.7.0-18_g5146d802 The machine hosts XEN VMs. Right now I wonder:
Pool layout: kern.log- PANIC: kern.log - subsequent timeouts: |
|
So I upgraded to git head again and applied the assert/verify toggle patch and now it's not happening anymore. Maybe this got patched between 0.7.0 and 0.7.1, will need to test more to confirm. |
|
For me assert/verify patch just move the problem to another place: in addition it kind of limits the scope of what has crashed - other zvols are largely accessible even after this kind of crash. It is 'better' than ASSERT - in a sense that it allows rest of the VMs to stop in an orderly fashion. Removing l2arc doesn't help. Didn't dare to remove SLOGs. |
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 <[email protected]> Reviewed-by: Brian Behlendorf <[email protected]> Signed-off-by: loli10K <[email protected]> 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 <[email protected]> Reviewed-by: Brian Behlendorf <[email protected]> Signed-off-by: loli10K <[email protected]> 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 <[email protected]> Reviewed-by: Brian Behlendorf <[email protected]> Signed-off-by: loli10K <[email protected]> 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
System information
qemu-2.9.0-r2
virt-manager-1.4.0-r3
virtualbox-5.0.32
Describe the problem you're observing
VM setup on my laptop, gentoo host - OpenIndiana guest residing on a zvol. Tried running OI through vbox (KVM accelerated), as soon as the guest tries to do any zfs operations, zfs on the host panics. Also tried using KVM/QEMU directly (with virt-manager), same result.
Scrubbing after the panic reveals that the zvol is now damaged and needs to be destroyed.
FreeBSD installed through same methods was successful.
Describe how to reproduce the problem
Create new zvol, assign it to guest, attempt to install OS (or boot pre-existing install), while watching host dmesg.
edit: zvol was created with:
zfs create -b 4K -V 30G -o compression=off -o primarycache=none -o secondarycache=none -o logbias=throughput -o sync=always a-pool/vm-openindianaLooks slightly similar to #5504
Include any warning/errors/backtraces from the system logs
The text was updated successfully, but these errors were encountered: