Re: ZFS checksum errors on USB attach (Was: ZFS data error without reasons)

From: Damian Gerow <dgerow_at_afflictions.org>
Date: Wed, 1 Apr 2009 19:43:15 -0400
Damian Gerow wrote:
: : > I walked over to my laptop (Lenovo X200), and plugged in a Cowon D2 to
: : > charge up the battery.  When I tried to do other things, I received a large
: : > number of input/output errors, so I knew I'd triggered the bug.  Two things
: : > that I tried to do:
: : 
: : If you unload "umass" and plug a memory stick, do you see the same behaviour 
: : then?
: : 
: : Maybe it is not directly USB related.
: 
: I had previously been unable to produce the same symptoms immediately
: following a reboot, with no USB-related modules loaded.  I will give it
: another try later today to confirm.

umass is compiled in to the kernel by default.  It's not a module I can
load and unload (that I'm aware of, anyhow).

So I tried plugging the D2 in, and it didn't cause any troubles.  But I
wasn't running transmission -- so I started transmission up, plugged the D2
in again, and lo and behold, ZFS checksum errors:

-----
Apr  1 19:37:24 plebeian kernel: da1 at umass-sim0 bus 0 target 0 lun 1
Apr  1 19:37:24 plebeian kernel: da1: <COWON D2 0100> Removable Direct Access SCSI-0 device 
Apr  1 19:37:24 plebeian kernel: da1: 40.000MB/s transfers
Apr  1 19:37:24 plebeian kernel: da1: 15359MB (31456320 512 byte sectors: 255H 63S/T 1958C)
Apr  1 19:37:24 plebeian kernel: GEOM_LABEL: Label for provider da0 is msdosfs/D2.
Apr  1 19:37:24 plebeian kernel: GEOM: da1: partition 1 does not start on a track boundary.
Apr  1 19:37:24 plebeian kernel: GEOM: da1: partition 1 does not end on a track boundary.
Apr  1 19:37:29 plebeian root: ZFS: checksum mismatch, zpool=storage path=/dev/ad4s1d.eli offset=107774476288 size=131072
Apr  1 19:37:29 plebeian root: ZFS: checksum mismatch, zpool=storage path=/dev/ad4s1d.eli offset=107774476288 size=131072
Apr  1 19:37:29 plebeian root: ZFS: zpool I/O failure, zpool=storage error=86
-----

However, the errors are ocurring far less quickly than normal.  Could just
be coincidence, but I doubt it: closing firefox didn't result in a core
dump, but in a proper shutdown procedure.

So, this seems to be related to ZFS, and possibly the number of files it has
open?  Pure speculation on my part, but I only seem to be able to trigger
this bug when transmission is open: the only torrent it has loaded is
something like 200 files, and 30GB.

  - Damian
Received on Wed Apr 01 2009 - 21:43:34 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:45 UTC