All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: Dave Chinner <david@fromorbit.com>,
	John Garry <john.g.garry@oracle.com>,
	brauner@kernel.org, cem@kernel.org, dchinner@redhat.com,
	hch@lst.de, ritesh.list@gmail.com, linux-xfs@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	martin.petersen@oracle.com
Subject: Re: [PATCH 1/4] iomap: Lift blocksize restriction on atomic writes
Date: Thu, 16 Jan 2025 07:52:25 +0100	[thread overview]
Message-ID: <20250116065225.GA25695@lst.de> (raw)
In-Reply-To: <20250114235726.GA3566461@frogsfrogsfrogs>

On Tue, Jan 14, 2025 at 03:57:26PM -0800, Darrick J. Wong wrote:
> Ok, let's do that then.  Just to be clear -- for any RWF_ATOMIC direct
> write that's correctly aligned and targets a single mapping in the
> correct state, we can build the untorn bio and submit it.  For
> everything else, prealloc some post EOF blocks, write them there, and
> exchange-range them.
> 
> Tricky questions: How do we avoid collisions between overlapping writes?
> I guess we find a free file range at the top of the file that is long
> enough to stage the write, and put it there?  And purge it later?
> 
> Also, does this imply that the maximum file size is less than the usual
> 8EB?

I think literally using the exchrange code for anything but an
initial prototype is a bad idea for the above reasons.  If we go
beyond proving this is possible you'd want a version of exchrange
where the exchange partners is not a file mapping, but a cow staging
record.


  parent reply	other threads:[~2025-01-16  6:52 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-04 15:43 [PATCH 0/4] large atomic writes for xfs John Garry
2024-12-04 15:43 ` [PATCH 1/4] iomap: Lift blocksize restriction on atomic writes John Garry
2024-12-04 20:35   ` Dave Chinner
2024-12-05  6:30     ` Darrick J. Wong
2024-12-05 11:51       ` John Garry
2024-12-05 10:52     ` John Garry
2024-12-05 21:15       ` Dave Chinner
2024-12-06  9:43         ` John Garry
2024-12-12  1:34         ` Darrick J. Wong
2025-01-14  4:41           ` Dave Chinner
2025-01-14 23:57             ` Darrick J. Wong
2025-01-15  9:30               ` John Garry
2025-01-16  6:52               ` Christoph Hellwig [this message]
2025-01-17 18:49                 ` Darrick J. Wong
2025-01-22  6:42                   ` Christoph Hellwig
2025-01-22 10:45                     ` John Garry
2025-01-22 23:51                       ` Dave Chinner
2025-01-23  9:28                         ` John Garry
2025-01-17 10:26               ` John Garry
2025-01-17 18:29                 ` Darrick J. Wong
2025-01-20  8:29                   ` John Garry
2025-01-22 21:05               ` Dave Chinner
2025-01-13 21:35         ` John Garry
2025-01-14  4:43           ` Dave Chinner
2024-12-04 15:43 ` [PATCH 2/4] xfs: Switch atomic write size check in xfs_file_write_iter() John Garry
2024-12-04 15:43 ` [PATCH 3/4] xfs: Add RT atomic write unit max to xfs_mount John Garry
2024-12-04 15:43 ` [PATCH 4/4] xfs: Update xfs_get_atomic_write_attr() for large atomic writes 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=20250116065225.GA25695@lst.de \
    --to=hch@lst.de \
    --cc=brauner@kernel.org \
    --cc=cem@kernel.org \
    --cc=david@fromorbit.com \
    --cc=dchinner@redhat.com \
    --cc=djwong@kernel.org \
    --cc=john.g.garry@oracle.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=ritesh.list@gmail.com \
    /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.