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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 88BA6C10F1A for ; Wed, 1 May 2024 08:33:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0285D6B0089; Wed, 1 May 2024 04:33:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EF3666B008A; Wed, 1 May 2024 04:33:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D6D226B008C; Wed, 1 May 2024 04:33:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id B469E6B0089 for ; Wed, 1 May 2024 04:33:11 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 6597D14012B for ; Wed, 1 May 2024 08:33:11 +0000 (UTC) X-FDA: 82069162182.13.E789E40 Received: from mail-pj1-f50.google.com (mail-pj1-f50.google.com [209.85.216.50]) by imf23.hostedemail.com (Postfix) with ESMTP id 8DE7F14000C for ; Wed, 1 May 2024 08:33:08 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=fromorbit-com.20230601.gappssmtp.com header.s=20230601 header.b=AhZRbhCf; spf=pass (imf23.hostedemail.com: domain of david@fromorbit.com designates 209.85.216.50 as permitted sender) smtp.mailfrom=david@fromorbit.com; dmarc=pass (policy=quarantine) header.from=fromorbit.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1714552388; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ZTYNlvyrYVbQYSeq48cS2P70mX2dX5gOsnD6+FgyUPQ=; b=IZljeHHpMPVyby2de5IX5PAfSfNX6xpNsUJxCbZFSNvjq/8bnbKA8zi35JTq+l3K06xaR7 z4lgD7kCahdZ+7f+yojBJzHWJ5xAghj2ODiCxKuZm74qzDZwdXF3To/yUmLx971jufNYW3 rSC5Q4HC07tYmjzeZ05RMF4MUh4gado= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=fromorbit-com.20230601.gappssmtp.com header.s=20230601 header.b=AhZRbhCf; spf=pass (imf23.hostedemail.com: domain of david@fromorbit.com designates 209.85.216.50 as permitted sender) smtp.mailfrom=david@fromorbit.com; dmarc=pass (policy=quarantine) header.from=fromorbit.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1714552388; a=rsa-sha256; cv=none; b=JxRaebJKSjX/IxaKpvAhb5N8skl4tOE08aJ0ALUSr6sN7PdwUfpibAe7GL7NZ9PZAfaz1K BqS+srUpH4+8fLm3naIOa+3/exjKtXiomVrRLz2HAbZQ1b6nzFPEwHeoTjmV9x378d9fJf n/EodyscDYssr//7+JsMsCasqDfs4o8= Received: by mail-pj1-f50.google.com with SMTP id 98e67ed59e1d1-2a55a3d0b8eso446828a91.1 for ; Wed, 01 May 2024 01:33:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fromorbit-com.20230601.gappssmtp.com; s=20230601; t=1714552387; x=1715157187; darn=kvack.org; 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=ZTYNlvyrYVbQYSeq48cS2P70mX2dX5gOsnD6+FgyUPQ=; b=AhZRbhCfGVKED0ZS3bK/TvJT12Q0I5ACa0FWzrJIU4I7KFGfZJRJHQ2agwaXV9ulOo /IGLOljaK/8d+8FJ90A/b9gUUhIqXlz0S9bcW/sASCXuG4fxUPP5QTxbI5aFw/P1XGCL 7Z4jxfSQea4KTBXPF0mhmFTvDZCCOFV5dhU/8HVFCzlLXTsa3FFNjPImTZWEM6NytzTT KJaOTYJuOS9y5u/fkRDwqfobMBpGpMQ5+3dcijPo4g+Pd+vLf2TojMUxSu19ECz+xNsp eC4UeX/xURCh19K9SBYlKfnW0jlV80ld0p/f3KlzW/nYfKbkZe/iHkj6CdjTiV11yslY ArrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714552387; x=1715157187; 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=ZTYNlvyrYVbQYSeq48cS2P70mX2dX5gOsnD6+FgyUPQ=; b=bXMoFX3o+FZGJFcLCv56aYnpafs6FE7j+0KsYqxCqPOvCfwAlIY6/3KdPWlq0NVZM/ 8cf99Sp1YRw/USTBot75yeSGeNNORYCksR6ju2x2XXQray6V1GU1DpBUEYcw1O4rzWh+ tsP4Wo9EWIICgy+dIdT2QIrmhCKn02GGhonYGS0lIGKlUx5nDFBraeKAzrJvmq1JZijT W3OzTMb8PiOAunE0hiMhQkRlFSeOApgNbmfCJpnbNxbbLMWnbtxGbhRyy6cXg/iloLtA E8sEb3F4hzd6u6T0eJe+mXxvYxLuO+1Jjsi5qGoGiPWrZgkuVys694nZ/i8/jGTmzX7O t8Cg== X-Forwarded-Encrypted: i=1; AJvYcCVT19UvgQt+/ucnycfhnCRnywSk6BUbDL0xZ6UDTZntgYLvHSpBGIuUPFiD+6LU7Yon/N6xQB+ppO3pvESweqDwrlI= X-Gm-Message-State: AOJu0Ywg8LrFiaCi2VR7FtZ2DrvOWrV4fNTUF94IIGIhCyazGVbxdfUs JUxL1CjHFKDlRqbTNPvGjqbVjOA7DMYBZYHnf4GKU2guQJbcSYKrqvBx4rYVY/Y= X-Google-Smtp-Source: AGHT+IEiZg4Ov1wyuvwipwKu7F/ZM1MAg10yW7QiVfhsFN3PpgghzgYyHjehJ85DP2fIrKsN7R9vJA== X-Received: by 2002:a17:90a:a592:b0:2b1:cf6a:848 with SMTP id b18-20020a17090aa59200b002b1cf6a0848mr7414655pjq.7.1714552387057; Wed, 01 May 2024 01:33:07 -0700 (PDT) Received: from dread.disaster.area (pa49-179-32-121.pa.nsw.optusnet.com.au. [49.179.32.121]) by smtp.gmail.com with ESMTPSA id sx11-20020a17090b2ccb00b002b1750f228csm874075pjb.7.2024.05.01.01.33.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 May 2024 01:33:06 -0700 (PDT) Received: from dave by dread.disaster.area with local (Exim 4.96) (envelope-from ) id 1s25Oi-00HAPQ-1S; Wed, 01 May 2024 18:33:04 +1000 Date: Wed, 1 May 2024 18:33:04 +1000 From: Dave Chinner To: Zhang Yi Cc: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, tytso@mit.edu, adilger.kernel@dilger.ca, jack@suse.cz, ritesh.list@gmail.com, hch@infradead.org, djwong@kernel.org, willy@infradead.org, zokeefe@google.com, yi.zhang@huawei.com, chengzhihao1@huawei.com, yukuai3@huawei.com, wangkefeng.wang@huawei.com Subject: Re: [RFC PATCH v4 24/34] ext4: implement buffered write iomap path Message-ID: References: <20240410142948.2817554-1-yi.zhang@huaweicloud.com> <20240410142948.2817554-25-yi.zhang@huaweicloud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 8DE7F14000C X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: mh8epbpqshwodcnprqnpe8kx33nfcdj4 X-HE-Tag: 1714552388-646311 X-HE-Meta: U2FsdGVkX18FwUt5bHdILXCQujLNyM+Tm/F2x8c6YBWiWc7nybI849/JBdsPOVZ0l2ZY4uXP2ZOoacv9jKaVlPEoiYMQHaUKSwE+5A977ZmXjhUwHIDifaQgGv/Kin4ZRIYRmJtD1ztG3dYLgqF1BwB+ysv1Qy/19gjnEsyQ7R0xc3YeJ3BNa1lt/VYsgjL/JfHduBZBP+HEzAPgOg4vnVMJzamn6Y4eGtudj5SxTqBsX8f+geuPRInV6HJ/bE4IzM7tc4zBdUxtPBR3Lani0hBzIC7FpnYnsVjI1RA5/ZLy4hYOub8ixqh4Dsw1Vu6HvZEIYeLIXcL99AnhYROe7B9b0cTTZZKxqbzYIgjG6EXZX/eji/qnCzLLthezljYr46jX/hM6r/3m9qEhFwCtbDNUap44lXJj7Ot+cOJsEO+Nr2NXUsveM0OkLOyGDVL035YQ7bG5+qbO0EJTaHyR1F02KaudI5Ou7bXxhtjoYkgYYaxk+amnzIbHEMzhJliFd858VDAPOlrcS1OzXGE+Yljtn3VsrSgxH6HUWxpApOmfalGXt104bf5Gf/jvzw0cJSi0Se6U1N+FY8MK2aYhruCSUQVPBQFytW36/o9MlZTMUMo7kV8WoMbPVPIQQfhUuQw5j04Svti1MKokbrqsnZqqdqcaAD67ElIr3GtnEJACwtNs67JUKe3C2lfBQN/e58cc4rKEmEF22wQbR7qse4ih7TbR/GB1soEt+4JDEEg5hLYdIw7NwDKAfJ6ODgd2J7atQcVMIRvMUs2onlE5aGDKEqQrqD2y0VYui+JnWvPBcrMlCUgvCtz05kih0WH6vcusA1fBvNuBhGefaUfFKSqeISZ3zuvtYTCqoHleGT09/b++FA3RHmyNsgxX+B8wXCh8t49IQgxnHRylLNoPpkrgKKxa3JxT1SB7NUzJ2MbVhTesU5W9KiOTgUl8L6Btj2kiC4PzUogrf8VHQWV 2wn11/kT ecMuLjCgdoL5r74Jv8pxwCvMyeFdhXg9fzI6PMhDkDlLcGru/kfQEaWMnmVV4ta5+0kG3Zaz3USaxfGVlCg9VMWOFPDdbe4rnEJUwPo6s7ACiYs87U2uD1ZaWkcD5VAlN29ScRvpY8P37oeEvem7v9pRitJmmN9qr3y3S12RBakomb2o1CTTHTb7jknPYEIeilhOt6zRqXfkrKJEUsQOLVxXMHbpfqcTnnyjIUf3Yz7q+x0rtHuRjSi7iy+yFCse1lh32g1bcHhv79ETcHPpxa9xR3ntzVZUGZoqkkSnUNI5sbIOmZQw1Q+wRckTJwfQklvlM2cvQlIvjRvc/myJnjweFei9py0Qf8zOS+vlZxMCeYNEhddbFA0N5DgpCfLyCzATaJwRTxg34WzyJGFZZqwiogiR1l86Bw6HOA1Yw9kg9ukuxX6NoTXM9kqxkBGIkL+Iy4PwMWBT8nNRhHjJ06nLNZQK4FRKGi2KITjOtMmV61hz+49NsJPP5yOc0VQSbvOFKuIZjg9TcDkCpItCnwv16gTrgI90Ob5o4 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: List-Subscribe: List-Unsubscribe: On Wed, May 01, 2024 at 06:11:13PM +1000, Dave Chinner wrote: > On Wed, Apr 10, 2024 at 10:29:38PM +0800, Zhang Yi wrote: > > From: Zhang Yi > > > > Implement buffered write iomap path, use ext4_da_map_blocks() to map > > delalloc extents and add ext4_iomap_get_blocks() to allocate blocks if > > delalloc is disabled or free space is about to run out. > > > > Note that we always allocate unwritten extents for new blocks in the > > iomap write path, this means that the allocation type is no longer > > controlled by the dioread_nolock mount option. After that, we could > > postpone the i_disksize updating to the writeback path, and drop journal > > handle in the buffered dealloc write path completely. ..... > > +/* > > + * Drop the staled delayed allocation range from the write failure, > > + * including both start and end blocks. If not, we could leave a range > > + * of delayed extents covered by a clean folio, it could lead to > > + * inaccurate space reservation. > > + */ > > +static int ext4_iomap_punch_delalloc(struct inode *inode, loff_t offset, > > + loff_t length) > > +{ > > + ext4_es_remove_extent(inode, offset >> inode->i_blkbits, > > + DIV_ROUND_UP_ULL(length, EXT4_BLOCK_SIZE(inode->i_sb))); > > return 0; > > } > > > > +static int ext4_iomap_buffered_write_end(struct inode *inode, loff_t offset, > > + loff_t length, ssize_t written, > > + unsigned int flags, > > + struct iomap *iomap) > > +{ > > + handle_t *handle; > > + loff_t end; > > + int ret = 0, ret2; > > + > > + /* delalloc */ > > + if (iomap->flags & IOMAP_F_EXT4_DELALLOC) { > > + ret = iomap_file_buffered_write_punch_delalloc(inode, iomap, > > + offset, length, written, ext4_iomap_punch_delalloc); > > + if (ret) > > + ext4_warning(inode->i_sb, > > + "Failed to clean up delalloc for inode %lu, %d", > > + inode->i_ino, ret); > > + return ret; > > + } > > Why are you creating a delalloc extent for the write operation and > then immediately deleting it from the extent tree once the write > operation is done? Ignore this, I mixed up the ext4_iomap_punch_delalloc() code directly above with iomap_file_buffered_write_punch_delalloc(). In hindsight, iomap_file_buffered_write_punch_delalloc() is poorly named, as it is handling a short write situation which requires newly allocated delalloc blocks to be punched. iomap_file_buffered_write_finish() would probably be a better name for it.... > Also, why do you need IOMAP_F_EXT4_DELALLOC? Isn't a delalloc iomap > set up with iomap->type = IOMAP_DELALLOC? Why can't that be used? But this still stands - the first thing iomap_file_buffered_write_punch_delalloc() is: if (iomap->type != IOMAP_DELALLOC) return 0; Cheers, Dave. -- Dave Chinner david@fromorbit.com