This series expands atomic write support to filesystems, specifically
XFS.

Initially we will only support writing exactly 1x FS block atomically.

Since we can now have FS block size > PAGE_SIZE for XFS, we can write
atomically 4K+ blocks on x86.

No special per-inode flag is required for enabling writing 1x F block.
In future, to support writing more than one FS block atomically, a new FS
XFLAG flag may then introduced - like FS_XFLAG_BIG_ATOMICWRITES. This
would depend on a feature like forcealign.

So if we format the FS for 16K FS block size:
mkfs.xfs -b size=16384 /dev/sda

The statx reports atomic write unit min/max = FS block size:
$xfs_io -c statx filename
...
stat.stx_atomic_write_unit_min = 16384
stat.stx_atomic_write_unit_max = 16384
stat.stx_atomic_write_segments_max = 1
...

Baseline is 77bfe1b11ea0 (tag: xfs-6.12-fixes-3, xfs/xfs-6.12-fixesC,
xfs/for-next) xfs: fix a typo

Patches for this series can be found at:
https://github.com/johnpgarry/linux/tree/atomic-writes-v6.12-fs-v9

Changes since v8:
- Add bdev atomic write unit helpers (Christoph)
- Add comment on FS block size limit (Christoph)
- Stylistic improvements (Christoph)
- Add RB tags from Christoph (thanks!)

Changes since v7:
- Drop FS_XFLAG_ATOMICWRITES
- Reorder block/fs patches and add fixes tags (Christoph)
- Add RB tag from Christoph (Thanks!)
- Rebase

Changes since v6:
- Add iomap documentation update (Darrick)
- Drop reflink restriction (Darrick, Christoph)
- Catch XFS buffered IO fallback (Darrick)
- Check IOCB_DIRECT in generic_atomic_write_valid()
- Tweaks to coding style (Darrick)
- Add RB tags from Darrick and Christoph (thanks!)

John Garry (8):
  block/fs: Pass an iocb to generic_atomic_write_valid()
  fs/block: Check for IOCB_DIRECT in generic_atomic_write_valid()
  block: Add bdev atomic write limits helpers
  fs: Export generic_atomic_write_valid()
  fs: iomap: Atomic write support
  xfs: Support atomic write for statx
  xfs: Validate atomic writes
  xfs: Support setting FMODE_CAN_ATOMIC_WRITE

 .../filesystems/iomap/operations.rst          | 11 ++++++
 block/fops.c                                  | 22 ++++++-----
 fs/iomap/direct-io.c                          | 38 +++++++++++++++++--
 fs/iomap/trace.h                              |  3 +-
 fs/read_write.c                               | 16 +++++---
 fs/xfs/xfs_buf.c                              |  7 ++++
 fs/xfs/xfs_buf.h                              |  4 ++
 fs/xfs/xfs_file.c                             | 16 ++++++++
 fs/xfs/xfs_inode.h                            | 15 ++++++++
 fs/xfs/xfs_iops.c                             | 22 +++++++++++
 include/linux/blkdev.h                        | 16 ++++++++
 include/linux/fs.h                            |  2 +-
 include/linux/iomap.h                         |  1 +
 13 files changed, 151 insertions(+), 22 deletions(-)

-- 
2.31.1

On 16/10/2024 11:03, John Garry wrote:

Hi Jens,

There are block changes in this series. I was going to ask Carlos to 
queue this work via the XFS tree, so can you let me know whether you 
have any issue with those (block) changes. There is a fix included, 
which I can manually backport to stable (if not autoselected).

Note that I still plan on sending a v10 for this series, to fix a small 
documentation issue which Darrick noticed.

BTW, I was hoping to send non-RFCs patches for atomic write RAID support 
soon, originally sent in:
https://lore.kernel.org/linux-block/20240919092302.3094725-1-john.g.garry@oracle.com/
https://lore.kernel.org/linux-block/20240903150748.2179966-1-john.g.garry@oracle.com/

They should not have any dependency or conflict with this series.

Thanks,
John

> This series expands atomic write support to filesystems, specifically
> XFS.
> 
> Initially we will only support writing exactly 1x FS block atomically.
> 
> Since we can now have FS block size > PAGE_SIZE for XFS, we can write
> atomically 4K+ blocks on x86.
> 

...

> John Garry (8):
>    block/fs: Pass an iocb to generic_atomic_write_valid()
>    fs/block: Check for IOCB_DIRECT in generic_atomic_write_valid()
>    block: Add bdev atomic write limits helpers
>    fs: Export generic_atomic_write_valid()
>    fs: iomap: Atomic write support
>    xfs: Support atomic write for statx
>    xfs: Validate atomic writes
>    xfs: Support setting FMODE_CAN_ATOMIC_WRITE
> 
>   .../filesystems/iomap/operations.rst          | 11 ++++++
>   block/fops.c                                  | 22 ++++++-----
>   fs/iomap/direct-io.c                          | 38 +++++++++++++++++--
>   fs/iomap/trace.h                              |  3 +-
>   fs/read_write.c                               | 16 +++++---
>   fs/xfs/xfs_buf.c                              |  7 ++++
>   fs/xfs/xfs_buf.h                              |  4 ++
>   fs/xfs/xfs_file.c                             | 16 ++++++++
>   fs/xfs/xfs_inode.h                            | 15 ++++++++
>   fs/xfs/xfs_iops.c                             | 22 +++++++++++
>   include/linux/blkdev.h                        | 16 ++++++++
>   include/linux/fs.h                            |  2 +-
>   include/linux/iomap.h                         |  1 +
>   13 files changed, 151 insertions(+), 22 deletions(-)
>

On 10/18/24 3:29 AM, John Garry wrote:
> On 16/10/2024 11:03, John Garry wrote:
> 
> Hi Jens,
> 
> There are block changes in this series. I was going to ask Carlos to
> queue this work via the XFS tree, so can you let me know whether you
> have any issue with those (block) changes. There is a fix included,
> which I can manually backport to stable (if not autoselected).
> 
> Note that I still plan on sending a v10 for this series, to fix a
> small documentation issue which Darrick noticed.

To avoid conflicts, let's do a separate branch that we can both pull in.
I'll take a closer look and set that up once you post v10.

-- 
Jens Axboe

On 18/10/2024 14:41, Jens Axboe wrote:
>> There are block changes in this series. I was going to ask Carlos to
>> queue this work via the XFS tree, so can you let me know whether you
>> have any issue with those (block) changes. There is a fix included,
>> which I can manually backport to stable (if not autoselected).
>>
>> Note that I still plan on sending a v10 for this series, to fix a
>> small documentation issue which Darrick noticed.
> To avoid conflicts, let's do a separate branch that we can both pull in.
> I'll take a closer look and set that up once you post v10.


ok, I'll send v10 soon.

Thanks,
John