In the last episode (May 30), Olaf Seibert said:
> On Mon 30 May 2011 at 03:33:49 -0700, Jeremy Chadwick wrote:
> > On Mon, May 30, 2011 at 12:10:51PM +0200, Olaf Seibert wrote:
> > I'm not sure why this didn't actually map to a filename on the system
> > however. I've never quite understood what the hexadecimal values shown
> > represent (I have ideas but it'd be useful to know what they meant).
>
> The scrub is starting to add some filenames to the list. So far they are
> two filenames in snapshots (where current versions of the file have been
> modified since then).
>
> > Try running without compression and see if that improves things.
>
> That sounds like a good idea.
>
> My theory so far is that it ran out of memory while compressing, with
> incorrect compressed data written to the disk.
The ZFS compression code will panic if it can't allocate the buffer needed
to store the compressed data, so that's unlikely to be your problem. The
only time I have seen an "illegal byte sequence" error was when trying to
copy raw disk images containing ZFS pools to different disks, and the
destination disk was a different size than the original. I wasn't even able
to import the pool in that case, though.
The zfs IO code overloads the EILSEQ error code and uses it as a "checksum
error" code. Returning that error for the same block on all disks is
definitely weird. Could you have run a partitioning tool, or some other
program that would have done direct writes to all of your component disks?
Your scrub is also a bit worrying - 24k checksum errors definitely shouldn't
occur during normal usage.
--
Dan Nelson
dnelson@allantgroup.com
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
討論串 (同標題文章)
完整討論串 (本文為第 5 之 9 篇)：