Date: Fri, 27 Nov 2015 11:07:13 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 186000] zdb(8): zdb -S poolname no longer works Message-ID: <bug-186000-8-9Mu5RFlFPc@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-186000-8@https.bugs.freebsd.org/bugzilla/> References: <bug-186000-8@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=186000 --- Comment #2 from Gert Doering <gert@greenie.muc.de> --- ok, turns out I could solve this on my own, so maybe the result can help either make the tools more useful, or just fix the issue. Turns out that when this pool was created, it was put on /dev/multipath/fc_mpath (because there are two FC paths to the same LUN on a SAN). I made a mistake when creating the multipath label, that is, I only "gmultipath create"'d it, not "gmultipath label" - it was in RAM, everything worked, after reboot, the label was not there and the pool was imported from /dev/da2. And here comes's the catch: "zdb -s" still wanted to access /dev/multipath/fc_mpath, which, of course, did not exist. After fixing the labeling and re-importing the pool it works now. But it's still a bug - at least, it should point out *what* is "No such file or directory", or preferrably, just use the device that "zpool status" knows is used... -- You are receiving this mail because: You are the assignee for the bug.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-186000-8-9Mu5RFlFPc>