Date: Sat, 23 Jan 2010 05:05:37 -0500 From: Rich <rincebrain@gmail.com> To: Artem Belevich <fbsdlist@src.cx> Cc: freebsd-fs <freebsd-fs@freebsd.org> Subject: Re: Errors on a file on a zpool: How to remove? Message-ID: <5da0588e1001230205y43f359dh68268a9c59b6ce53@mail.gmail.com> In-Reply-To: <ed91d4a81001230157x5a12ee48hc571bfb9abf6c586@mail.gmail.com> References: <5da0588e1001222223m773648am907267235bdcf882@mail.gmail.com> <ed91d4a81001230011t7aef2da8h3be13d2494c06550@mail.gmail.com> <5da0588e1001230014k1b8a32f8v42046497265429ed@mail.gmail.com> <ed91d4a81001230131m29446dcm1f4b5706c23665bc@mail.gmail.com> <5da0588e1001230136j52442acfw306dccaa889af7bb@mail.gmail.com> <ed91d4a81001230157x5a12ee48hc571bfb9abf6c586@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Jan 23, 2010 at 4:57 AM, Artem Belevich <fbsdlist@src.cx> wrote: > I guess it's a feature. Without redundancy all ZFS can do is report > corruption. If corruption is in the file data, it cen be removed along > with the file. If corruption is in directory or in metadata there's > little ZFS can do because that particular portion of filesystem is > inconsistent. The best that could be done is to keep those portions > read-only and try not to crash right away. > > With 7TB of data with no redundancy of any kind you are asking for > trouble even with all hardware functioning within spec. I'm well aware, thank you. The data is all retrievable from other sources, which is why redundancy wasn't a large concern in this particular pool, just speed, and knowledge of when bits flip. Of course, when all ZFS claims to do is raise EIO on corruption, and requires you to nuke the pool from orbit in order to get it to stop, rather than isolating and removing the offending segments, it's rather frustrating. - Rich
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5da0588e1001230205y43f359dh68268a9c59b6ce53>