Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 23 Jan 2010 18:41:02 -0500
From:      Rich <rincebrain@gmail.com>
To:        Wes Morgan <morganw@chemikals.org>
Cc:        freebsd-fs <freebsd-fs@freebsd.org>
Subject:   Re: Errors on a file on a zpool: How to remove?
Message-ID:  <5da0588e1001231541l246769eao410c5ea6ccca0de4@mail.gmail.com>
In-Reply-To: <alpine.BSF.2.00.1001231733570.2160@ibyngvyr>
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>

next in thread | previous in thread | raw e-mail | index | archive | help
I have no files named 0x0.

I have a number of files which, on attempting to do anything to them
(stat, mv, rm), EIO occurs, the checksum error number on three of the
disks in that pool ticks up, and /var/log/messages reports what I
reported in my initial post. (i discovered this due to FreeBSD's daily
check-for-setuid-bits-in-strange-places find command reporting EIO on
some files.)

My original post in this thread is about how to resolve this.

- Rich

On Sat, Jan 23, 2010 at 6:34 PM, Wes Morgan <morganw@chemikals.org> wrote:
> On Sat, 23 Jan 2010, Rich wrote:
>
>> On Sat, Jan 23, 2010 at 4:21 PM, Wes Morgan <morganw@chemikals.org> wrot=
e:
>> > On Sat, 23 Jan 2010, Rich wrote:
>> >
>> >> I already diagnosed the bad hardware - one of the two sticks of RAM
>> >> had gone bad, and fails memtest in the other machine.
>> >>
>> >> =A0 pool: rigatoni
>> >> =A0state: ONLINE
>> >> status: One or more devices has experienced an error resulting in dat=
a
>> >> =A0 =A0 =A0 corruption. =A0Applications may be affected.
>> >> action: Restore the file in question if possible. =A0Otherwise restor=
e the
>> >> =A0 =A0 =A0 entire pool from backup.
>> >> =A0 =A0see: http://www.sun.com/msg/ZFS-8000-8A
>> >> =A0scrub: scrub completed after 15h28m with 1 errors on Thu Jan 21 18=
:09:25 2010
>> >> config:
>> >>
>> >> =A0 =A0 =A0 NAME =A0 =A0 =A0 =A0STATE =A0 =A0 READ WRITE CKSUM
>> >> =A0 =A0 =A0 rigatoni =A0 =A0ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 =A0 1
>> >> =A0 =A0 =A0 =A0 da4 =A0 =A0 =A0 ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 =
=A0 2
>> >> =A0 =A0 =A0 =A0 da5 =A0 =A0 =A0 ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 =
=A0 2
>> >> =A0 =A0 =A0 =A0 da7 =A0 =A0 =A0 ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 =
=A0 0
>> >> =A0 =A0 =A0 =A0 da6 =A0 =A0 =A0 ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 =
=A0 0
>> >> =A0 =A0 =A0 =A0 da2 =A0 =A0 =A0 ONLINE =A0 =A0 =A0 0 =A0 =A0 0 =A0 =
=A0 2
>> >>
>> >> errors: Permanent errors have been detected in the following files:
>> >>
>> >> =A0 =A0 =A0 =A0 rigatoni/mirrors:<0x0>
>> >
>> > Can you post your entire pool filesystem structure? That message above
>> > looks like an unreferenced block or corrupted metadata rather than an
>> > actual file. Also, if it's part of a snapshot, you simply have to dest=
roy
>> > the snapshot.
>> >
>> > I had a pool become corrupted due to bad memory, and all of the files =
were
>> > still able to be manipulated. The only time EIO popped up was on the
>> > specific block that had a checksum error.
>>
>> # zfs list -r -t all rigatoni
>> NAME =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0USED =A0AVAIL =A0REFER =A0MOUNTP=
OINT
>> rigatoni =A0 =A0 =A0 =A0 =A0 =A0 5.73T =A0 984G =A0 =A019K =A0/rigatoni
>> rigatoni/logs_bitch =A0 269M =A0 984G =A0 269M =A0/rigatoni/logs_bitch
>> rigatoni/mirrors =A0 =A0 5.73T =A0 984G =A05.73T =A0/mirrors
>>
>> No snapshots here. :/
>>
>> EIO only pops up on the files I mentioned above - everything else in
>> those directories, including renaming that directory, is fine.
>
> I must have missed it, what files is it showing besides the <0x0> address=
?
> Or do you have a file named "<0x0>"?



--=20

Life is a yo-yo, and mankind ties knots in the string.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5da0588e1001231541l246769eao410c5ea6ccca0de4>