From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f169.google.com (mail-pl1-f169.google.com [209.85.214.169]) (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 3509F23ABA1 for ; Sun, 5 Oct 2025 22:06:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.169 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759702006; cv=none; b=mvG9L/j+SG0h/uR8ifXdsIJPRanREILsOWBE3CbJnIR9/3BT0q51uTXreAw3fLqpk/NIW/lWE39AeAf9zGoSET2XJiQUAxOo1xNksIfV7z5bmlnoS1z82Mft59d+1uDKhj3aJnPi4OJDvg5RK+V/RRNpMdigF8Xe9Qym5XnN77I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759702006; c=relaxed/simple; bh=ghK5/Akxyskde6VGn6Ahjhb7SpOkpwGVxVDkbDa5JHI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Cb9s1aRQHkyGL2DXGRPx9qTCg20gZB3Br127ozRm+t0AO4d2OjpyD6GKNBQWjxnq6VRCLmo20KM4RJdsyzoDrffx1vOGIr+d3FiVsri8Gvu0OuEbXX8mSogpQagHPdeCS9WyarW0d97Gf/y9p0A+g0fcqZ/xtFLAgmb1R7EU2SY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=fromorbit.com; spf=pass smtp.mailfrom=fromorbit.com; dkim=pass (2048-bit key) header.d=fromorbit-com.20230601.gappssmtp.com header.i=@fromorbit-com.20230601.gappssmtp.com header.b=wZBCwzMP; arc=none smtp.client-ip=209.85.214.169 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=fromorbit.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=fromorbit.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=fromorbit-com.20230601.gappssmtp.com header.i=@fromorbit-com.20230601.gappssmtp.com header.b="wZBCwzMP" Received: by mail-pl1-f169.google.com with SMTP id d9443c01a7336-269639879c3so39151375ad.2 for ; Sun, 05 Oct 2025 15:06:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fromorbit-com.20230601.gappssmtp.com; s=20230601; t=1759702004; x=1760306804; darn=vger.kernel.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=EfB79PgOGfvIs0AN5btrRu7ltzbFZlxj1NUbJbf87SE=; b=wZBCwzMPOFZBmauIC3yw6qRd3Sykz5c41p4OyQrG7RW1fqeUVQVk4+mfyM1AevAKc1 X3CNKtkrVkVwGxHS4GSCfu3viAmYXxbexjaDViFry9rBARBCcEv7pAqnB30zvTurTMSo ySylK2bcuJtlFWgHiUImDjfDfksXzOAzufpJHwfBsyZPBePY489kw9DUfFfOAUuC4Z2u nrSD3sltjbgbhrvL9Ru6C9W+9NuMNXwg27vo9iJ9iNMlyGyoxLOfHvcmS7YZ1vUz6vNg tVFSaRWyR3S4PzXDIKUy1sfNMftKsb077+bSXLRau2LyPrSCH/F4tw8ItMuGH4GDxKtZ MQpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1759702004; x=1760306804; 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=EfB79PgOGfvIs0AN5btrRu7ltzbFZlxj1NUbJbf87SE=; b=NZ+9VFpPXGNJl2nLT2u0y4qeja9flpOr9hU2Vg6fz4uNpRJYPdWoxEG4VqPaaH2xWx GTrtxXJdhI+IK0IfUx9jKIb44uXUr4jhCAF3NjKBDKBAnNEklJqct3GjyGczi5HrC1Fw 0L5I+JaGeZUGVDPOp9amKJnTGLUPUP4jA2M//sNdwl27fAyIUojyyJQjFFARn+u4vg6z DhN6dPgDmvIFKyTkjXjTsl75TuqdFIh5NGdzeuqXMsNqqP/9uD4ivUCvAvcTGVFnjcZq 2qcPQoOrYk6oJOQi1C526KtLXF1gONpzQeHizY4alusiqOlcgIIg/ufgj0eg48lM0KqP wJfg== X-Forwarded-Encrypted: i=1; AJvYcCXYpC877qJsvSOfEFlVQGII/3qsmmVkIfptwLQ8HvXYnyVt47LgN3WX9DDZXyOl1ySwyoOkYqVAJyo=@vger.kernel.org X-Gm-Message-State: AOJu0YzbKhvB5evckYsL/pQzVF4vbZrch4KGCtjYi+wWmbeBguTPCpqv YDG/HykOEkzynn3m2RNh/czZNwbyIfPlqa/I1tVNl7D+GPt19BOh1xDsfTSzNpB/4nI= X-Gm-Gg: ASbGncvL0TciBb+rmi5HG1G/zs1V5DFjCJSlhg/ptUVSpWi388oj4GwODmlpJKbe09w 5wkio46dl3TXJplFDWlQV675470o1oSls5mcO/xmStNJb7thnTmSgc7stM1kP2mb8BjZNp5do3B 2LsskOvtpXjdVx89wHKozr8K182qpTMwwQtqVohLCw44xPAwCF+Qi2dTc349aMMCPeTyFdUNHhx rcnoX/1febzFpMjK8BN1GPUg66KLotCyU3iQmaE1icWx6FosrtGq5asWc4YEqP33G/jTlg19HXt pYdd7xQFtACGN0w1lZlwrJNF1UyYC1mX8ALnASaj008nehOL1OXDWculW70Kq2o+u5Qt503WsgD DkBXfGBiGw2LIVosnIhkCflGxH8+gKStsTqio4l2EzM+GBVoZW29cbzbEzuYWfzCT05HIzhUp6q C+2cIxU7LgC6ilwVN4hc7lDtWl/2Yizsif X-Google-Smtp-Source: AGHT+IENWyTXPDADMQ43Q+qUkEcxH8/Cfr1KV4BDn/buPYFW/8tWf4Jvv5Qv2AAxqHLtTLmLsOKCaA== X-Received: by 2002:a17:903:3c48:b0:269:805c:9447 with SMTP id d9443c01a7336-28e9a5bd2c0mr110553955ad.4.1759702004172; Sun, 05 Oct 2025 15:06:44 -0700 (PDT) Received: from dread.disaster.area (pa49-180-91-142.pa.nsw.optusnet.com.au. [49.180.91.142]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-28e8d1269b8sm111302175ad.50.2025.10.05.15.06.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 05 Oct 2025 15:06:43 -0700 (PDT) Received: from dave by dread.disaster.area with local (Exim 4.98.2) (envelope-from ) id 1v5WsK-0000000B0Wz-40rk; Mon, 06 Oct 2025 09:06:40 +1100 Date: Mon, 6 Oct 2025 09:06:40 +1100 From: Dave Chinner To: Christoph Hellwig Cc: Pavel Emelyanov , linux-fsdevel@vger.kernel.org, "Raphael S . Carvalho" , linux-api@vger.kernel.org, linux-xfs@vger.kernel.org Subject: Re: [PATCH] fs: Propagate FMODE_NOCMTIME flag to user-facing O_NOCMTIME Message-ID: References: <20251003093213.52624-1-xemul@scylladb.com> Precedence: bulk X-Mailing-List: linux-api@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Fri, Oct 03, 2025 at 09:26:50PM -0700, Christoph Hellwig wrote: > On Fri, Oct 03, 2025 at 12:32:13PM +0300, Pavel Emelyanov wrote: > > The FMODE_NOCMTIME flag tells that ctime and mtime stamps are not > > updated on IO. The flag was introduced long ago by 4d4be482a4 ([XFS] > > add a FMODE flag to make XFS invisible I/O less hacky. Back then it > > was suggested that this flag is propagated to a O_NOCMTIME one. > > skipping c/mtime is dangerous. The XFS handle code allows it to > support HSM where data is migrated out to tape, and requires > CAP_SYS_ADMIN. Allowing it for any file owner would expand the scope > for too much as now everyone could skip timestamp updates. > > > It can be used by workloads that want to write a file but don't care > > much about the preciese timestamp on it and can update it later with > > utimens() call. If you don't care about accurate c/mtime, then mount the filesystem with '-o lazytime' to degrade c/mtime updates to "eventual consistency" behaviour for IO operations. If inode metadata is otherwise modified (e.g. block allocation during IO) or the application then calls utimens(), it will update the recorded in-memory timestamps in a persistent manner immediately. > The workload might not care, the rest of the system does. ctime can't > bet set to arbitrary values, so it is important for backups and as > an audit trail. But we can (and do) delay the persistence of IO-based timestamp updates with the lazytime option. > > There's another reason for having this patch. When performing AIO write, > > the file_modified_flags() function checks whether or not to update inode > > times. In case update is needed and iocb carries the RWF_NOWAIT flag, > > the check return EINTR error that quickly propagates into cb completion > > without doing any IO. This restriction effectively prevents doing AIO > > writes with nowait flag, as file modifications really imply time update. > > Well, we'll need to look into that, including maybe non-blockin > timestamp updates. Lazytime updates can generally be done in a non-blocking manner right now (someone raised that in the context of io-uring on #xfs about a month ago), but the NOWAIT behaviour for timestamp updates is done at a higher level in the VFS and does not take into account filesystem specific non-blocking lazytime updates at all. If we push the NOWAIT checking behaviour down to the filesystem, we can do this. -Dave. -- Dave Chinner david@fromorbit.com