From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 92962C433DB for ; Wed, 24 Feb 2021 23:55:22 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B48F864F0A for ; Wed, 24 Feb 2021 23:55:21 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B48F864F0A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 19B546B0005; Wed, 24 Feb 2021 18:55:21 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1253B6B006C; Wed, 24 Feb 2021 18:55:21 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 013C86B006E; Wed, 24 Feb 2021 18:55:20 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0073.hostedemail.com [216.40.44.73]) by kanga.kvack.org (Postfix) with ESMTP id DB4896B0005 for ; Wed, 24 Feb 2021 18:55:20 -0500 (EST) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id A2B611838DBF8 for ; Wed, 24 Feb 2021 23:55:20 +0000 (UTC) X-FDA: 77854820400.09.AB54D6B Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf20.hostedemail.com (Postfix) with ESMTP id E7AFFDC for ; Wed, 24 Feb 2021 23:55:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=ZKtbljNjRDo6cY0QPHsZ6Rnq2DeZQM19dzIHGg5f4PY=; b=R11gkp4K6rehkkXSl4PSRzx65l omOs9KB4haZFN5IszYClFTlIXNmakpAsz4fAxZC7AP4NT0be48ChODM8fR9s0/eXa/4Ty3HZvM4gt 6lHCl7SJswDAajgVgHI2iVL4pUKvNycpwzbn5KTaT/ENMXWr5tq2GMvgVbbwKIMXRywuv/Ful5xhu dCtFqPDsR9IhaO+ztDoHOy2wHWc42wdSRaZ4WQzmlL79HDrh2j26nL25+BanEl5FxoMxfOgGAMVT0 NhWxnqlvn8KV9j6D0BCcqR4RJuPlTFObo0dTO2Kd5vzwZhGp+60qiUC+RVhmrTZBXgKvRn100zgST WvXhqM/w==; Received: from willy by casper.infradead.org with local (Exim 4.94 #2 (Red Hat Linux)) id 1lF3za-00A2mh-3j; Wed, 24 Feb 2021 23:54:57 +0000 Date: Wed, 24 Feb 2021 23:54:54 +0000 From: Matthew Wilcox To: Andreas Dilger Cc: Jan Kara , linux-fsdevel , linux-mm , linux-kernel@vger.kernel.org, Christoph Hellwig , Kent Overstreet 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: E7AFFDC X-Stat-Signature: 1ctgrugs9gdght77fur4fuqgw97knyiq Received-SPF: none (infradead.org>: No applicable sender policy available) receiver=imf20; identity=mailfrom; envelope-from=""; helo=casper.infradead.org; client-ip=90.155.50.34 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1614210917-976889 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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)