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=-5.4 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 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 5DD86C55178 for ; Fri, 23 Oct 2020 06:22:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1259B20829 for ; Fri, 23 Oct 2020 06:22:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S375305AbgJWGWL (ORCPT ); Fri, 23 Oct 2020 02:22:11 -0400 Received: from mx2.suse.de ([195.135.220.15]:37190 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S375300AbgJWGWL (ORCPT ); Fri, 23 Oct 2020 02:22:11 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 0753CACE6; Fri, 23 Oct 2020 06:22:10 +0000 (UTC) Subject: Re: [RFC] synchronous readpage for buffer_heads To: Matthew Wilcox , linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org References: <20201022152256.GU20115@casper.infradead.org> From: Hannes Reinecke Message-ID: <25528b1a-7434-62cb-705a-7269d050bbc1@suse.de> Date: Fri, 23 Oct 2020 08:22:07 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <20201022152256.GU20115@casper.infradead.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On 10/22/20 5:22 PM, Matthew Wilcox wrote: > I'm working on making readpage synchronous so that it can actually return > errors instead of futilely setting PageError. Something that's common > between most of the block based filesystems is the need to submit N > I/Os and wait for them to all complete (some filesystems don't support > sub-page block size, so they don't have this problem). > > I ended up coming up with a fairly nice data structure which I've called > the blk_completion. It waits for 'n' events to happen, then wakes the > task that cares, unless the task has got bored and wandered off to do > something else. > > block_read_full_page() then uses this data structure to submit 'n' buffer > heads and wait for them to all complete. The fscrypt code doesn't work > in this scheme, so I bailed on that for now. I have ideas for fixing it, > but they can wait. > > Obviously this all needs documentation, but I'd like feedback on the > idea before I do that. I have given it some light testing, but there > aren't too many filesystems left that use block_read_full_page() so I > haven't done a proper xfstests run. > Hmm. You are aware, of course, that hch et al are working on replacing bhs with iomap, right? So wouldn't it be more useful to concentrate on the iomap code, and ensure that _that_ is working correctly? Cheers, Hannes -- Dr. Hannes Reinecke Kernel Storage Architect hare@suse.de +49 911 74053 688 SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer