Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 12 Dec 2017 18:12:28 +0200
From:      Andriy Gapon <avg@FreeBSD.org>
To:        Scott Long <scottl@samsco.org>
Cc:        Warner Losh <imp@bsdimp.com>, FreeBSD FS <freebsd-fs@freebsd.org>, freebsd-geom@freebsd.org
Subject:   Re: add BIO_NORETRY flag, implement support in ata_da, use in ZFS vdev_geom
Message-ID:  <f321b814-f3d2-029a-40eb-813d35605a5f@FreeBSD.org>
In-Reply-To: <DC23D104-F5F3-4844-8638-4644DC9DD411@samsco.org>
References:  <391f2cc7-0036-06ec-b6c9-e56681114eeb@FreeBSD.org> <CANCZdfoE5UWMC6v4bbov6zizvcEMCbrSdGeJ019axCUfS_T_6w@mail.gmail.com> <64f37301-a3d8-5ac4-a25f-4f6e4254ffe9@FreeBSD.org> <39E8D9C4-6BF3-4844-85AD-3568A6D16E64@samsco.org> <c9a96004-9998-c96d-efd7-d7e510c3c460@FreeBSD.org> <DC23D104-F5F3-4844-8638-4644DC9DD411@samsco.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 25/11/2017 12:54, Scott Long wrote:
> Why is overloading EIO so bad?  brelse() will call bdirty() when a BIO_WRITE
> command has failed with EIO.  Calling bdirty() has the effect of retrying the I/O.
> This disregards the fact that disk drivers only return EIO when they’ve decided
> that the I/O cannot be retried.  It has no termination condition for the retries, and
> will endlessly retry I/O in vain; I’ve seen this quite frequently.  It also disregards
> the fact that I/O marked as B_PAGING can’t be retried in this fashion, and will
> trigger a panic.  Because we pretend that EIO can be retried, we are left with
> a system that is very fragile when I/O actually does fail.  Instead of adding
> more special cases and blurred lines, I want to go back to enforcing strict
> contracts between the layers and force the core parts of the system to respect
> those contracts and handle errors properly, instead of just retrying and
> hoping for the best.

I agree with your intention.
But let's not project what I consider to be a bug in the buffer cache code on
all consumers of bio / geom interface.
In fact, I am much surprised that there is any code that treats EIO as
retriable.  I don't know of any other such code except for specialized disk
recovery tools.

-- 
Andriy Gapon



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?f321b814-f3d2-029a-40eb-813d35605a5f>