Date: Mon, 26 Jan 2009 17:28:07 -0500 From: Bryant Eadon <bryant.eadon@gmail.com> To: FreeBSD Questions <freebsd-questions@freebsd.org> Subject: danging dbufs in ZFS v6 , FreeBSD 7.1 Message-ID: <497E38F7.9010405@gmail.com>
next in thread | raw e-mail | index | archive | help
A problem I'm hoping you can solve ! Running on a 64bit platform with 5, 500GB HDDs in a basic raidz configuration classically named 'tank', I began copying a file. During the copy, I lost a disk. Since these are all hot swappable SATA drives, I pulled the one I *thought* had died and swapped in a good drive, which powered up and I attempted a 'replace'. The copy was still proceeding... (you see where this is going...) This wasn't the broken drive I pulled, which I quickly found after the replace attempt ! In an effort to put the good drive back into the array, I reconnected and rebooted the machine citing possible 'drive disappearance' problems with the stunt I just pulled. Nothing doing. The kernel hung at : "panic : dangling dbufs. dn = 0xffffff000a49f338 dbuf = 0xffffff000a4a01e0 " Leading me to believe the array is dead. :-/ I am happy to lose the data that was copied at the time of failure if it's possible to recover the rest of the array. I suppose that the rest of the data remains intact. Is there a way to rid myself of the dangling buffers to get back to a usable state ? (some dd magic ?) Could I recover by using a newer version of ZFS for FreeBSD ? (v13 instead of v v6) Quickly it moved from : NAME STATE READ WRITE CKSUM tank DEGRADED 0 0 0 raidz1 DEGRADED 0 0 0 da0 ONLINE 0 0 0 da1 UNAVAIL 0 887 0 cannot open da2 ONLINE 0 0 0 ad5 ONLINE 0 0 0 ad6 ONLINE 0 0 0 to : NAME STATE READ WRITE CKSUM tank UNAVAIL 0 0 0 insufficient replicas raidz1 UNAVAIL 0 0 0 insufficient replicas da0 UNAVAIL 0 0 0 cannot open da1 UNAVAIL 0 0 0 cannot open da2 ONLINE 0 0 0 ad5 ONLINE 0 0 0 ad6 ONLINE 0 0 0
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?497E38F7.9010405>