linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: John Garry <john.g.garry@oracle.com>
Cc: Christoph Hellwig <hch@lst.de>,
	axboe@kernel.dk, brauner@kernel.org, viro@zeniv.linux.org.uk,
	jack@suse.cz, dchinner@redhat.com, cem@kernel.org,
	linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	hare@suse.de, martin.petersen@oracle.com,
	catherine.hoang@oracle.com, mcgrof@kernel.org,
	ritesh.list@gmail.com, ojaswin@linux.ibm.com
Subject: Re: [PATCH v7 5/8] xfs: Support FS_XFLAG_ATOMICWRITES
Date: Tue, 15 Oct 2024 17:52:01 -0700	[thread overview]
Message-ID: <20241016005201.GH21836@frogsfrogsfrogs> (raw)
In-Reply-To: <f0febabf-25ee-4fbe-9dfe-77a240cc29db@oracle.com>

On Sun, Oct 13, 2024 at 10:06:04PM +0100, John Garry wrote:
> On 07/10/2024 06:42, Christoph Hellwig wrote:
> > On Fri, Oct 04, 2024 at 02:07:05PM +0100, John Garry wrote:
> > > Sure, that is true (about being able to atomically write 1x FS block if the
> > > bdev support it).
> > > 
> > > But if we are going to add forcealign or similar later, then it would make
> > > sense (to me) to have FS_XFLAG_ATOMICWRITES (and its other flags) from the
> > > beginning. I mean, for example, if FS_XFLAG_FORCEALIGN were enabled and we
> > > want atomic writes, setting FS_XFLAG_ATOMICWRITES would be rejected if AG
> > > count is not aligned with extsize, or extsize is not a power-of-2, or
> > > extsize exceeds bdev limits. So FS_XFLAG_ATOMICWRITES could have some value
> > > there.
> > > 
> > > As such, it makes sense to have a consistent user experience and require
> > > FS_XFLAG_ATOMICWRITES from the beginning.
> > 
> > Well, even with forcealign we're not going to lose support for atomic
> > writes <= block size, are we?
> > 
> 
> forcealign would not be required for atomic writes <= FS block size.
> 
> How about this modified approach:
> 
> a. Drop FS_XFLAG_ATOMICWRITES support from this series, and so we can always
> atomic write 1x FS block (if the bdev supports it)
> 
> b. If we agree to support forcealign afterwards, then we can introduce 2x
> new flags:
> 	- FS_XFLAG_FORCEALIGN - as before
> 	- FS_XFLAG_BIG_ATOMICWRITES - this depends on  FS_XFLAG_FORCEALIGN being
> enabled per inode, and allows us to atomically write > 1 FS block
> 
> c. Later support writing < 1 FS block
> 	- this would not depend on forcealign
> 	- would require a real user, and I don't know one yet
> 
> better?

Sounds fine to /me/, but that's just my opinion. :)

--D

  reply	other threads:[~2024-10-16  0:52 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-04  9:22 [PATCH v7 0/8] block atomic writes for xfs John Garry
2024-10-04  9:22 ` [PATCH v7 1/8] block/fs: Pass an iocb to generic_atomic_write_valid() John Garry
2024-10-04  9:22 ` [PATCH v7 2/8] fs: Export generic_atomic_write_valid() John Garry
2024-10-04  9:22 ` [PATCH v7 3/8] fs/block: Check for IOCB_DIRECT in generic_atomic_write_valid() John Garry
2024-10-04 12:34   ` Christoph Hellwig
2024-10-04 12:45     ` John Garry
2024-10-04  9:22 ` [PATCH v7 4/8] fs: iomap: Atomic write support John Garry
2024-10-04  9:22 ` [PATCH v7 5/8] xfs: Support FS_XFLAG_ATOMICWRITES John Garry
2024-10-04 12:35   ` Christoph Hellwig
2024-10-04 13:07     ` John Garry
2024-10-07  5:42       ` Christoph Hellwig
2024-10-13 21:06         ` John Garry
2024-10-16  0:52           ` Darrick J. Wong [this message]
2024-10-04  9:22 ` [PATCH v7 6/8] xfs: Support atomic write for statx John Garry
2024-10-04  9:22 ` [PATCH v7 7/8] xfs: Validate atomic writes John Garry
2024-10-04  9:22 ` [PATCH v7 8/8] xfs: Support setting FMODE_CAN_ATOMIC_WRITE John Garry

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20241016005201.GH21836@frogsfrogsfrogs \
    --to=djwong@kernel.org \
    --cc=axboe@kernel.dk \
    --cc=brauner@kernel.org \
    --cc=catherine.hoang@oracle.com \
    --cc=cem@kernel.org \
    --cc=dchinner@redhat.com \
    --cc=hare@suse.de \
    --cc=hch@lst.de \
    --cc=jack@suse.cz \
    --cc=john.g.garry@oracle.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=mcgrof@kernel.org \
    --cc=ojaswin@linux.ibm.com \
    --cc=ritesh.list@gmail.com \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).