mbox series

[v3,0/5] btrfs: encoded reads via io_uring

Message ID 20241014171838.304953-1-maharmstone@fb.com (mailing list archive)
Headers show
Series btrfs: encoded reads via io_uring | expand

Message

Mark Harmstone Oct. 14, 2024, 5:18 p.m. UTC
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.

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(-)

Comments

Boris Burkov Oct. 14, 2024, 5:44 p.m. UTC | #1
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
>
Mark Harmstone Oct. 15, 2024, 8:50 a.m. UTC | #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