-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PANIC: blkptr at ffff88080812d048 DVA 1 has invalid VDEV 1 #4582
Comments
@JuliaVixen According to this error you saw during the
the pool must have had another top-level vdev (i.e. stripe). The import, even with FYI, the pool configuration displayed is not the complete pool configuration, which is only stored on an object within the pool. Instead, it's displaying only the parts of the pool configuration which were actually discovered. The error quoted above does not refer to the missing mirror leg but, instead, refers to a missing top-level vdev. |
I plugged the drive back in to get the vdev labels... It kinda looks like there's only supposed to be two drives, if I understand this correctly.
|
@JuliaVixen Hmm, the label is missing |
This pool was created on FreeBSD release, um... I forgot, 7.something I think? (I still have the root fs drive, so I could theoretically check.) In 2009, I probably plugged this drive in (with a second drive too), created a zpool mirror named "backup", backed some stuff up to it, unplugged the drives, and hid them away (apparently in different locations) until I found one of them again in 2016. I'm pretty sure there's data on it, I just can't get any information about that from zdb or any other tools. I've probably only imported this once or twice, in 2009, just to copy data to it. |
I agree with dweezil, the pool was only imported for around 3m18s and there should be another missing disk above and beyond the Allowing the import to proceed with a known missing top-level vdev just to promptly crash is a bug though. |
Here's another interesting item shown by the vdev label: the I manually ran the vdev checksum calculation and it definitely doesn't match any of the uberblocks. @JuliaVixen I don't know much about the various versions of ZoL available for Gentoo but this still sounds like a regression introduced by the stable ABI as I understand is used on some Gentoo systems. The import process shouldn't get this far and as @DeHackEd pointed out, that's the real bug here. Can you try with a more stock build of ZoL, assuming you are in fact using a version with the new stable API? |
The zfs-9999, spl-9999, zfs-kmod-9999 ebuilds will have the current master without the stable API patches. |
|
Oh hey guess what! I just got this crash again with a drive from my old Solaris box. I know for certain that there is no missing VDEV this time; I have all of the drives plugged in. At the console:
In the log:
Yep, it's blocked... Here's the disk label
This disk was the boot drive on my old Solaris 10 box...
|
@JuliaVixen ZFS is detecting a DVA (data virtual address) which appears to be damaged because it refers to a vdev which can't exist according to the pool configuration. Since the drive is from a very old Solaris system and ZFS version (pool version 2!), and because it's not the primary DVA I suspect it's just not being detected on the old setup. You could try setting the |
I haven't tried the Well... FreeBSD has a kernel panic too.
|
Ok, I booted with
Then I typed
|
While clearing out the rest of the stuff from my garage, I found the other half of the So, I guess to reproduce this bug, I should remove a disk. Anyway, while I have it working, here's a dump of what a "working" configuration looks like... If I just do [The partitions are left over from whatever this drive was used as before, they're not really valid partitions, but I didn't zero out the disk before I used it in this ZFS pool.]
Nothing in Oh hey, I found another drive, I can import it too!
I don't know why Anyway, so I guess I'll pull |
Removed one drive.... nothing exciting happened.... But, then I removed the other drive, leaving only the drive I had tried to import [GUID: 15917724193338767979] back in May, when I opened this bug report... And kernel panic! First the boring part:
And then this triggers the kernel panic....
And then block forever... So here's the stack dump...
|
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. |
So, I found an old hard drive from around 2009, which was half of a mirror apparently; plugged it in, and tried to import the pool. Then got a kernel panic...
...And then the zpool process blocks on I/O forever. (In the D state)
The text was updated successfully, but these errors were encountered: