Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 24 Mar 2013 08:33:42 -0700
From:      Jeremy Chadwick <jdc@koitsu.org>
To:        Quartz <quartz@sneakertech.com>
Cc:        freebsd-fs@freebsd.org
Subject:   Re: ZFS question
Message-ID:  <20130324153342.GA3687@icarus.home.lan>
In-Reply-To: <20130321085304.GB16997@icarus.home.lan>
References:  <20130321044557.GA15977@icarus.home.lan> <514AA192.2090006@sneakertech.com> <20130321085304.GB16997@icarus.home.lan>

next in thread | previous in thread | raw e-mail | index | archive | help
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@koitsu.org |
| UNIX Systems Administrator                http://jdc.koitsu.org/ |
| Mountain View, CA, US                                            |
| Making life hard for others since 1977.             PGP 4BD6C0CB |



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