Date: Sat, 23 Jan 2010 23:13:54 -0500 From: jhell <jhell@DataIX.net> To: Rich <rincebrain@gmail.com> Cc: freebsd-fs@freebsd.org Subject: Re: Errors on a file on a zpool: How to remove? Message-ID: <alpine.BSF.2.00.1001232307590.83451@pragry.qngnvk.ybpny> In-Reply-To: <5da0588e1001231638i349f8f17t297e970b08825441@mail.gmail.com> References: <5da0588e1001222223m773648am907267235bdcf882@mail.gmail.com> <ed91d4a81001230011t7aef2da8h3be13d2494c06550@mail.gmail.com> <5da0588e1001230014k1b8a32f8v42046497265429ed@mail.gmail.com> <alpine.BSF.2.00.1001231519110.91898@ibyngvyr> <5da0588e1001231415t403f29ceq6e8dcd16edb4a28@mail.gmail.com> <alpine.BSF.2.00.1001231733570.2160@ibyngvyr> <5da0588e1001231541l246769eao410c5ea6ccca0de4@mail.gmail.com> <A43CB93C-06D6-406D-A8C0-4E10E85661A2@gmail.com> <5da0588e1001231615t37c22575uedaae938be40f530@mail.gmail.com> <4B5B94B8.7070509@modulus.org> <5da0588e1001231638i349f8f17t297e970b08825441@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 23 Jan 2010 19:38, rincebrain@ wrote: > I'm not claiming that restoring data from backups is unreasonable, or > that silent data corruption is better. > > I'm claiming that my inability to delete the corrupted data in order > to restore from backups without nuking unaffected data or remaking the > filesystem is unreasonable. > > - Rich > > On Sat, Jan 23, 2010 at 7:30 PM, Andrew Snow <andrew@modulus.org> wrote: >> Rich wrote: >>> >>> I claim this is still Bad Behavior, and should be resolvable without >>> doing something like that. >> >> I cannot agree that silent corruption (which would have happened with any >> other filesystem) is preferable to what ZFS is doing here. >> >> You had bad RAM, and no redundancy in a huge RAID0, I think it would be >> reasonable to have to restore from backups or recreate the data and not pin >> blame on ZFS. >> >> >> - Andrew >> > Rich, Can you try the following please and then report back. Setting failmode to continue might let you continue a removal. zpool set failmode=continue what_is_it_rigatoni? This should be inherited by effected drives. zfs set checksum=off what_is_it_rigatoni? Remove the said effected files at this point. Turn your failmode back to its default state which is "wait" and then turn your checksum back to on state or whatever you had it at previously. zpool clear what_is_it_rigatoni? zpool scrub what_is_it_rigatoni? We will wait for you here... -- jhell
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1001232307590.83451>