Received: by 2002:a05:6358:9144:b0:117:f937:c515 with SMTP id r4csp1434180rwr; Wed, 3 May 2023 15:24:42 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7+dRXMlVsLfWBvhRiWFWzGhxm9SIpdxyiQqvaqSFjrMNwWCOHVB7WS/06Z8zluWsQ4Exj+ X-Received: by 2002:a05:6a20:ae15:b0:f0:2222:8b58 with SMTP id dp21-20020a056a20ae1500b000f022228b58mr142077pzb.12.1683152682235; Wed, 03 May 2023 15:24:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1683152682; cv=none; d=google.com; s=arc-20160816; b=DnzUC7W0ney/8YyJKxSPsywCmDqKmMqJ7Z7MmEEAG0Ey+zeIRTkRGB5tavDBmqxgBJ b83rs1A5R5n5Oq0vLJ81Wu9hJfsP4odIZF3eQ38y3Jp7dkTFH7uv/2UACj0E8AYa3G2Y nD1cBGIiLQz1LfXsXuM9ReYkZ3HLMj8O4cLebdI1/UmAYHRw7HAXZEOCCCPpgRLfST8Y Wd0EhqWi40IRNXjTJHKu36lBSsUlE4CvPlWqt+zGDgAWJrC7lHg3ySJCz0+pgzv1GM0r CaQl5oIn/t04Q2ZbQxCHfNRQgIyOmPLSpe19CXv2pVyLO3XM9ZYfC78j8AtmnRWv3LdC ezvQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=SZlTdG04TqTF7+/hzp5sSJRuB5EmsmvAFGgc3K+3F0Y=; b=GyZZ4RwE+se8BtSEcPvnXswy/tMlUWTB9/Lb2SP39dnTHH0jLKjRURi9wjBjy3CwOu ZpurnoQ8GVdyEH/hXoSsN3K1rLWkfL2pzAXFrGzhsr8RGwoOUdCYNzBKQD4Z94WnVvVY kaGjeJ4eHWqf3Q42WJV4d59ejyrMzqMLnf9u4ai9FaOBFaWqE6Zg9UP8PN3XOFSjV/By Y5UjkaGWe9JeVIqmzm4/QRcjA7jKEPSUoCJMeGcDLjQ7paGp4Q9hNKBJNIQcxmbRBtTy A+ek37e6Rq+AWTEpMZ3bajaTprwcCEqRzYnUnNoEgviw8Ddnh7wl7OUKk/hFDUgBiLj3 g5QQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@fromorbit-com.20221208.gappssmtp.com header.s=20221208 header.b=39WVkULq; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=fromorbit.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id 137-20020a63078f000000b00513a68ca71asi28810419pgh.742.2023.05.03.15.24.26; Wed, 03 May 2023 15:24:42 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@fromorbit-com.20221208.gappssmtp.com header.s=20221208 header.b=39WVkULq; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=fromorbit.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229742AbjECWR7 (ORCPT + 99 others); Wed, 3 May 2023 18:17:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33808 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229730AbjECWR4 (ORCPT ); Wed, 3 May 2023 18:17:56 -0400 Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4B07B8687 for ; Wed, 3 May 2023 15:17:53 -0700 (PDT) Received: by mail-pl1-x632.google.com with SMTP id d9443c01a7336-1aaf2ede38fso43418185ad.2 for ; Wed, 03 May 2023 15:17:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fromorbit-com.20221208.gappssmtp.com; s=20221208; t=1683152273; x=1685744273; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=SZlTdG04TqTF7+/hzp5sSJRuB5EmsmvAFGgc3K+3F0Y=; b=39WVkULqHXRDJ4WUYe73OzFA/R2wak2Byvue6BmOkCk/OUZ7TIFexiujMgqDtXjhoJ vY8UhclcPr7rl4Zv2wbm/zdzS0ni41dpAUltS0ZIuTMSWKNEFldMe8omTChgh7JjGHw9 rVsx1Yw28FjKmAmsO5frsdqvSKA4ZJrGU5Gp+Q9w3fCsWnJVySoTDQBrKpXRB+VVwMsd 2mP535YsEeeVtqm0f04weAqu0Ix/cKqOgjAhn6wHaEI53Xkx+scS9ruET4oev/lz/RR9 HuYeHautziBafZRfpxfmTZFWObUFN65QoOJpAc8Hd0Mv9bIad3zclXTZRNBKp80hSzAf fzBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683152273; x=1685744273; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=SZlTdG04TqTF7+/hzp5sSJRuB5EmsmvAFGgc3K+3F0Y=; b=QDQjlxhJ4OPHjqSlgDZh1Ze3CXm2WaSZ95AxgO5HaKSnaJK1crTp1TyOP8pAM5JOFU OBsNw8qj+T394UN/ubnRmpqeYJtXLYrOQm9y6jFX17vdxFgMhmamXcQfZRZ9Fat1/qTj d2KyHGmRgk7RIf28CGqwe+5aH5xq5PfJvcMmCSbDf6PX/7sOYCSe/MV+4EqNQoL4pLGd apGqzrXev9cuCr4dzkY2F0/45iglNp2E8v/+df4NHx55WMhUvMaC0lWtHDgQW5+i9rUA 5zHn7MRfwcSjSsVK8/wngrkP/kBDzzRl/GCIzOF/sjubLo23J99A7QJ2YDBPFRJEQANd e2lw== X-Gm-Message-State: AC+VfDziPXYDdwjf8CFZ4IIVPO+POm+LeRBmptiDAjA+jhZmDaDqen33 c+Vryxa1QNcdeAzGQwDUq2DDQw== X-Received: by 2002:a17:902:be08:b0:1a6:d8a3:3346 with SMTP id r8-20020a170902be0800b001a6d8a33346mr1422648pls.31.1683152272764; Wed, 03 May 2023 15:17:52 -0700 (PDT) Received: from dread.disaster.area (pa49-181-88-204.pa.nsw.optusnet.com.au. [49.181.88.204]) by smtp.gmail.com with ESMTPSA id q7-20020a170902bd8700b001a6ff7bd4d9sm22112696pls.15.2023.05.03.15.17.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 May 2023 15:17:51 -0700 (PDT) Received: from dave by dread.disaster.area with local (Exim 4.92.3) (envelope-from ) id 1puKnF-00B0ur-4U; Thu, 04 May 2023 08:17:49 +1000 Date: Thu, 4 May 2023 08:17:49 +1000 From: Dave Chinner To: John Garry Cc: axboe@kernel.dk, kbusch@kernel.org, hch@lst.de, sagi@grimberg.me, martin.petersen@oracle.com, djwong@kernel.org, viro@zeniv.linux.org.uk, brauner@kernel.org, dchinner@redhat.com, jejb@linux.ibm.com, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org, linux-scsi@vger.kernel.org, linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-security-module@vger.kernel.org, paul@paul-moore.com, jmorris@namei.org, serge@hallyn.com Subject: Re: [PATCH RFC 03/16] xfs: Support atomic write for statx Message-ID: <20230503221749.GF3223426@dread.disaster.area> References: <20230503183821.1473305-1-john.g.garry@oracle.com> <20230503183821.1473305-4-john.g.garry@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230503183821.1473305-4-john.g.garry@oracle.com> X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 03, 2023 at 06:38:08PM +0000, John Garry wrote: > Support providing info on atomic write unit min and max. > > Darrick Wong originally authored this change. > > Signed-off-by: John Garry > --- > fs/xfs/xfs_iops.c | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/fs/xfs/xfs_iops.c b/fs/xfs/xfs_iops.c > index 24718adb3c16..e542077704aa 100644 > --- a/fs/xfs/xfs_iops.c > +++ b/fs/xfs/xfs_iops.c > @@ -614,6 +614,16 @@ xfs_vn_getattr( > stat->dio_mem_align = bdev_dma_alignment(bdev) + 1; > stat->dio_offset_align = bdev_logical_block_size(bdev); > } > + if (request_mask & STATX_WRITE_ATOMIC) { > + struct xfs_buftarg *target = xfs_inode_buftarg(ip); > + struct block_device *bdev = target->bt_bdev; > + > + stat->atomic_write_unit_min = queue_atomic_write_unit_min(bdev->bd_queue); > + stat->atomic_write_unit_max = queue_atomic_write_unit_max(bdev->bd_queue); I'm not sure this is right. Given that we may have a 4kB physical sector device, XFS will not allow IOs smaller than physical sector size. The initial values of queue_atomic_write_unit_min/max() will be (1 << SECTOR_SIZE) which is 512 bytes. IOs done with 4kB sector size devices will fail in this case. Further, XFS has a software sector size - it can define the sector size for the filesystem to be 4KB on a 512 byte sector device. And in that case, the filesystem will reject 512 byte sized/aligned IOs as they are smaller than the filesystem sector size (i.e. a config that prevents sub-physical sector IO for 512 logical/4kB physical devices). There may other filesystem constraints - realtime devices have fixed minimum allocation sizes which may be larger than atomic write limits, which means that IO completion needs to split extents into multiple unwritten/written extents, extent size hints might be in use meaning we have different allocation alignment constraints to atomic write constraints, stripe alignment of extent allocation may through out atomic write alignment, etc. These are all solvable, but we need to make sure here that the filesystem constraints are taken into account here, not just the block device limits. As such, it is probably better to query these limits at filesystem mount time and add them to the xfs buftarg (same as we do for logical and physical sector sizes) and then use the xfs buftarg values rather than having to go all the way to the device queue here. That way we can ensure at mount time that atomic write limits don't conflict with logical/physical IO limits, and we can further constrain atomic limits during mount without always having to recalculate those limits from first principles on every stat() call... Cheers, Dave. -- Dave Chinner david@fromorbit.com