Linux-Fsdevel Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Amir Goldstein <amir73il@gmail.com>
To: Omar Sandoval <osandov@osandov.com>
Cc: linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Linux Btrfs <linux-btrfs@vger.kernel.org>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Christoph Hellwig <hch@infradead.org>,
	Dave Chinner <david@fromorbit.com>, Jann Horn <jannh@google.com>,
	Aleksa Sarai <cyphar@cyphar.com>,
	Linux API <linux-api@vger.kernel.org>,
	kernel-team@fb.com
Subject: Re: [PATCH v5 3/9] fs: add RWF_ENCODED for reading/writing compressed data
Date: Tue, 25 Aug 2020 11:25:05 +0300	[thread overview]
Message-ID: <CAOQ4uxgXUvDSV_4V8R6ivbbSOdh8J4GhvrHqys77E_PgHtAoWg@mail.gmail.com> (raw)
In-Reply-To: <20200824234903.GA202819@exodia.localdomain>

On Tue, Aug 25, 2020 at 2:49 AM Omar Sandoval <osandov@osandov.com> 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@osandov.com> wrote:
> > >
> > > From: Omar Sandoval <osandov@fb.com>
> > >
> > > 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@fb.com>
> > > ---
> > >  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.

  reply	other threads:[~2020-08-25  8:25 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-21  7:38 [PATCH v5 0/9] fs: interface for directly " Omar Sandoval
2020-08-21  7:38 ` [PATCH man-pages v5] Document encoded I/O Omar Sandoval
2020-08-21  9:24   ` Amir Goldstein
2020-08-24 18:15     ` Omar Sandoval
2020-08-21  7:38 ` [PATCH v5 1/9] iov_iter: add copy_struct_from_iter() Omar Sandoval
2020-08-24 18:52   ` Josef Bacik
2020-08-24 21:09     ` Omar Sandoval
2020-08-21  7:38 ` [PATCH v5 2/9] fs: add O_ALLOW_ENCODED open flag Omar Sandoval
2020-08-24 18:28   ` Josef Bacik
2020-08-24 21:11     ` Omar Sandoval
2020-08-21  7:38 ` [PATCH v5 3/9] fs: add RWF_ENCODED for reading/writing compressed data Omar Sandoval
2020-08-21  8:47   ` Amir Goldstein
2020-08-24 23:49     ` Omar Sandoval
2020-08-25  8:25       ` Amir Goldstein [this message]
2020-08-25 17:20         ` Omar Sandoval
2020-08-24 19:07   ` Josef Bacik
2020-08-21  7:38 ` [PATCH v5 4/9] btrfs: don't advance offset for compressed bios in btrfs_csum_one_bio() Omar Sandoval
2020-08-24 19:17   ` Josef Bacik
2020-08-21  7:38 ` [PATCH v5 5/9] btrfs: add ram_bytes and offset to btrfs_ordered_extent Omar Sandoval
2020-08-24 19:23   ` Josef Bacik
2020-08-21  7:38 ` [PATCH v5 6/9] btrfs: support different disk extent size for delalloc Omar Sandoval
2020-08-24 19:26   ` Josef Bacik
2020-08-21  7:38 ` [PATCH v5 7/9] btrfs: optionally extend i_size in cow_file_range_inline() Omar Sandoval
2020-08-24 19:33   ` Josef Bacik
2020-08-21  7:38 ` [PATCH v5 8/9] btrfs: implement RWF_ENCODED reads Omar Sandoval
2020-08-24 19:54   ` Josef Bacik
2020-08-24 21:23     ` Omar Sandoval
2020-08-21  7:38 ` [PATCH v5 9/9] btrfs: implement RWF_ENCODED writes Omar Sandoval
2020-08-24 20:30   ` Josef Bacik
2020-08-24 21:30     ` Omar Sandoval

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 \
    --in-reply-to=CAOQ4uxgXUvDSV_4V8R6ivbbSOdh8J4GhvrHqys77E_PgHtAoWg@mail.gmail.com \
    --to=amir73il@gmail.com \
    --cc=cyphar@cyphar.com \
    --cc=david@fromorbit.com \
    --cc=hch@infradead.org \
    --cc=jannh@google.com \
    --cc=kernel-team@fb.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=osandov@osandov.com \
    --cc=viro@zeniv.linux.org.uk \
    --subject='Re: [PATCH v5 3/9] fs: add RWF_ENCODED for reading/writing compressed data' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).