Message ID | 20241014171838.304953-1-maharmstone@fb.com (mailing list archive) |
---|---|
Headers | show |
Series | btrfs: encoded reads via io_uring | expand |
On Mon, Oct 14, 2024 at 06:18:22PM +0100, Mark Harmstone wrote: > This is a re-do of my previous patchsets: I wasn't happy with how > synchronous the previous version was in many ways, nor quite how badly > it butchered the existing ioctl. > > This adds an io_uring cmd to btrfs to match the behaviour of the > existing BTRFS_IOC_ENCODED_READ ioctl, which allows the reading of > potentially compressed extents directly from the disk. > > Pavel mentioned on the previous patches whether we definitely need to > keep the inode and the extent locked while doing I/O; I think the answer > is probably yes, a) to prevent races with no-COW extents, and b) to > prevent the extent from being deallocated from under us. But I think > it's possible to resolve this, as a future optimization. What branch is this based off of? I attempted to apply it to the current btrfs for-next and "btrfs: change btrfs_encoded_read_regular_fill_pages to take a callback" did not apply cleanly. > > Mark Harmstone (5): > btrfs: remove pointless addition in btrfs_encoded_read > btrfs: change btrfs_encoded_read_regular_fill_pages to take a callback > btrfs: change btrfs_encoded_read so that reading of extent is done by > caller > btrfs: add nowait parameter to btrfs_encoded_read > btrfs: add io_uring command for encoded reads > > fs/btrfs/btrfs_inode.h | 23 ++- > fs/btrfs/file.c | 1 + > fs/btrfs/inode.c | 186 ++++++++++++++++-------- > fs/btrfs/ioctl.c | 316 ++++++++++++++++++++++++++++++++++++++++- > fs/btrfs/ioctl.h | 1 + > fs/btrfs/send.c | 15 +- > 6 files changed, 476 insertions(+), 66 deletions(-) > > -- > 2.44.2 >
On 14/10/24 18:44, Boris Burkov wrote: > > > On Mon, Oct 14, 2024 at 06:18:22PM +0100, Mark Harmstone wrote: >> This is a re-do of my previous patchsets: I wasn't happy with how >> synchronous the previous version was in many ways, nor quite how badly >> it butchered the existing ioctl. >> >> This adds an io_uring cmd to btrfs to match the behaviour of the >> existing BTRFS_IOC_ENCODED_READ ioctl, which allows the reading of >> potentially compressed extents directly from the disk. >> >> Pavel mentioned on the previous patches whether we definitely need to >> keep the inode and the extent locked while doing I/O; I think the answer >> is probably yes, a) to prevent races with no-COW extents, and b) to >> prevent the extent from being deallocated from under us. But I think >> it's possible to resolve this, as a future optimization. > > What branch is this based off of? I attempted to apply it to the current > btrfs for-next and > "btrfs: change btrfs_encoded_read_regular_fill_pages to take a callback" > did not apply cleanly. This is against v6.11, because it's the latest stable version. I'm guessing it ought to have been against upstream/master... Mark