From: John Garry <[email protected]>
To: [email protected], [email protected], [email protected], [email protected],
[email protected], [email protected],
[email protected], [email protected], [email protected],
[email protected]
Cc: [email protected], [email protected],
[email protected], [email protected],
[email protected], [email protected], [email protected],
[email protected], [email protected],
[email protected], [email protected],
[email protected], [email protected],
[email protected], [email protected], [email protected],
[email protected], [email protected],
[email protected], [email protected],
John Garry <[email protected]>
Subject: [Patch v9 00/10] block atomic writes
Date: Thu, 20 Jun 2024 12:53:49 +0000 [thread overview]
Message-ID: <[email protected]> (raw)
This series introduces a proposal to implementing atomic writes in the
kernel for torn-write protection.
This series takes the approach of adding a new "atomic" flag to each of
pwritev2() and iocb->ki_flags - RWF_ATOMIC and IOCB_ATOMIC, respectively.
When set, these indicate that we want the write issued "atomically".
Only direct IO is supported and for block devices here. For this, atomic
write HW is required, like SCSI ATOMIC WRITE (16).
XFS FS support has previously been posted at:
https://lore.kernel.org/linux-xfs/[email protected]/T/#t
Updated man pages have been posted at:
https://lore.kernel.org/lkml/[email protected]/T/#m520dca97a9748de352b5a723d3155a4bb1e46456
The goal here is to provide an interface that allows applications use
application-specific block sizes larger than logical block size
reported by the storage device or larger than filesystem block size as
reported by stat().
With this new interface, application blocks will never be torn or
fractured when written. For a power fail, for each individual application
block, all or none of the data to be written. A racing atomic write and
read will mean that the read sees all the old data or all the new data,
but never a mix of old and new.
Three new fields are added to struct statx - atomic_write_unit_min,
atomic_write_unit_max, and atomic_write_segments_max. For each atomic
individual write, the total length of a write must be a between
atomic_write_unit_min and atomic_write_unit_max, inclusive, and a
power-of-2. The write must also be at a natural offset in the file
wrt the write length. For pwritev2, iovcnt is limited by
atomic_write_segments_max.
There has been some discussion on untorn buffered writes support at:
https://lore.kernel.org/linux-fsdevel/[email protected]/T/#t
That conversation continues.
SCSI sd.c and scsi_debug and NVMe kernel support is added.
This series is based on Jens' for-6.11/block-limits branch at commit
339d3948c07b ("block: move the bounce flag into the features field").
Patches can be found at:
https://github.com/johnpgarry/linux/commits/atomic-writes-v6.10-v9
Changes since v8:
- Rebase
- Update comment on nvme_valid_atomic_write()
- Update chunk sectors vs atomic boundary support
- Add Martin and Darrick's review tags (thanks!)
Changes since v7:
- Generalize block chunk_sectors support (Hannes)
- Relocate and reorder args for generic_atomic_write_valid (Christoph)
- Drop rq_straddles_atomic_write_boundary()
Alan Adamson (1):
nvme: Atomic write support
John Garry (6):
block: Pass blk_queue_get_max_sectors() a request pointer
block: Generalize chunk_sectors support as boundary support
block: Add core atomic write support
block: Add fops atomic write support
scsi: sd: Atomic write support
scsi: scsi_debug: Atomic write support
Prasad Singamsetty (3):
fs: Initial atomic write support
fs: Add initial atomic write support info to statx
block: Add atomic write support for statx
Documentation/ABI/stable/sysfs-block | 53 +++
block/bdev.c | 36 +-
block/blk-core.c | 19 +
block/blk-merge.c | 67 ++-
block/blk-mq.c | 2 +-
block/blk-settings.c | 88 ++++
block/blk-sysfs.c | 33 ++
block/blk.h | 9 +-
block/fops.c | 20 +-
drivers/md/dm.c | 2 +-
drivers/nvme/host/core.c | 52 +++
drivers/scsi/scsi_debug.c | 588 +++++++++++++++++++++------
drivers/scsi/scsi_trace.c | 22 +
drivers/scsi/sd.c | 93 ++++-
drivers/scsi/sd.h | 8 +
fs/aio.c | 8 +-
fs/btrfs/ioctl.c | 2 +-
fs/read_write.c | 18 +-
fs/stat.c | 50 ++-
include/linux/blk_types.h | 8 +-
include/linux/blkdev.h | 74 +++-
include/linux/fs.h | 20 +-
include/linux/stat.h | 3 +
include/scsi/scsi_proto.h | 1 +
include/trace/events/scsi.h | 1 +
include/uapi/linux/fs.h | 5 +-
include/uapi/linux/stat.h | 12 +-
io_uring/rw.c | 9 +-
28 files changed, 1111 insertions(+), 192 deletions(-)
--
2.31.1
next reply other threads:[~2024-06-20 12:55 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-20 12:53 John Garry [this message]
2024-06-20 12:53 ` [Patch v9 01/10] block: Pass blk_queue_get_max_sectors() a request pointer John Garry
2024-06-20 14:12 ` Hannes Reinecke
2024-06-20 12:53 ` [Patch v9 02/10] block: Generalize chunk_sectors support as boundary support John Garry
2024-06-20 14:14 ` Hannes Reinecke
2024-06-20 12:53 ` [Patch v9 03/10] fs: Initial atomic write support John Garry
2024-06-21 5:56 ` Hannes Reinecke
2024-06-20 12:53 ` [Patch v9 04/10] fs: Add initial atomic write support info to statx John Garry
2024-06-21 5:57 ` Hannes Reinecke
2024-06-20 12:53 ` [Patch v9 05/10] block: Add core atomic write support John Garry
2024-06-20 19:34 ` Keith Busch
2024-06-21 6:09 ` Hannes Reinecke
2024-06-21 7:41 ` John Garry
2024-06-20 12:53 ` [Patch v9 06/10] block: Add atomic write support for statx John Garry
2024-06-20 19:46 ` Keith Busch
2024-06-21 6:10 ` Hannes Reinecke
2024-06-20 12:53 ` [Patch v9 07/10] block: Add fops atomic write support John Garry
2024-06-20 19:46 ` Keith Busch
2024-06-21 6:13 ` Hannes Reinecke
2024-06-21 12:02 ` John Garry
2024-06-21 21:23 ` Darrick J. Wong
2024-06-21 9:41 ` Kanchan Joshi
2024-06-20 12:53 ` [Patch v9 08/10] scsi: sd: Atomic " John Garry
2024-06-21 6:15 ` Hannes Reinecke
2024-06-20 12:53 ` [Patch v9 09/10] scsi: scsi_debug: " John Garry
2024-06-21 6:15 ` Hannes Reinecke
2024-06-20 12:53 ` [Patch v9 10/10] nvme: " John Garry
2024-06-20 20:36 ` Keith Busch
2024-06-21 6:17 ` Hannes Reinecke
2024-06-21 9:40 ` Kanchan Joshi
2024-06-20 21:23 ` [Patch v9 00/10] block atomic writes Jens Axboe
2024-06-21 7:59 ` John Garry
2024-06-21 14:28 ` Jens Axboe
2024-06-21 14:41 ` 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 \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
/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