Date: Thu, 20 Sep 2018 21:44:52 +0200 From: Alexander Leidinger <Alexander@leidinger.net> To: David Chisnall <theraven@freebsd.org> Cc: freebsd-fs@freebsd.org Subject: Re: Fixing vdev name Message-ID: <20180920214452.Horde.tmI5_tfqjxx2hFC_n4XKZFO@webmail.leidinger.net> In-Reply-To: <58e2716e-5221-c529-d270-ba4e3b322fac@theravensnest.org> References: <fe377835-a45a-22e1-e80e-bf4d1e87664b@theravensnest.org> <58e2716e-5221-c529-d270-ba4e3b322fac@theravensnest.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting David Chisnall <theraven@freebsd.org> (from Thu, 20 Sep 2018 14:05:46 +0100): > [ Please keep me in the cc line - I'm not subscribed to this list ] > >>> Hello the list, >>> >>> I have a VM that uses ZFS with a pair of striped devices. The >>> first is a partition on the root disk, created by the installer. >>> When this was too small, I added another device (da1) and told >>> the pool to expand to use it (no redundancy, because the >>> underlying storage for the VM images provides that). After a >>> reboot, I can no longer boot the system. Booting from the install >>> CD and attempting to import the pool, it correctly identifies >>> da0p4 as one of the devices, but gives me a long number instead >>> of da1. >> >> This means ZFS doesn't see the other device (or more correctly no >> device with the ZFS meta-data on the device which matches what the >> pool wants to see as the second vdev). > > So there's been some corruption to the disk? Maybe. >> Do you see the second disk from non-ZFS tools? > > geom lists da1 as a device of the correct type, but zdb doesn't find > any labels for it. > >> Does the partition info look OK there (if you partitioned it >> before giving it to ZFS)? > > I dind't partition it, I just assigned the whole thing to ZFS. For a raw disk (real hardware) not recommended, but for a LUN from a SAN I see no issue with that. >> Does the geometry/size look correct? > > Yup, in geom list it all looks sensible. > >> >>> How do I fix this so that the pool again points to da1? >> >> As a side note, it doesn't matter if it is da1 or something else >> (e.g. /dev/gpt/<volid> or whatever), as long as it is a geom >> provider instead of the uuid of the device like it seems to be the >> case right now. > > So does this mean that something on the (virtual) disk was corrupted > (sufficiently to remove both copies of the label and the uberblock)? Sounds like. Or the unterlying provider was in some kind of "revert to initial state after power-cycle" mode. Or the backing store was exchanged in between. Or ... If you have the space, make an exact copy of the backing store of both disks, then run "zpool import -F <pool_name>". This will _try_ to revert back to a pool state which can be imported (before addition of the 2nd vdev). This will then off course be without any data (or chance to recover it) since the addition of the second vdev, but maybe this is good enough for you. You then have off course the possibility to copy both pools back from the "safecopy" you did before and you will be in the same situation as now. I have no other idea right now and don't know if there is some kind of way to let zfs/zdb search harder for ZFS structures on disk (to give you an idea of what may have happened or how big a possible corruption is). Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180920214452.Horde.tmI5_tfqjxx2hFC_n4XKZFO>