add BIO_NORETRY flag, implement support in ata_da, use in ZFS vdev_geom
avg at FreeBSD.org
Fri Nov 24 13:41:27 UTC 2017
On 24/11/2017 15:08, Warner Losh wrote:
> On Fri, Nov 24, 2017 at 3:30 AM, Andriy Gapon <avg at freebsd.org
> <mailto:avg at freebsd.org>> wrote:
> https://reviews.freebsd.org/D13224 <https://reviews.freebsd.org/D13224>
> Anyone interested is welcome to join the review.
> I think it's a really bad idea. It introduces a 'one-size-fits-all' notion of
> QoS that seems misguided. It conflates a shorter timeout with don't retry. And
> why is retrying bad? It seems more a notion of 'fail fast' or so other concept.
> There's so many other ways you'd want to use it. And it uses the same return
> code (EIO) to mean something new. It's generally meant 'The lower layers have
> retried this, and it failed, do not submit it again as it will not succeed' with
> 'I gave it a half-assed attempt, and that failed, but resubmission might work'.
> This breaks a number of assumptions in the BUF/BIO layer as well as parts of CAM
> even more than they are broken now.
> So let's step back a bit: what problem is it trying to solve?
A simple example. I have a mirror, I issue a read to one of its members. Let's
assume there is some trouble with that particular block on that particular disk.
The disk may spend a lot of time trying to read it and would still fail. With
the current defaults I would wait 5x that time to finally get the error back.
Then I go to another mirror member and get my data from there.
IMO, this is not optimal. I'd rather pass BIO_NORETRY to the first read, get
the error back sooner and try the other disk sooner. Only if I know that there
are no other copies to try, then I would use the normal read with all the retrying.
More information about the freebsd-fs