ZFS question

[Jeremy Chadwick]

On Thu, Mar 21, 2013 at 01:53:04AM -0700, Jeremy Chadwick wrote:
> There were fixes for very similar situations to this in stable/9
> recently -- I know because I was the person who reported such.  mav@ and
> ken@ worked out a series of kinks/bugs in CAM pertaining to pass(4) and
> xpt(4) and some other things.  You can read about that here:
> 
> http://lists.freebsd.org/pipermail/freebsd-fs/2013-February/016515.html
> http://lists.freebsd.org/pipermail/freebsd-fs/2013-February/016524.html
> 
> For me to determine if those fixes address the above oddity while
> testing, I would need to build stable/9 on this testbox.  I can do that,
> and will try to dedicate some time to it tomorrow.
> 
> So in summary: there seem to be multiple issues shown above, but I can
> confirm that failmode=continue **does** pass EIO to *running* processes
> that are doing I/O.  Subsequent I/O, however, is questionable at this
> time.

I've tested with stable/9 (r248571).  The issues I noted in my previous
post:

http://lists.freebsd.org/pipermail/freebsd-fs/2013-March/016814.html

...still exist.  Issue is 100% reproducible.

However, commands like "zpool status"

I also confirmed that **reads** from the now-busted pool do block/wait
indefinitely -- this means you cannot Ctrl-C or Ctrl-Z or kill them in
any way (this is completely normal for all *IXes (for some reason people
think kill -9 will always cause a kernel to unlock/relinquish a thread,
which is not the case)).  For whatever reason "ls -l /pool" did return
results, but I imagine these may be being returned from some caching
mechanism within the kernel (either VFS or ZFS ARC, not sure).
**Writes**, however, immediately return with EIO.  This is with
failmode=continue.

-- 
| Jeremy Chadwick                                   jdc at koitsu.org |
| UNIX Systems Administrator                http://jdc.koitsu.org/ |
| Mountain View, CA, US                                            |
| Making life hard for others since 1977.             PGP 4BD6C0CB |