All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: John Garry <john.g.garry@oracle.com>
Cc: brauner@kernel.org, hch@lst.de, viro@zeniv.linux.org.uk,
	jack@suse.cz, cem@kernel.org, linux-fsdevel@vger.kernel.org,
	dchinner@redhat.com, linux-xfs@vger.kernel.org,
	linux-kernel@vger.kernel.org, ojaswin@linux.ibm.com,
	ritesh.list@gmail.com, martin.petersen@oracle.com,
	linux-ext4@vger.kernel.org, linux-block@vger.kernel.org,
	catherine.hoang@oracle.com, linux-api@vger.kernel.org
Subject: Re: [PATCH v7 11/14] xfs: add xfs_file_dio_write_atomic()
Date: Mon, 21 Apr 2025 09:42:41 -0700	[thread overview]
Message-ID: <20250421164241.GD25700@frogsfrogsfrogs> (raw)
In-Reply-To: <2467484b-382b-47c2-ae70-4a41d63cf4fc@oracle.com>

On Mon, Apr 21, 2025 at 06:47:44AM +0100, John Garry wrote:
> On 21/04/2025 05:00, Darrick J. Wong wrote:
> > > @@ -843,6 +909,8 @@ xfs_file_dio_write(
> > >   		return xfs_file_dio_write_unaligned(ip, iocb, from);
> > >   	if (xfs_is_zoned_inode(ip))
> > >   		return xfs_file_dio_write_zoned(ip, iocb, from);
> > What happens to an IOCB_ATOMIC write to a zoned file?  I think the
> > ioend for an atomic write to a zoned file involves a similar change as
> > an outofplace atomic write to a file (one big transaction to absorb
> > all the mapping changes) but I don't think the zoned code quite does
> > that...?
> 
> Correct. For now, I don't think that we should try to support zoned device
> atomic writes. However we don't have proper checks for this. How about
> adding a xfs_has_zoned() check in xfs_get_atomic_write_{min, max, opt}()?

Well it turns out that was a stupid question -- zoned=1 can't be enabled
with reflink, which means there's no cow fallback so atomic writes just
plain don't work:

$ xfs_info /mnt
meta-data=/dev/sda               isize=512    agcount=4, agsize=32768 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=1, rmapbt=1
         =                       reflink=0    bigtime=1 inobtcount=1 nrext64=1
         =                       exchange=1   metadir=1
data     =                       bsize=4096   blocks=131072, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1, parent=1
log      =internal log           bsize=4096   blocks=16384, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =internal               extsz=4096   blocks=5061632, rtextents=5061632
         =                       rgcount=78   rgsize=65536 extents
         =                       zoned=1      start=131072 reserved=0
$ xfs_io -c 'statx -r -m 0x10000' /mnt/a | grep atomic
stat.atomic_write_unit_min = 0
stat.atomic_write_unit_max = 0
stat.atomic_write_segments_max = 0
stat.atomic_write_unit_max_opt = 0

I /think/ all you'd have to do is create an xfs_zoned_end_atomic_io
function that does what xfs_zoned_end_io but with a single
tr_atomic_ioend transaction; figure out how to convey "this is an
atomic out of place write" to xfs_end_ioend so that it knows to call
xfs_zoned_end_atomic_io; and then update the xfs_get_atomic_write*
helpers.

--D

> Thanks,
> John

  reply	other threads:[~2025-04-21 16:42 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-15 12:14 [PATCH v7 00/14] large atomic writes for xfs John Garry
2025-04-15 12:14 ` [PATCH v7 01/14] fs: add atomic write unit max opt to statx John Garry
2025-04-15 12:14 ` [PATCH v7 02/14] xfs: add helpers to compute log item overhead John Garry
2025-04-15 12:14 ` [PATCH v7 03/14] xfs: add helpers to compute transaction reservation for finishing intent items John Garry
2025-04-15 12:14 ` [PATCH v7 04/14] xfs: rename xfs_inode_can_atomicwrite() -> xfs_inode_can_hw_atomicwrite() John Garry
2025-04-15 12:14 ` [PATCH v7 05/14] xfs: allow block allocator to take an alignment hint John Garry
2025-04-15 12:14 ` [PATCH v7 06/14] xfs: refactor xfs_reflink_end_cow_extent() John Garry
2025-04-15 12:14 ` [PATCH v7 07/14] xfs: refine atomic write size check in xfs_file_write_iter() John Garry
2025-04-15 12:14 ` [PATCH v7 08/14] xfs: add xfs_atomic_write_cow_iomap_begin() John Garry
2025-04-15 12:14 ` [PATCH v7 09/14] xfs: add large atomic writes checks in xfs_direct_write_iomap_begin() John Garry
2025-04-15 17:34   ` Darrick J. Wong
2025-04-15 17:46     ` John Garry
2025-04-15 12:14 ` [PATCH v7 10/14] xfs: commit CoW-based atomic writes atomically John Garry
2025-04-15 12:14 ` [PATCH v7 11/14] xfs: add xfs_file_dio_write_atomic() John Garry
2025-04-21  4:00   ` Darrick J. Wong
2025-04-21  5:47     ` John Garry
2025-04-21 16:42       ` Darrick J. Wong [this message]
2025-04-23  5:42         ` Christoph Hellwig
2025-04-23  8:19           ` Christoph Hellwig
2025-04-23 14:51             ` Darrick J. Wong
2025-04-23 14:53           ` Darrick J. Wong
2025-04-21 21:18   ` Luis Chamberlain
2025-04-22  6:08     ` John Garry
2025-04-23  5:18       ` Luis Chamberlain
2025-04-23  7:08         ` John Garry
2025-04-23  7:36           ` Luis Chamberlain
2025-04-23  5:44       ` Christoph Hellwig
2025-04-23  7:02         ` John Garry
2025-04-15 12:14 ` [PATCH v7 12/14] xfs: add xfs_compute_atomic_write_unit_max() John Garry
2025-04-15 16:25   ` Darrick J. Wong
2025-04-15 16:35     ` John Garry
2025-04-15 16:39       ` Darrick J. Wong
2025-04-15 12:14 ` [PATCH v7 13/14] xfs: update atomic write limits John Garry
2025-04-15 16:26   ` Darrick J. Wong
2025-04-15 12:14 ` [PATCH v7 14/14] xfs: allow sysadmins to specify a maximum atomic write limit at mount time John Garry
2025-04-15 15:35   ` Randy Dunlap
2025-04-15 16:55   ` Darrick J. Wong
2025-04-15 22:36   ` [PATCH v7.1 " Darrick J. Wong
2025-04-16 10:08     ` John Garry
2025-04-16 16:26       ` Darrick J. Wong

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=20250421164241.GD25700@frogsfrogsfrogs \
    --to=djwong@kernel.org \
    --cc=brauner@kernel.org \
    --cc=catherine.hoang@oracle.com \
    --cc=cem@kernel.org \
    --cc=dchinner@redhat.com \
    --cc=hch@lst.de \
    --cc=jack@suse.cz \
    --cc=john.g.garry@oracle.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-ext4@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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.