From owner-freebsd-fs@freebsd.org Tue Dec 12 16:20:13 2017 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 36C5AE9DBA9; Tue, 12 Dec 2017 16:20:13 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lf0-f48.google.com (mail-lf0-f48.google.com [209.85.215.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D08A6640B0; Tue, 12 Dec 2017 16:20:12 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lf0-f48.google.com with SMTP id x20so23869243lff.1; Tue, 12 Dec 2017 08:20:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=pvyxcyeBsAeXccLTKSTHyn8rJf8X375ECowLUb6YoL8=; b=cJiZLKP6eZXYIHwjDf2xbjeCoEiYE40Rvath+CbmVoFnMdL49zL0IGcNab7lJgkgoC wj26joQFYJLlBelrs9dJg2MBB+CwI3GwDeinkl4ZmLfnhizqjzO1IEi4c0X4fEC8aLf3 KH8+b4Kfl82OLBpKTKlk9LH71hLdHHYlGyZnGfvrIHNScIsTapVqJjrKDnqKDsc5B87X BsuZllnGavfy2hHIjvLwkMlM1w72VxpO50M57n9eQ1I2sAkI544X4e6FeZj7VhMgGox0 8e+7P8d+pLqKRXYB0bxpeUWFe5iL4SgJNY3LzyF9NaGmBYliQOiylOPkPav2JI5D/HUO WgRQ== X-Gm-Message-State: AKGB3mK1EhkqIwke6Vxns3eZ27dKPTgizP+wevdnotiUHG0bpa3esAV+ aZdsoYFuFGrSgzaz1oTdmQFlo9mG X-Google-Smtp-Source: ACJfBosN7UGwbsGu3w0DX4edklyH7oX2rwxJhKs8v1aXezug/WriC8eki5Asqs1gV8j48iW0+3EhOA== X-Received: by 10.25.242.65 with SMTP id d1mr1968326lfk.18.1513095149607; Tue, 12 Dec 2017 08:12:29 -0800 (PST) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id r90sm3352936lje.80.2017.12.12.08.12.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Dec 2017 08:12:29 -0800 (PST) Subject: Re: add BIO_NORETRY flag, implement support in ata_da, use in ZFS vdev_geom To: Scott Long Cc: Warner Losh , FreeBSD FS , freebsd-geom@freebsd.org References: <391f2cc7-0036-06ec-b6c9-e56681114eeb@FreeBSD.org> <64f37301-a3d8-5ac4-a25f-4f6e4254ffe9@FreeBSD.org> <39E8D9C4-6BF3-4844-85AD-3568A6D16E64@samsco.org> From: Andriy Gapon Message-ID: Date: Tue, 12 Dec 2017 18:12:28 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Dec 2017 16:20:13 -0000 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