ARC- and zrlock-related panics during import #8876
Comments
|
added |
|
Interesting: not all or even: and At the same time it has no problem enumerating datasets from another pool: |
|
mutex assert traceback: |
|
Sorry for this noise, but I just remembered to try userland tools with |
|
Is ARC compression enabled?
|
I'm not sure how ARC might affect |
|
@vthriller there is a proposed fix for the |
|
After applying #8736 zfs crashes pretty much exactly like |
|
@vthriller thanks for the My suggestion would be to first attempt to import the pool read-only from the previous TXG number, using the |
|
@behlendorf is it ok if label txg is smaller than those recorded in the uberblocks? As for importing, I'd rather stick to |
|
Tried every txg from the list, the result is either this: or like this: |
|
Sure |
Quick reminder: the pool in question was not properly exported due to kernel oopses deep in the SPL code. Besides, |
|
Consider trying zdb's |
|
Can you try the following patch with diff --git a/module/zfs/dnode.c b/module/zfs/dnode.c
index c06f614..f5bd10d 100644
--- a/module/zfs/dnode.c
+++ b/module/zfs/dnode.c
@@ -1381,6 +1381,16 @@ dnode_hold_impl(objset_t *os, uint64_t object, int flag, int slo
if (dn_block[i].dn_type != DMU_OT_NONE) {
int interior = dn_block[i].dn_extra_slots;
+ if (i + interior >= DNODES_PER_BLOCK) {
+ for (int j = 0; j < i; j++)
+ zrl_destroy(&dnh[j].dnh_zrlock);
+
+ kmem_free(dnc, sizeof (dnode_children_t) +
+ epb * sizeof (dnode_handle_t));
+ dbuf_rele(db, FTAG);
+
+ return (SET_ERROR(ECKSUM));
+ }
+
dnode_set_slots(dnc, i, 1, DN_SLOT_ALLOCATED);
dnode_set_slots(dnc, i + 1, interior,
DN_SLOT_INTERIOR); |
Neither |
|
@behlendorf this is weird: with this patch zdb does… nothing. It shows import configuration, then just goes into (I'm not showing |
|
Whoops, it looks like I forgot to release a hold. I've updated the patch above accordingly (note the additional |
|
Thank you. Previously asserting txg: Output for |
|
You can pass |
|
This is interesting. I rebooted into the system with both patches (#8736 and the one above) applied, and initial I get this trace both after |
This corresponds to https://github.com/zfsonlinux/zfs/blob/zfs-0.8.0/module/zfs/arc.c#L2256 in tag zfs-0.8.0 |
|
Anyways, I went ahead and tried |
|
I always see this with ZoL master on Fedora (5.1.11-200.fc29.x86_64) when |
I can also easily reproduce this with upstream |
|
|
|
This issue has been automatically marked as "stale" because it has not had any activity for a while. It will be closed in 90 days if no further activity occurs. Thank you for your contributions. |
System information
Describe the problem you're observing
zfs panics during
zfs import. Pools in question were not properly exported before that due to #7987.zdb -luhave no issues with reading crucial data from any of the disks.Panics differ between versions with and without
USE=debug.Describe how to reproduce the problem
Dunno. I'm yet to figure out which pool out of three causes this.
Include any warning/errors/backtraces from the system logs
0.7.13, release:
0.7.13, debug (
zfs_dbgmsg_enable=1 zfs_flags=33):0.8.0, debug (
zfs_dbgmsg_enable=1 zfs_flags=1):The text was updated successfully, but these errors were encountered: