On Tue, Aug 25, 2020 at 11:25:05AM +0300, Amir Goldstein wrote:
> On Tue, Aug 25, 2020 at 2:49 AM Omar Sandoval <osandov@xxxxxxxxxxx> wrote:
> >
> > On Fri, Aug 21, 2020 at 11:47:54AM +0300, Amir Goldstein wrote:
> > > On Fri, Aug 21, 2020 at 10:38 AM Omar Sandoval <osandov@xxxxxxxxxxx> wrote:
> > > >
> > > > From: Omar Sandoval <osandov@xxxxxx>
> > > >
> > > > Btrfs supports transparent compression: data written by the user can be
> > > > compressed when written to disk and decompressed when read back.
> > > > However, we'd like to add an interface to write pre-compressed data
> > > > directly to the filesystem, and the matching interface to read
> > > > compressed data without decompressing it. This adds support for
> > > > so-called "encoded I/O" via preadv2() and pwritev2().
> > > >
> > > > A new RWF_ENCODED flags indicates that a read or write is "encoded". If
> > > > this flag is set, iov[0].iov_base points to a struct encoded_iov which
> > > > is used for metadata: namely, the compression algorithm, unencoded
> > > > (i.e., decompressed) length, and what subrange of the unencoded data
> > > > should be used (needed for truncated or hole-punched extents and when
> > > > reading in the middle of an extent). For reads, the filesystem returns
> > > > this information; for writes, the caller provides it to the filesystem.
> > > > iov[0].iov_len must be set to sizeof(struct encoded_iov), which can be
> > > > used to extend the interface in the future a la copy_struct_from_user().
> > > > The remaining iovecs contain the encoded extent.
> > > >
> > > > This adds the VFS helpers for supporting encoded I/O and documentation
> > > > for filesystem support.
> > > >
> > > > Signed-off-by: Omar Sandoval <osandov@xxxxxx>
> > > > ---
> > > > Documentation/filesystems/encoded_io.rst | 74 ++++++++++
> > > > Documentation/filesystems/index.rst | 1 +
> > > > include/linux/fs.h | 16 +++
> > > > include/uapi/linux/fs.h | 33 ++++-
> > > > mm/filemap.c | 166 +++++++++++++++++++++--
> > > > 5 files changed, 276 insertions(+), 14 deletions(-)
> > > > create mode 100644 Documentation/filesystems/encoded_io.rst
> > > >
> > > > diff --git a/Documentation/filesystems/encoded_io.rst b/Documentation/filesystems/encoded_io.rst
> > > > new file mode 100644
> > > > index 000000000000..50405276d866
> > > > --- /dev/null
> > > > +++ b/Documentation/filesystems/encoded_io.rst
> > > > @@ -0,0 +1,74 @@
> > > > +===========
> > > > +Encoded I/O
> > > > +===========
> > > > +
> > > > +Encoded I/O is a mechanism for reading and writing encoded (e.g., compressed
> > > > +and/or encrypted) data directly from/to the filesystem. The userspace interface
> > > > +is thoroughly described in the :manpage:`encoded_io(7)` man page; this document
> > > > +describes the requirements for filesystem support.
> > > > +
> > > > +First of all, a filesystem supporting encoded I/O must indicate this by setting
> > > > +the ``FMODE_ENCODED_IO`` flag in its ``file_open`` file operation::
> > > > +
> > > > + static int foo_file_open(struct inode *inode, struct file *filp)
> > > > + {
> > > > + ...
> > > > + filep->f_mode |= FMODE_ENCODED_IO;
> > > > + ...
> > > > + }
> > > > +
> > > > +Encoded I/O goes through ``read_iter`` and ``write_iter``, designated by the
> > > > +``IOCB_ENCODED`` flag in ``kiocb->ki_flags``.
> > > > +
> > > > +Reads
> > > > +=====
> > > > +
> > > > +Encoded ``read_iter`` should:
> > > > +
> > > > +1. Call ``generic_encoded_read_checks()`` to validate the file and buffers
> > > > + provided by userspace.
> > > > +2. Initialize the ``encoded_iov`` appropriately.
> > > > +3. Copy it to the user with ``copy_encoded_iov_to_iter()``.
> > > > +4. Copy the encoded data to the user.
> > > > +5. Advance ``kiocb->ki_pos`` by ``encoded_iov->len``.
> > > > +6. Return the size of the encoded data read, not including the ``encoded_iov``.
> > > > +
> > > > +There are a few details to be aware of:
> > > > +
> > > > +* Encoded ``read_iter`` should support reading unencoded data if the extent is
> > > > + not encoded.
> > > > +* If the buffers provided by the user are not large enough to contain an entire
> > > > + encoded extent, then ``read_iter`` should return ``-ENOBUFS``. This is to
> > > > + avoid confusing userspace with truncated data that cannot be properly
> > > > + decoded.
> > > > +* Reads in the middle of an encoded extent can be returned by setting
> > > > + ``encoded_iov->unencoded_offset`` to non-zero.
> > > > +* Truncated unencoded data (e.g., because the file does not end on a block
> > > > + boundary) may be returned by setting ``encoded_iov->len`` to a value smaller
> > > > + value than ``encoded_iov->unencoded_len - encoded_iov->unencoded_offset``.
> > > > +
> > > > +Writes
> > > > +======
> > > > +
> > > > +Encoded ``write_iter`` should (in addition to the usual accounting/checks done
> > > > +by ``write_iter``):
> > > > +
> > > > +1. Call ``copy_encoded_iov_from_iter()`` to get and validate the
> > > > + ``encoded_iov``.
> > > > +2. Call ``generic_encoded_write_checks()`` instead of
> > > > + ``generic_write_checks()``.
> > > > +3. Check that the provided encoding in ``encoded_iov`` is supported.
> > > > +4. Advance ``kiocb->ki_pos`` by ``encoded_iov->len``.
> > > > +5. Return the size of the encoded data written.
> > > > +
> > > > +Again, there are a few details:
> > > > +
> > > > +* Encoded ``write_iter`` doesn't need to support writing unencoded data.
> > > > +* ``write_iter`` should either write all of the encoded data or none of it; it
> > > > + must not do partial writes.
> > > > +* ``write_iter`` doesn't need to validate the encoded data; a subsequent read
> > > > + may return, e.g., ``-EIO`` if the data is not valid.
> > > > +* The user may lie about the unencoded size of the data; a subsequent read
> > > > + should truncate or zero-extend the unencoded data rather than returning an
> > > > + error.
> > > > +* Be careful of page cache coherency.
> > >
> > > Haha that rings in my head like the "Smoking kills!" warnings...
> > >
> > > I find it a bit odd that you mix page cache at all when reading
> > > unencoded extents.
> > > Feels like a file with FMODE_ENCODED_IO should stick to direct IO in all cases.
> > > I don't know how btrfs deals with mixing direct IO and page cache IO normally,
> > > but surely the rules could be made even stricter for an inode accessed with this
> > > new API?
> > >
> > > Is there something I am misunderstanding?
> > >
> > > Thanks,
> > > Amir.
> >
> > I'm not completely following here, are you suggesting that if a file is
> > open with O_ALLOW_ENCODED, buffered I/O to that file should return an
> > error?
>
> No. I don't.
>
> > Btrfs at least does the necessary range locking and page cache
> > invalidation to ensure that direct I/O gets along with buffered I/O (and
> > now encoded I/O).
>
> That's a good start :-)
>
> I saw btrfs_encoded_read_regular_fill_pages() and concluded that even
> in FMODE_ENCODED_IO, when reading an unencoded extent, you fill
> page cache with the unencoded data.
>
> Is that correct? or did I miss read the code?
> If correct, does it serve any purpose?
> Seems more sensible to me to read/write FMODE_ENCODED_IO only in direct io
> regardless if the extent is encoded or not (for simpler code if nothing else).
>
> Thanks,
> Amir.
Oh, I see. btrfs_encoded_read_regular_fill_pages() fills temporary pages
allocated for the read, not page cache pages. RWF_ENCODED always
bypasses the page cache, which I agree is the most sensible option.
