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.8 required=3.0 tests=BAYES_00, 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 1543BC4338F for ; Thu, 5 Aug 2021 18:27:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E1EE361158 for ; Thu, 5 Aug 2021 18:27:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240628AbhHES2E (ORCPT ); Thu, 5 Aug 2021 14:28:04 -0400 Received: from tartarus.angband.pl ([51.83.246.204]:60480 "EHLO tartarus.angband.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229771AbhHES2D (ORCPT ); Thu, 5 Aug 2021 14:28:03 -0400 X-Greylist: delayed 2259 seconds by postgrey-1.27 at vger.kernel.org; Thu, 05 Aug 2021 14:28:03 EDT Received: from kilobyte by tartarus.angband.pl with local (Exim 4.94.2) (envelope-from ) id 1mBhR0-001psM-2y; Thu, 05 Aug 2021 19:45:34 +0200 Date: Thu, 5 Aug 2021 19:45:34 +0200 From: Adam Borowski To: David Howells Cc: Matthew Wilcox , linux-fsdevel@vger.kernel.org, jlayton@kernel.org, Christoph Hellwig , Linus Torvalds , dchinner@redhat.com, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: Could it be made possible to offer "supplementary" data to a DIO write ? Message-ID: References: <1017390.1628158757@warthog.procyon.org.uk> <1170464.1628168823@warthog.procyon.org.uk> <1186271.1628174281@warthog.procyon.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1186271.1628174281@warthog.procyon.org.uk> X-Junkbait: aaron@angband.pl, zzyx@angband.pl X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: kilobyte@angband.pl X-SA-Exim-Scanned: No (on tartarus.angband.pl); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Thu, Aug 05, 2021 at 03:38:01PM +0100, David Howells wrote: > Generally, I prefer to write back the minimum I can get away with (as does the > Linux NFS client AFAICT). > > However, if everyone agrees that we should only ever write back a multiple of > a certain block size, even to network filesystems, what block size should that > be? Note that PAGE_SIZE varies across arches and folios are going to > exacerbate this. What I don't want to happen is that you read from a file, it > creates, say, a 4M (or larger) folio; you change three bytes and then you're > forced to write back the entire 4M folio. grep . /sys/class/block/*/queue/minimum_io_size and also hw_sector_size, logical_block_size, physical_block_size. The data seems suspect to me, though. I get 4096 for a spinner (looks sane), 512 for nvme (less than page size), and 4096 for pmem (I'd expect cacheline or ECC block). Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ Certified airhead; got the CT scan to prove that! ⠈⠳⣄⠀⠀⠀⠀