Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Wed, 24 Feb 2021 23:54:54 +0000
From:   Matthew Wilcox <willy@infradead.org>
To:     Andreas Dilger <adilger@dilger.ca>
Cc:     Jan Kara <jack@suse.cz>,
        linux-fsdevel <linux-fsdevel@vger.kernel.org>,
        linux-mm <linux-mm@kvack.org>, linux-kernel@vger.kernel.org,
        Christoph Hellwig <hch@lst.de>,
        Kent Overstreet <kent.overstreet@gmail.com>
Subject: Re: [RFC] Better page cache error handling
Message-ID: <20210224235454.GV2858050@casper.infradead.org>
References: <20210205161142.GI308988@casper.infradead.org>
 <20210224123848.GA27695@quack2.suse.cz>
 <20210224134115.GP2858050@casper.infradead.org>
 <DC74377C-DFFD-4E26-90AB-213577DB3081@dilger.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <DC74377C-DFFD-4E26-90AB-213577DB3081@dilger.ca>
Precedence: bulk

On Wed, Feb 24, 2021 at 04:41:26PM -0700, Andreas Dilger wrote:
> Since you would know that the page is bad at this point (not uptodate,
> does not contain valid data) you could potentially re-use some other

Oh, we don't know that.  We know _a_ read has failed.  There could be
up to 128 blocks that comprise this (64kB) page, and we don't want to
prevent reads to those other blocks in the page to fail unnecessarily.

> fields in struct page, or potentially store something in the page itself?
> That would avoid bloating struct page with fields that are only rarely
> needed.  Userspace shouldn't be able to read the page at that point if
> it is not marked uptodate, but they could overwrite it, so you wouldn't
> want to store any kind of complex data structure there, but you _could_
> store a magic, an error value, and a timeout, that are only valid if
> !uptodate (cleared if the page were totally overwritten by userspace).
> 
> Yes, it's nasty, but better than growing struct page, and better than
> blocking userspace threads for tens of minutes when a block is bad.

The current state blocks threads for tens of minutes.  I'm proposing
reducing it down to 30 seconds.  I'd want to see a more concrete
proposal than this ...

(also, a per-page data structure might blow up nastily if the entire
drive is inaccessible, rather than just a single bad block)