Date: Sun, 24 Jan 2010 08:44:32 -0500 From: Rich <rincebrain@gmail.com> To: Wes Morgan <morganw@chemikals.org> Cc: freebsd-fs@freebsd.org Subject: Re: Errors on a file on a zpool: How to remove? Message-ID: <5da0588e1001240544q61e3bebbka7ad1248343be26d@mail.gmail.com> In-Reply-To: <alpine.BSF.2.00.1001240635360.2160@ibyngvyr> References: <5da0588e1001222223m773648am907267235bdcf882@mail.gmail.com> <5da0588e1001231615t37c22575uedaae938be40f530@mail.gmail.com> <4B5B94B8.7070509@modulus.org> <5da0588e1001231638i349f8f17t297e970b08825441@mail.gmail.com> <alpine.BSF.2.00.1001232307590.83451@pragry.qngnvk.ybpny> <5da0588e1001232017m6c67731fwaa1d71cd86800017@mail.gmail.com> <alpine.BSF.2.00.1001232341590.19303@pragry.qngnvk.ybpny> <5da0588e1001232128w5a551674od0805c2ff0b884ad@mail.gmail.com> <alpine.BSF.2.00.1001240043350.19303@pragry.qngnvk.ybpny> <alpine.BSF.2.00.1001240635360.2160@ibyngvyr>
next in thread | previous in thread | raw e-mail | index | archive | help
> This is a non-redundant pool. The remove command will not work. Replace > will, but for that pool to function at all, *every* device must be > present. If the metadata was recoverable, I think that the scrub would > have reported "xxx kb repaired". Actually, zpool remove can't be used for that either - zpool detach gets used for anything that's "live". > From http://dlc.sun.com/osol/docs/content/ZFSADMIN/gbbwl.html: > > =A0 =A0If the object number to a file path cannot be successfully transla= ted, > =A0 =A0either due to an error or because the object doesn't have a real f= ile > =A0 =A0path associated with it , as is the case for a dnode_t, then the > =A0 =A0dataset name followed by the object's number is displayed. For > =A0 =A0example: > > =A0 =A0 monkey/dnode:<0x0> > > Which seems to be precisely your error. Continuing: > > =A0 =A0Then, try removing the file with the rm command. If this command > =A0 =A0doesn't work, the corruption is within the file's metadata, and ZF= S > =A0 =A0cannot determine which blocks belong to the file in order to remov= e > =A0 =A0the corruption. > > =A0 =A0If the corruption is within a directory or a file's metadata, the = only > =A0 =A0choice is to move the file elsewhere. You can safely move any file= or > =A0 =A0directory to a less convenient location, allowing the original obj= ect > =A0 =A0to be restored in place." > > In other words, either move the files out of the way or restore the pool. > I'd wager that any other filesystem would have simply wiped out entire > directory trees or possibly just panicked with this kind of corruption. I'm presuming you mean "to another FS", since we already saw rm reports EIE= IO. I've started that process, and I'll get out the backups for all the other d= ata. Thanks to everyone for being so helpful, and especially to you, Wes, for citing exactly what was going on with the manual. All hail manuals! :) - Rich
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5da0588e1001240544q61e3bebbka7ad1248343be26d>