From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f173.google.com (mail-pl1-f173.google.com [209.85.214.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 098162D0C84 for ; Tue, 10 Mar 2026 05:49:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.173 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773121800; cv=none; b=Fr5SYEd24VFohzO6nvTBTfcomq6ndchTEA+WcOpbGSnA+hwnNuHweovI916uTAjKCiV6DMeyPboxykBoaG9909GIsVZ+SkRFvsMF84g5hQ0y531uGeXgaNxvqov1xEJFHzTYHQ1GcCsYSqurN9dMhc0fRrw2VXWmQcRPjluu/Cw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773121800; c=relaxed/simple; bh=/QAlSwxCL3YeNfXvPolDNjg6x5KjVV4GoQBz310VDH4=; h=From:To:Cc:Subject:In-Reply-To:Date:Message-ID:References; b=WE02PhbLGN3RD0wFshymfOhNz0uZJ1qkqucR7J+9RhlRKXP0FDZoUrZnSYy+IXRbiZjRcOjDrH7NUxXYnQY3jo4ns7Xj89veo/wu2m+b3okBV/YbYoQHLw0kdhHzm4zTTLN3sliekmRD76qQ/+A9SiztZ4fMe5NNzvuk9Y/AgVE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=esYbiJki; arc=none smtp.client-ip=209.85.214.173 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="esYbiJki" Received: by mail-pl1-f173.google.com with SMTP id d9443c01a7336-2ae5636ab04so91306875ad.3 for ; Mon, 09 Mar 2026 22:49:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773121791; x=1773726591; darn=vger.kernel.org; h=references:message-id:date:in-reply-to:subject:cc:to:from:from:to :cc:subject:date:message-id:reply-to; bh=4e252tvJ7wgS17IJwLKwEjk90VH1IZzHII9iIV6zg7Q=; b=esYbiJkiOa6c8VSgEzfgVXJuvYifvl+0q4JtztlYusRJ2yS2o+IW53jcS1Gh7Sa1zJ OK1NzXHwY3gIogRdojWGGeNpHbtxFoqU4oWOFwtZPapA6t2R/2bPe4q/1gjSqDbwE7j0 0ViKkLxcdNU0AGkFDlPVU5UxlQsE3w9cMrDzHiDXyrFgINheHP3vuYr3TFBRQBN1lpsa inn3/rzY7u6S28iirMr8RCCredVxLiR93Qob8HqfiabeHwBi6v1QJtpVvPJ8av+nm2yt mH7+TAstxnAl4qeK996HdDRIu6X6PG815P1PojaQH0DBYm2+prSgRapD9xT+o8KAzPdU FiNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773121791; x=1773726591; h=references:message-id:date:in-reply-to:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=4e252tvJ7wgS17IJwLKwEjk90VH1IZzHII9iIV6zg7Q=; b=IHi0cJ6Y6rsgW8eBFCqRKnON/s0NjFJwqW48ip0mw+kzeFJmJAtNPWZNVweRJ1jc4r Dd9/c1mkZww3CCi3Fpxjuh5qEuR0Alako49aCi7eQLBaeUCTx1pA7p1q1xi69CrA3+DB 2Q5arQWs02O7VeRYB8ssIy71cV78nRRGmikysuEpbplx4Qw60p+FDMH6V5BZjWfJBqUQ iZSa2envXRVNGSx6DUe57j6B0/X0/w+xoP9DS3ZW+IMqn7vOPs7ehNLCu3t3N7aZlQei +bLW5b5vdDw6s2i9fqWv3BWzKv/2mdAlCigSJADlhfFZK/X4wL7yi7VCnTCouX5tijU/ EPjw== X-Forwarded-Encrypted: i=1; AJvYcCXhGVX1dA3kAnjhx0q+eYu72bk3MZqWmn0O9G/QXoPf3QByS0jFcgT3rf+lsnlUcAeFiZjOjpdqdfjAqzY=@vger.kernel.org X-Gm-Message-State: AOJu0YzYSBBnOPLFwoxd+53Mi2/tSUCpl4on+fcrhoeIs7gT2dlkNhkO SPTgaSEbPUbGUzBejm4BZ0DrTZWVOPHB0YYylB7KdsmHuasP7xyU2S5bYW6Fs1Ng X-Gm-Gg: ATEYQzwXrPYcujytX4h3PXwGhvmz+SeHFlxV5cP63caK3iTUTHbynuquacL5xXwVnM9 nfw2A2RyILBNOW9aHctvTZiSgolKyDxFc+RXhwf7jHpguLzIiXCd/BKQ7fF1Zy9oIjK/ECFtVGZ HfEUT9d9FjhHbrcgmCG0ZHZryMuf69MLi4syDwLAKUMiGGwVOrwUUQMKBsGD9E5Jsl8pKOrwwb/ zCr4PxHxdI/sBBhOfrFLq/3EJ3922W63CggbEbDUXXfSBT61W7LUNxt16UFQuI2f4gk4TlktJls HV3TPBFt9c+LGBrIFjlLsPV7MyqgY818OKWDuvgvpJu2NzJYbZRFmVBeyj46eROWQWw9+veMhHS 7DqWLzvZMgNf+H/wr68x0eqkLXXnZwKnQqcWkQQVZ0dTO9yc/UJaZG/nqITDyjQ7ciPDIxTecQ9 78+xE7BKqKFtvtCM+R6tFSVQ== X-Received: by 2002:a17:902:ea02:b0:2ae:7ed6:46e3 with SMTP id d9443c01a7336-2ae824441d8mr137516745ad.27.1773121791358; Mon, 09 Mar 2026 22:49:51 -0700 (PDT) Received: from pve-server ([49.205.216.49]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2ae83e58592sm187181675ad.14.2026.03.09.22.49.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Mar 2026 22:49:50 -0700 (PDT) From: Ritesh Harjani (IBM) To: "Darrick J. Wong" , Ojaswin Mujoo Cc: linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, john.g.garry@oracle.com, willy@infradead.org, hch@lst.de, jack@suse.cz, Luis Chamberlain , dgc@kernel.org, tytso@mit.edu, p.raghav@samsung.com, andres@anarazel.de, linux-kernel@vger.kernel.org Subject: Re: [RFC 2/3] iomap: Enable stable writes for RWF_WRITETHROUGH inodes In-Reply-To: <20260310035719.GI1105363@frogsfrogsfrogs> Date: Tue, 10 Mar 2026 10:55:04 +0530 Message-ID: <4imouuhb.ritesh.list@gmail.com> References: <3704b81046b11f8b8da0367c7c8ad8767f42e5df.1773076216.git.ojaswin@linux.ibm.com> <20260310035719.GI1105363@frogsfrogsfrogs> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: "Darrick J. Wong" writes: > On Mon, Mar 09, 2026 at 11:04:32PM +0530, Ojaswin Mujoo wrote: >> Currently, RWF_WRITETHROUGH writes wait for writeback to complete >> on a folio before performing the writethrough. This serializes >> writethrough with each other and the writeback path. However, it is also >> desirable have similar guarantees between RWF_WRITETHROUGH and non >> writethrough writes. >> >> Hence, ensure stable writes are enabled on an inode's mapping as >> long as a writethrough write is ongoing. This way, all paths will >> wait for RWF_WRITETHROUGH to complete on a folio before proceeding. >> >> To track inflight writethrough writes, we use an atomic counter in the >> inode->i_mapping. This struct was chosen because (i) writethrough is an >> operation on the folio and (ii) we don't want to add bloat to struct >> inode. Now I am also questioning the need of this counter. If mapping has AS_STABLE_WRITES bit set, then that means the inode->mapping is going through stable writes until that bit is cleared. And since in future we are going to add support of async buffered write-through, so the stable writes bit should get cleared in the completion path (like how it is done now.) > > What if we just set it whenever someone successfully initiates a > RWF_WRITETHROUGH write? Then we wouldn't need all this atomic counter > machinery. > I agree. If we set the mapping as stable before initiating iomap_write_begin() itself, then we don't need this atomic counter. Maybe, we can set it in iomap_file_writethrough_write() itself (we have mapping available from iocb). > Also: What if some filesystem (not xfs, obviously) finds a need to > change the stablepages bit while there might be writethrough writes in > progress? Is there a usecase where this can happen (just curious)? > It's a little awkward to have a flag /and/ a counter; why not > change mapping_{set,clear}_stable_pages to inc and dec the counter and > base the test off that? > Yes, either ways, I agree that I don't see the need of an extra counter here. -ritesh