Errors on a file on a zpool: How to remove?
Artem Belevich
fbsdlist at src.cx
Sat Jan 23 09:31:47 UTC 2010
> errors: Permanent errors have been detected in the following files:
> rigatoni/mirrors:<0x0>
This looks similar to what I had. My wild guess would be that some
metadata got corrupted.
If you really want to fix it, you may need to get close and personal
with zdb and ZFS on-disk format spec here:
http://hub.opensolaris.org/bin/download/Community+Group+zfs/docs/ondiskformat0822.pdf
Following video and PDF may help a bit:
http://video.google.com/videoplay?docid=2325724487196148104#
http://www.osdevcon.org/2008/files/osdevcon2008-max.pdf
If all you want is to avoid nagging errors you can try going up the
tree until you can do something with directory. Then move it somewhere
where it would not get in the way, "chmod 000" it and perhaps even do
"setflags schg" on it to prevent anyone from descending into directory
with bad files.
--Artem
On Sat, Jan 23, 2010 at 12:14 AM, Rich <rincebrain at gmail.com> wrote:
> I already diagnosed the bad hardware - one of the two sticks of RAM
> had gone bad, and fails memtest in the other machine.
>
> pool: rigatoni
> state: ONLINE
> status: One or more devices has experienced an error resulting in data
> corruption. Applications may be affected.
> action: Restore the file in question if possible. Otherwise restore the
> entire pool from backup.
> see: http://www.sun.com/msg/ZFS-8000-8A
> scrub: scrub completed after 15h28m with 1 errors on Thu Jan 21 18:09:25 2010
> config:
>
> NAME STATE READ WRITE CKSUM
> rigatoni ONLINE 0 0 1
> da4 ONLINE 0 0 2
> da5 ONLINE 0 0 2
> da7 ONLINE 0 0 0
> da6 ONLINE 0 0 0
> da2 ONLINE 0 0 2
>
> errors: Permanent errors have been detected in the following files:
>
> rigatoni/mirrors:<0x0>
>
> Scrubbing repeatedly does nothing to remove the note about that error,
> and I'd rather like to avoid trying to recreate a 7TB pool.
>
> - Rich
>
> On Sat, Jan 23, 2010 at 3:11 AM, Artem Belevich <fbsdlist at src.cx> wrote:
>> The directory that those files are in may be corrupted. What does
>> zpool status -v show?
>>
>> You may want to scrub the pool if you haven't done so yet. That would
>> help to find all corrupted files.
>>
>> When plain files are corrupted, you should be able to remove them. You
>> may also try to set atime=off on the filesystem to avoid filesystem
>> updates on reads.
>> Some time back when I had zpool corruption I've found no way to remove
>> corrupted directory that still had some files in it. In the end I had
>> to rebuild the pool.
>>
>> BTW, given that your pool did get corrupted, perhaps it might be a
>> good idea to start moving your data somewhere else rather than worry
>> about how to remove corrupted files. If corruption is due to bad
>> hardware, bad files would just keep popping up.
>>
>> --Artem
>>
>>
>>
>> On Fri, Jan 22, 2010 at 10:23 PM, Rich <rincebrain at gmail.com> wrote:
>>> Hey world,
>>> I've got a series of files in a non-redundant zpool which all report
>>> Input/Output Error on attempting to manipulate them in any way - stat,
>>> read, rm, anything.
>>>
>>> Whenever anything is attempted, the following style of thing is
>>> printed to /var/log/messages:
>>> Jan 23 01:22:34 manticore root: ZFS: checksum mismatch, zpool=rigatoni
>>> path=/dev/da4 offset=1231402180608 size=8192
>>> Jan 23 01:22:34 manticore root: ZFS: checksum mismatch, zpool=rigatoni
>>> path=/dev/da5 offset=446136819712 size=8192
>>> Jan 23 01:22:34 manticore root: ZFS: checksum mismatch, zpool=rigatoni
>>> path=/dev/da2 offset=320393101312 size=8192
>>> Jan 23 01:22:34 manticore root: ZFS: checksum mismatch, zpool=rigatoni
>>> path=/dev/da5 offset=446136819712 size=8192
>>> Jan 23 01:22:34 manticore root: ZFS: checksum mismatch, zpool=rigatoni
>>> path=/dev/da2 offset=320393101312 size=8192
>>> Jan 23 01:22:34 manticore root: ZFS: checksum mismatch, zpool=rigatoni
>>> path=/dev/da4 offset=1231402180608 size=8192
>>> Jan 23 01:22:35 manticore root: ZFS: zpool I/O failure, zpool=rigatoni error=86
>>>
>>> What can I do? I really would like to just purge all of these files
>>> from orbit, since I can recreate them, but I can't seem to delete
>>> them, and deleting the pool is a really inconvenient option, as I have
>>> other data on it.
>>>
>>> I'm running 8.0-RELEASE stock on amd64.
>>>
>>> Thanks!
>>>
>>> - Rich
>>> _______________________________________________
>>> freebsd-fs at freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-fs
>>> To unsubscribe, send any mail to "freebsd-fs-unsubscribe at freebsd.org"
>>>
>>
>
>
>
> --
>
> Todo homem morre, mas nem todo homem vive. -- William Wallace
>
More information about the freebsd-fs
mailing list