fs: interface for directly reading/writing compressed data
Subsystems (11)
v9 cover fs: interface for directly reading/writing compressed data
From: Omar Sandoval <[email protected]>
This series adds an API for reading compressed data on a filesystem without decompressing it as well as support for writing compressed data directly to the filesystem. I have test cases (including fsstress support) and example programs which I'll send up once the dust settles [1].
The main use-case is Btrfs send/receive: currently, when sending data from one compressed filesystem to another, the sending side decompresses the data and the receiving side recompresses it before writing it out. This is wasteful and can be avoided if we can just send and write compressed extents. The patches implementing the send/receive support were sent with the last submission of this series [2].
Patches 1-3 add the VFS support, UAPI, and documentation. Patches 4-7 are Btrfs prep patches. Patch 8 adds Btrfs encoded read support and patch 9 adds Btrfs encoded write support.
These patches are based on Dave Sterba's Btrfs misc-next branch [3], which is in turn currently based on v5.13-rc2.
This is a _resend of a resend_ of v9 [4], rebased on the latest kdave/misc-next branch.
1: https://github.com/osandov/xfstests/tree/rwf-encoded
2: https://lore.kernel.org/linux-btrfs/[email protected]/
3: https://github.com/kdave/btrfs-devel/tree/misc-next
4: https://lore.kernel.org/linux-fsdevel/[email protected]/
Omar Sandoval (9):
iov_iter: add copy_struct_from_iter()
fs: add O_ALLOW_ENCODED open flag
fs: add RWF_ENCODED for reading/writing compressed data
btrfs: don't advance offset for compressed bios in
btrfs_csum_one_bio()
btrfs: add ram_bytes and offset to btrfs_ordered_extent
btrfs: support different disk extent size for delalloc
btrfs: optionally extend i_size in cow_file_range_inline()
btrfs: implement RWF_ENCODED reads
btrfs: implement RWF_ENCODED writes
Documentation/filesystems/encoded_io.rst | 240 ++++++ Documentation/filesystems/index.rst | 1 + arch/alpha/include/uapi/asm/fcntl.h | 1 + arch/parisc/include/uapi/asm/fcntl.h | 1 + arch/sparc/include/uapi/asm/fcntl.h | 1 + fs/btrfs/compression.c | 12 +- fs/btrfs/compression.h | 6 +- fs/btrfs/ctree.h | 9 +- fs/btrfs/delalloc-space.c | 18 +- fs/btrfs/file-item.c | 35 +- fs/btrfs/file.c | 46 +- fs/btrfs/inode.c | 929 +++++++++++++++++++++-- fs/btrfs/ordered-data.c | 124 +-- fs/btrfs/ordered-data.h | 25 +- fs/btrfs/relocation.c | 4 +- fs/fcntl.c | 10 +- fs/namei.c | 4 + fs/read_write.c | 168 +++- include/linux/encoded_io.h | 17 + include/linux/fcntl.h | 2 +- include/linux/fs.h | 13 + include/linux/uio.h | 1 + include/uapi/asm-generic/fcntl.h | 4 + include/uapi/linux/encoded_io.h | 30 + include/uapi/linux/fs.h | 5 +- lib/iov_iter.c | 91 +++ 26 files changed, 1563 insertions(+), 234 deletions(-) create mode 100644 Documentation/filesystems/encoded_io.rst create mode 100644 include/linux/encoded_io.h create mode 100644 include/uapi/linux/encoded_io.h
Signature · 1 line
2.31.1
PATCH v9 1/9 iov_iter: add copy_struct_from_iter()
From: Omar Sandoval <[email protected]>
This is essentially copy_struct_from_user() but for an iov_iter.
--- include/linux/uio.h | 1 + lib/iov_iter.c | 91 +++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 92 insertions(+)
include/linux/uio.h +1 -0
@@ -129,6 +129,7 @@ size_t copy_page_to_iter(struct page *page, size_t offset, size_t bytes, struct iov_iter *i);size_t copy_page_from_iter (struct page *page,size_t offset,size_t bytes,struct iov_iter *i); +int copy_struct_from_iter (void *dst,size_t ksize,struct iov_iter *i);size_t _copy_to_iter (const void *addr,size_t bytes,struct iov_iter *i);size_t _copy_from_iter (void *addr,size_t bytes,struct iov_iter *i);
lib/iov_iter.c +91 -0
97 lines not on this page · raw message
Signature · 1 line
2.31.1
PATCH v9 2/9 fs: add O_ALLOW_ENCODED open flag
In reply to Omar SandovalFrom: Omar Sandoval <[email protected]>
The upcoming RWF_ENCODED operation introduces some security concerns:
1. Compressed writes will pass arbitrary data to decompression algorithms in the kernel.
2. Compressed reads can leak truncated/hole punched data.
Therefore, we need to require privilege for RWF_ENCODED. It's not possible to do the permissions checks at the time of the read or write because, e.g., io_uring submits IO from a worker thread. So, add an open flag which requires CAP_SYS_ADMIN. It can also be set and cleared with fcntl(). The flag is not cleared in any way on fork or exec.
Note that the usual issue that unknown open flags are ignored doesn't really matter for O_ALLOW_ENCODED; if the kernel doesn't support O_ALLOW_ENCODED, then it doesn't support RWF_ENCODED, either.
--- arch/alpha/include/uapi/asm/fcntl.h | 1 + arch/parisc/include/uapi/asm/fcntl.h | 1 + arch/sparc/include/uapi/asm/fcntl.h | 1 + fs/fcntl.c | 10 ++++++++-- fs/namei.c | 4 ++++ include/linux/fcntl.h | 2 +- include/uapi/asm-generic/fcntl.h | 4 ++++ 7 files changed, 20 insertions(+), 3 deletions(-)
arch/alpha/include/uapi/asm/fcntl.h +1 -0
@@ -34,6 +34,7 @@#define O_PATH 040000000#define __O_TMPFILE 0100000000 +#define O_ALLOW_ENCODED 0200000000#define F_GETLK 7#define F_SETLK 8
arch/parisc/include/uapi/asm/fcntl.h +1 -0
@@ -19,6 +19,7 @@#define O_PATH 020000000#define __O_TMPFILE 040000000 +#define O_ALLOW_ENCODED 0100000000#define F_GETLK64 8#define F_SETLK64 9
arch/sparc/include/uapi/asm/fcntl.h +1 -0
@@ -37,6 +37,7 @@#define O_PATH 0x1000000#define __O_TMPFILE 0x2000000 +#define O_ALLOW_ENCODED 0x8000000#define F_GETOWN 5/* for sockets. */ #define F_SETOWN 6/* for sockets. */
fs/fcntl.c +8 -2
@@ -31,7 +31,8 @@#include <asm/siginfo.h> #include <linux/uaccess.h> -#define SETFL_MASK (O_APPEND | O_NONBLOCK | O_NDELAY | O_DIRECT | O_NOATIME) +#define SETFL_MASK (O_APPEND | O_NONBLOCK | O_NDELAY | O_DIRECT | O_NOATIME | \ + O_ALLOW_ENCODED)static int setfl (int fd,struct file * filp,unsigned long arg) {
@@ -50,6 +51,11 @@ static int setfl(int fd, struct file * filp, unsigned long arg)if (!inode_owner_or_capable (file_mnt_user_ns (filp), inode))return -EPERM ; +/* O_ALLOW_ENCODED can only be set by superuser */ +if ((arg &O_ALLOW_ENCODED ) && !(filp->f_flags &O_ALLOW_ENCODED ) && + !capable (CAP_SYS_ADMIN )) +return -EPERM ; +/* required for strict SunOS emulation */ if (O_NONBLOCK !=O_NDELAY )if (arg &O_NDELAY )
@@ -1043,7 +1049,7 @@ static int __init fcntl_init(void)* Exceptions: O_NONBLOCK is a two bit define on parisc; O_NDELAY * is defined as O_NONBLOCK on some platforms and not on others. */ -BUILD_BUG_ON (21 -1 /* for O_RDONLY being 0 */ != +BUILD_BUG_ON (22 -1 /* for O_RDONLY being 0 */ !=HWEIGHT32 ( (VALID_OPEN_FLAGS & ~(O_NONBLOCK |O_NDELAY )) | __FMODE_EXEC | __FMODE_NONOTIFY));
fs/namei.c +4 -0
@@ -2997,6 +2997,10 @@ static int may_open(struct user_namespace *mnt_userns, const struct path *path,if (flag &O_NOATIME && !inode_owner_or_capable (mnt_userns, inode))return -EPERM ; +/* O_ALLOW_ENCODED can only be set by superuser */ +if ((flag &O_ALLOW_ENCODED ) && !capable (CAP_SYS_ADMIN )) +return -EPERM ; +return 0 ; }
include/linux/fcntl.h +1 -1
@@ -10,7 +10,7 @@ (O_RDONLY |O_WRONLY |O_RDWR |O_CREAT |O_EXCL |O_NOCTTY |O_TRUNC | \O_APPEND |O_NDELAY |O_NONBLOCK | __O_SYNC |O_DSYNC | \FASYNC |O_DIRECT |O_LARGEFILE |O_DIRECTORY |O_NOFOLLOW | \ -O_NOATIME |O_CLOEXEC |O_PATH | __O_TMPFILE) +O_NOATIME |O_CLOEXEC |O_PATH | __O_TMPFILE |O_ALLOW_ENCODED ) /* List of all valid flags for the how->upgrade_mask argument: */#define VALID_UPGRADE_FLAGS \
include/uapi/asm-generic/fcntl.h +4 -0
@@ -89,6 +89,10 @@#define __O_TMPFILE 020000000#endif +#ifndef O_ALLOW_ENCODED +#define O_ALLOW_ENCODED 040000000 +#endif +/* a horrid kludge trying to make sure that this will fail on old kernels */ #define O_TMPFILE (__O_TMPFILE | O_DIRECTORY)#define O_TMPFILE_MASK (__O_TMPFILE | O_DIRECTORY | O_CREAT)
Signature · 1 line
2.31.1
PATCH v9 3/9 fs: add RWF_ENCODED for reading/writing compressed data
In reply to Omar SandovalFrom: Omar Sandoval <[email protected]>
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.
--- Documentation/filesystems/encoded_io.rst | 240 +++++++++++++++++++++++ Documentation/filesystems/index.rst | 1 + fs/read_write.c | 168 ++++++++++++++-- include/linux/encoded_io.h | 17 ++ include/linux/fs.h | 13 ++ include/uapi/linux/encoded_io.h | 30 +++ include/uapi/linux/fs.h | 5 +- 7 files changed, 460 insertions(+), 14 deletions(-) create mode 100644 Documentation/filesystems/encoded_io.rst create mode 100644 include/linux/encoded_io.h create mode 100644 include/uapi/linux/encoded_io.h
Documentation/filesystems/encoded_io.rst new file +240 -0
@@ -0,0 +1,240 @@ +=========== +Encoded I/O +=========== + +Several filesystems (e.g., Btrfs) support transparent encoding (e.g., +compression, encryption) of data on disk: written data is encoded by the kernel +before it is written to disk, and read data is decoded before being returned to +the user. In some cases, it is useful to skip this encoding step. For example, +the user may want to read the compressed contents of a file or write +pre-compressed data directly to a file. This is referred to as "encoded I/O". + +User API +======== + +Encoded I/O is specified with the ``RWF_ENCODED`` flag to ``preadv2()`` and +``pwritev2()``. If ``RWF_ENCODED`` is specified, then ``iov[0].iov_base`` +points to an ``encoded_iov`` structure, defined in ``<linux/encoded_io.h>`` +as:: + + struct encoded_iov { + __aligned_u64 len; + __aligned_u64 unencoded_len; + __aligned_u64 unencoded_offset; + __u32 compression; + __u32 encryption; + }; + +This may be extended in the future, so ``iov[0].iov_len`` must be set to +``sizeof(struct encoded_iov)`` for forward/backward compatibility. The +remaining buffers contain the encoded data. + +``compression`` and ``encryption`` are the encoding fields. ``compression`` is +``ENCODED_IOV_COMPRESSION_NONE`` (zero) or a filesystem-specific +``ENCODED_IOV_COMPRESSION_*`` constant; see `Filesystem support`_ below. +``encryption`` is currently always ``ENCODED_IOV_ENCRYPTION_NONE`` (zero). + +``unencoded_len`` is the length of the unencoded (i.e., decrypted and +decompressed) data. ``unencoded_offset`` is the offset from the first byte of +the unencoded data to the first byte of logical data in the file (less than or +equal to ``unencoded_len``). ``len`` is the length of the data in the file +(less than or equal to ``unencoded_len - unencoded_offset``). See `Extent +layout`_ below for some examples. + +If the unencoded data is actually longer than ``unencoded_len``, then it is +truncated; if it is shorter, then it is extended with zeroes. + +``pwritev2()`` uses the metadata specified in ``iov[0]``, writes the encoded +data from the remaining buffers, and returns the number of encoded bytes +written (that is, the sum of ``iov[n].iov_len for 1 <= n < iovcnt``; partial +writes will not occur). At least one encoding field must be non-zero. Note that +the encoded data is not validated when it is written; if it is not valid (e.g., +it cannot be decompressed), then a subsequent read may return an error. If the +offset argument to ``pwritev2()`` is -1, then the file offset is incremented by +``len``. If ``iov[0].iov_len`` is less than ``sizeof(struct encoded_iov)`` in +the kernel, then any fields unknown to user space are treated as if they were +zero; if it is greater and any fields unknown to the kernel are non-zero, then +``pwritev2()`` returns -1 and sets errno to ``E2BIG``. + +``preadv2()`` populates the metadata in ``iov[0]``, the encoded data in the +remaining buffers, and returns the number of encoded bytes read. This will only +return one extent per call. This can also read data which is not encoded; all +encoding fields will be zero in that case. If the offset argument to +``preadv2()`` is -1, then the file offset is incremented by ``len``. If +``iov[0].iov_len`` is less than ``sizeof(struct encoded_iov)`` in the kernel +and any fields unknown to user space are non-zero, then ``preadv2()`` returns +-1 and sets errno to ``E2BIG``; if it is greater, then any fields unknown to +the kernel are returned as zero. If the provided buffers are not large enough +to return an entire encoded extent, then ``preadv2()`` returns -1 and sets +errno to ``ENOBUFS``. + +As the filesystem page cache typically contains decoded data, encoded I/O +bypasses the page cache. + +Extent layout +------------- + +By using ``len``, ``unencoded_len``, and ``unencoded_offset``, it is possible +to refer to a subset of an unencoded extent. + +In the simplest case, ``len`` is equal to ``unencoded_len`` and +``unencoded_offset`` is zero. This means that the entire unencoded extent is +used. + +However, suppose we read 50 bytes into a file which contains a single +compressed extent. The filesystem must still return the entire compressed +extent for us to be able to decompress it, so ``unencoded_len`` would be the +length of the entire decompressed extent. However, because the read was at +offset 50, the first 50 bytes should be ignored. Therefore, +``unencoded_offset`` would be 50, and ``len`` would accordingly be +``unencoded_len - 50``. + +Additionally, suppose we want to create an encrypted file with length 500, but +the file is encrypted with a block cipher using a block size of 4096. The +unencoded data would therefore include the appropriate padding, and +``unencoded_len`` would be 4096. However, to represent the logical size of the +file, ``len`` would be 500 (and ``unencoded_offset`` would be 0). + +Similar situations can arise in other cases: + +* If the filesystem pads data to the filesystem block size before compressing, + then compressed files with a size unaligned to the filesystem block size will + end with an extent with ``len < unencoded_len``. + +* Extents cloned from the middle of a larger encoded extent with + ``FICLONERANGE`` may have a non-zero ``unencoded_offset`` and/or + ``len < unencoded_len``. + +* If the middle of an encoded extent is overwritten, the filesystem may create + extents with a non-zero ``unencoded_offset`` and/or ``len < unencoded_len`` + for the parts that were not overwritten. + +Security +-------- + +Encoded I/O creates the potential for some security issues: + +* Encoded writes allow writing arbitrary data which the kernel will decode on a + subsequent read. Decompression algorithms are complex and may have bugs that + can be exploited by maliciously crafted data. +* Encoded reads may return data that is not logically present in the file (see + the discussion of ``len`` vs ``unencoded_len`` above). It may not be intended + for this data to be readable. + +Therefore, encoded I/O requires privilege. Namely, the ``RWF_ENCODED`` flag may +only be used if the file description has the ``O_ALLOW_ENCODED`` file status +flag set, and the ``O_ALLOW_ENCODED`` flag may only be set by a thread with the +``CAP_SYS_ADMIN`` capability. The ``O_ALLOW_ENCODED`` flag can be set by +``open()`` or ``fcntl()``. It can also be cleared by ``fcntl()``; clearing it +does not require ``CAP_SYS_ADMIN``. Note that it is not cleared on ``fork()`` +or ``execve()``. One may wish to use ``O_CLOEXEC`` with ``O_ALLOW_ENCODED``. + +Filesystem support +------------------ + +Encoded I/O is supported on the following filesystems: + +Btrfs (since Linux 5.14) +~~~~~~~~~~~~~~~~~~~~~~~~ + +Btrfs supports encoded reads and writes of compressed data. The data is encoded +as follows: + +* If ``compression`` is ``ENCODED_IOV_COMPRESSION_BTRFS_ZLIB``, then the encoded + data is a single zlib stream. +* If ``compression`` is ``ENCODED_IOV_COMPRESSION_BTRFS_ZSTD``, then the + encoded data is a single zstd frame compressed with the windowLog compression + parameter set to no more than 17. +* If ``compression`` is one of ``ENCODED_IOV_COMPRESSION_BTRFS_LZO_4K``, + ``ENCODED_IOV_COMPRESSION_BTRFS_LZO_8K``, + ``ENCODED_IOV_COMPRESSION_BTRFS_LZO_16K``, + ``ENCODED_IOV_COMPRESSION_BTRFS_LZO_32K``, or + ``ENCODED_IOV_COMPRESSION_BTRFS_LZO_64K``, then the encoded data is + compressed page by page (using the page size indicated by the name of the + constant) with LZO1X and wrapped in the format documented in the Linux kernel + source file ``fs/btrfs/lzo.c``. + +Additionally, there are some restrictions on ``pwritev2()``: + +* ``offset`` (or the current file offset if ``offset`` is -1) must be aligned + to the sector size of the filesystem. +* ``len`` must be aligned to the sector size of the filesystem unless the data + ends at or beyond the current end of the file. +* ``unencoded_len`` and the length of the encoded data must each be no more + than 128 KiB. This limit may increase in the future. +* The length of the encoded data must be less than or equal to + ``unencoded_len.`` +* If using LZO, the filesystem's page size must match the compression page + size. + +Implementation +============== + +This section describes the requirements for filesystems implementing encoded +I/O. + +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.
Documentation/filesystems/index.rst +1 -0
@@ -54,6 +54,7 @@ filesystem implementations. fscrypt fsverity netfs_library + encoded_io Filesystems ===========
fs/read_write.c +155 -13
196 lines not on this page · raw message
include/linux/encoded_io.h new file +17 -0
@@ -0,0 +1,17 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +#ifndef _LINUX_ENCODED_IO_H +#define _LINUX_ENCODED_IO_H + +#include <uapi/linux/encoded_io.h> + +struct encoded_iov ; +struct iov_iter ; +struct kiocb ; +extern int generic_encoded_write_checks (struct kiocb *, +const struct encoded_iov *); +extern int copy_encoded_iov_from_iter (struct encoded_iov *,struct iov_iter *); +extern ssize_t generic_encoded_read_checks (struct kiocb *,struct iov_iter *); +extern int copy_encoded_iov_to_iter (const struct encoded_iov *, +struct iov_iter *); + +#endif /* _LINUX_ENCODED_IO_H */
include/linux/fs.h +13 -0
@@ -181,6 +181,9 @@ typedef int (dio_iodone_t)(struct kiocb *iocb, loff_t offset,/* File supports async buffered reads */ #define FMODE_BUF_RASYNC ((__force fmode_t)0x40000000) +/* File supports encoded IO */ +#define FMODE_ENCODED_IO ((__force fmode_t)0x80000000) +/* * Attribute flags. These should be or-ed together to figure out what * has been changed!
@@ -311,6 +314,7 @@ enum rw_hint {#define IOCB_SYNC (__force int) RWF_SYNC#define IOCB_NOWAIT (__force int) RWF_NOWAIT#define IOCB_APPEND (__force int) RWF_APPEND +#define IOCB_ENCODED (__force int) RWF_ENCODED/* non-RWF related bits - start at 16 */ #define IOCB_EVENTFD (1 << 16)
@@ -3223,6 +3227,13 @@ extern int generic_file_readonly_mmap(struct file *, struct vm_area_struct *);extern ssize_t generic_write_checks (struct kiocb *,struct iov_iter *);extern int generic_write_check_limits (struct file *file,loff_t pos,loff_t *count); +struct encoded_iov ; +extern int generic_encoded_write_checks (struct kiocb *, +const struct encoded_iov *); +extern int copy_encoded_iov_from_iter (struct encoded_iov *,struct iov_iter *); +extern ssize_t generic_encoded_read_checks (struct kiocb *,struct iov_iter *); +extern int copy_encoded_iov_to_iter (const struct encoded_iov *, +struct iov_iter *);extern int generic_file_rw_checks (struct file *file_in,struct file *file_out);ssize_t filemap_read (struct kiocb *iocb,struct iov_iter *to,ssize_t already_read);
@@ -3528,6 +3539,8 @@ static inline int kiocb_set_rw_flags(struct kiocb *ki, rwf_t flags)return -EOPNOTSUPP ; kiocb_flags |=IOCB_NOIO ; } +if ((flags &RWF_ENCODED ) && !(ki->ki_filp->f_mode &FMODE_ENCODED_IO )) +return -EOPNOTSUPP ; kiocb_flags |= (__force int ) (flags &RWF_SUPPORTED );if (flags &RWF_SYNC ) kiocb_flags |=IOCB_DSYNC ;
include/uapi/linux/encoded_io.h new file +30 -0
@@ -0,0 +1,30 @@ +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */ +#ifndef _UAPI_LINUX_ENCODED_IO_H +#define _UAPI_LINUX_ENCODED_IO_H + +#include <linux/types.h> + +#define ENCODED_IOV_COMPRESSION_NONE 0 +#define ENCODED_IOV_COMPRESSION_BTRFS_ZLIB 1 +#define ENCODED_IOV_COMPRESSION_BTRFS_ZSTD 2 +#define ENCODED_IOV_COMPRESSION_BTRFS_LZO_4K 3 +#define ENCODED_IOV_COMPRESSION_BTRFS_LZO_8K 4 +#define ENCODED_IOV_COMPRESSION_BTRFS_LZO_16K 5 +#define ENCODED_IOV_COMPRESSION_BTRFS_LZO_32K 6 +#define ENCODED_IOV_COMPRESSION_BTRFS_LZO_64K 7 +#define ENCODED_IOV_COMPRESSION_TYPES 8 + +#define ENCODED_IOV_ENCRYPTION_NONE 0 +#define ENCODED_IOV_ENCRYPTION_TYPES 1 + +struct encoded_iov { +__aligned_u64 len; +__aligned_u64 unencoded_len; +__aligned_u64 unencoded_offset; +__u32 compression; +__u32 encryption; +}; + +#define ENCODED_IOV_SIZE_VER0 32 + +#endif /* _UAPI_LINUX_ENCODED_IO_H */
include/uapi/linux/fs.h +4 -1
@@ -300,8 +300,11 @@ typedef int __bitwise __kernel_rwf_t;/* per-IO O_APPEND */ #define RWF_APPEND ((__force __kernel_rwf_t)0x00000010) +/* encoded (e.g., compressed and/or encrypted) IO */ +#define RWF_ENCODED ((__force __kernel_rwf_t)0x00000020) +/* mask of flags supported by the kernel */ #define RWF_SUPPORTED (RWF_HIPRI | RWF_DSYNC | RWF_SYNC | RWF_NOWAIT |\ - RWF_APPEND) + RWF_APPEND | RWF_ENCODED)#endif /* _UAPI_LINUX_FS_H */
Signature · 1 line
2.31.1
PATCH v9 4/9 btrfs: don't advance offset for compressed bios in btrfs_csum_one_bio()
In reply to Omar SandovalFrom: Omar Sandoval <[email protected]>
btrfs_csum_one_bio() loops over each filesystem block in the bio while keeping a cursor of its current logical position in the file in order to look up the ordered extent to add the checksums to. However, this doesn't make much sense for compressed extents, as a sector on disk does not correspond to a sector of decompressed file data. It happens to work because 1) the compressed bio always covers one ordered extent and 2) the size of the bio is always less than the size of the ordered extent. However, the second point will not always be true for encoded writes.
Let's add a boolean parameter to btrfs_csum_one_bio() to indicate that it can assume that the bio only covers one ordered extent. Since we're already changing the signature, let's get rid of the contig parameter and make it implied by the offset parameter, similar to the change we recently made to btrfs_lookup_bio_sums(). Additionally, let's rename nr_sectors to blockcount to make it clear that it's the number of filesystem blocks, not the number of 512-byte sectors.
--- fs/btrfs/compression.c | 5 +++-- fs/btrfs/ctree.h | 2 +- fs/btrfs/file-item.c | 35 ++++++++++++++++------------------- fs/btrfs/inode.c | 8 ++++---- 4 files changed, 24 insertions(+), 26 deletions(-)
fs/btrfs/compression.c +3 -2
@@ -454,7 +454,8 @@ blk_status_t btrfs_submit_compressed_write(struct btrfs_inode *inode, u64 start,BUG_ON (ret);/* -ENOMEM */ if (!skip_sum) { - ret =btrfs_csum_one_bio (inode, bio, start,1 ); + ret =btrfs_csum_one_bio (inode, bio, start, + true);BUG_ON (ret);/* -ENOMEM */ }
@@ -486,7 +487,7 @@ blk_status_t btrfs_submit_compressed_write(struct btrfs_inode *inode, u64 start,BUG_ON (ret);/* -ENOMEM */ if (!skip_sum) { - ret =btrfs_csum_one_bio (inode, bio, start,1 ); + ret =btrfs_csum_one_bio (inode, bio, start, true);BUG_ON (ret);/* -ENOMEM */ }
fs/btrfs/ctree.h +1 -1
@@ -3082,7 +3082,7 @@ int btrfs_csum_file_blocks(struct btrfs_trans_handle *trans,struct btrfs_root *root, struct btrfs_ordered_sum *sums);blk_status_t btrfs_csum_one_bio (struct btrfs_inode *inode,struct bio *bio, -u64 file_start,int contig); +u64 offset,bool one_ordered);int btrfs_lookup_csums_range (struct btrfs_root *root,u64 start,u64 end,struct list_head *list,int search_commit); void btrfs_extent_item_to_extent_map(struct btrfs_inode *inode,
fs/btrfs/file-item.c +16 -19
@@ -615,28 +615,28 @@ int btrfs_lookup_csums_range(struct btrfs_root *root, u64 start, u64 end,* btrfs_csum_one_bio - Calculates checksums of the data contained inside a bio * @inode: Owner of the data inside the bio * @bio: Contains the data to be checksummed -* @file_start: offset in file this bio begins to describe -* @contig: Boolean. If true/1 means all bio vecs in this bio are -* contiguous and they begin at @file_start in the file. False/0 -* means this bio can contains potentially discontigous bio vecs -* so the logical offset of each should be calculated separately. +* @offset: If (u64)-1, @bio may contain discontiguous bio vecs, so the +* file offsets are determined from the page offsets in the bio. +* Otherwise, this is the starting file offset of the bio vecs in +* @bio, which must be contiguous. +* @one_ordered: If true, @bio only refers to one ordered extent. */ blk_status_t btrfs_csum_one_bio (struct btrfs_inode *inode,struct bio *bio, -u64 file_start,int contig) +u64 offset,bool one_ordered) {struct btrfs_fs_info *fs_info = inode->root->fs_info;SHASH_DESC_ON_STACK (shash, fs_info->csum_shash);struct btrfs_ordered_sum *sums;struct btrfs_ordered_extent *ordered =NULL ; +const bool page_offsets = (offset == (u64)-1 );char *data;struct bvec_iter iter;struct bio_vec bvec;int index; -int nr_sectors; +int blockcount;unsigned long total_bytes =0 ;unsigned long this_sum_bytes =0 ;int i; -u64 offset;unsigned nofs_flag; nofs_flag =memalloc_nofs_save ();
@@ -650,18 +650,13 @@ blk_status_t btrfs_csum_one_bio(struct btrfs_inode *inode, struct bio *bio, sums->len = bio->bi_iter.bi_size;INIT_LIST_HEAD (&sums->list); -if (contig) - offset = file_start; -else - offset =0 ;/* shut up gcc */ - sums->bytenr = bio->bi_iter.bi_sector <<9 ; index =0 ; shash->tfm = fs_info->csum_shash;bio_for_each_segment (bvec, bio, iter) { -if (!contig) +if (page_offsets) offset =page_offset (bvec.bv_page) + bvec.bv_offset;if (!ordered) {
@@ -669,13 +664,14 @@ blk_status_t btrfs_csum_one_bio(struct btrfs_inode *inode, struct bio *bio,BUG_ON (!ordered);/* Logic error */ } - nr_sectors =BTRFS_BYTES_TO_BLKS (fs_info, + blockcount =BTRFS_BYTES_TO_BLKS (fs_info, bvec.bv_len + fs_info->sectorsize -1 ); -for (i =0 ; i < nr_sectors; i++) { -if (offset >= ordered->file_offset + ordered->num_bytes || - offset < ordered->file_offset) { +for (i =0 ; i < blockcount; i++) { +if (!one_ordered && + (offset >= ordered->file_offset + ordered->num_bytes || + offset < ordered->file_offset)) {unsigned long bytes_left; sums->len = this_sum_bytes;
@@ -706,7 +702,8 @@ blk_status_t btrfs_csum_one_bio(struct btrfs_inode *inode, struct bio *bio, sums->sums + index);kunmap_atomic (data); index += fs_info->csum_size; - offset += fs_info->sectorsize; +if (!one_ordered) + offset += fs_info->sectorsize; this_sum_bytes += fs_info->sectorsize; total_bytes += fs_info->sectorsize; }
fs/btrfs/inode.c +4 -4
@@ -2230,7 +2230,7 @@ int btrfs_bio_fits_in_stripe(struct page *page, size_t size, struct bio *bio,static blk_status_t btrfs_submit_bio_start (struct inode *inode,struct bio *bio,u64 dio_file_offset) { -return btrfs_csum_one_bio (BTRFS_I (inode), bio,0 ,0 ); +return btrfs_csum_one_bio (BTRFS_I (inode), bio, (u64)-1 , false); } bool btrfs_bio_fits_in_ordered_extent(struct page *page, struct bio *bio,
@@ -2420,7 +2420,7 @@ blk_status_t btrfs_submit_data_bio(struct inode *inode, struct bio *bio, 0, btrfs_submit_bio_start); goto out; }else if (!skip_sum) { - ret =btrfs_csum_one_bio (BTRFS_I (inode), bio,0 ,0 ); + ret =btrfs_csum_one_bio (BTRFS_I (inode), bio, (u64)-1 , false);if (ret) goto out; }
@@ -7999,7 +7999,7 @@ static blk_status_t btrfs_submit_bio_start_direct_io(struct inode *inode,struct bio *bio, u64 dio_file_offset) { - return btrfs_csum_one_bio(BTRFS_I(inode), bio, dio_file_offset, 1); + return btrfs_csum_one_bio(BTRFS_I(inode), bio, dio_file_offset, false); }static void btrfs_end_dio_bio (struct bio *bio)
@@ -8058,7 +8058,7 @@ static inline blk_status_t btrfs_submit_dio_bio(struct bio *bio,* If we aren't doing async submit, calculate the csum of the * bio now. */ - ret =btrfs_csum_one_bio (BTRFS_I (inode), bio, file_offset,1 ); + ret =btrfs_csum_one_bio (BTRFS_I (inode), bio, file_offset, false);if (ret) goto err; }else {
Signature · 1 line
2.31.1
PATCH v9 5/9 btrfs: add ram_bytes and offset to btrfs_ordered_extent
In reply to Omar SandovalFrom: Omar Sandoval <[email protected]>
Currently, we only create ordered extents when ram_bytes == num_bytes and offset == 0. However, RWF_ENCODED writes may create extents which only refer to a subset of the full unencoded extent, so we need to plumb these fields through the ordered extent infrastructure and pass them down to insert_reserved_file_extent().
Since we're changing the btrfs_add_ordered_extent* signature, let's get rid of the trivial wrappers and add a kernel-doc.
--- fs/btrfs/inode.c | 56 +++++++++++--------- fs/btrfs/ordered-data.c | 112 +++++++++++----------------------------- fs/btrfs/ordered-data.h | 22 ++++---- 3 files changed, 76 insertions(+), 114 deletions(-)
fs/btrfs/inode.c +32 -24
@@ -912,12 +912,12 @@ static noinline void submit_compressed_extents(struct async_chunk *async_chunk) goto out_free_reserve;free_extent_map (em); - ret =btrfs_add_ordered_extent_compress (inode, - async_extent->start, - ins.objectid, - async_extent->ram_size, - ins.offset, - async_extent->compress_type); + ret =btrfs_add_ordered_extent (inode, async_extent->start, + async_extent->ram_size, + async_extent->ram_size, + ins.objectid, ins.offset,0 , +1 <<BTRFS_ORDERED_COMPRESSED , + async_extent->compress_type);if (ret) { btrfs_drop_extent_cache(inode, async_extent->start, async_extent->start +
@@ -1122,9 +1122,9 @@ static noinline int cow_file_range(struct btrfs_inode *inode, }free_extent_map (em); - ret =btrfs_add_ordered_extent (inode, start, ins.objectid, - ram_size, cur_alloc_size, -BTRFS_ORDERED_REGULAR ); + ret =btrfs_add_ordered_extent (inode, start, ram_size, ram_size, + ins.objectid, cur_alloc_size,0 , +0 ,BTRFS_COMPRESS_NONE );if (ret) goto out_drop_extent_cache;
@@ -1784,10 +1784,11 @@ static noinline int run_delalloc_nocow(struct btrfs_inode *inode, goto error; }free_extent_map (em); - ret =btrfs_add_ordered_extent (inode, cur_offset, - disk_bytenr, num_bytes, - num_bytes, -BTRFS_ORDERED_PREALLOC ); + ret =btrfs_add_ordered_extent (inode, + cur_offset, num_bytes, num_bytes, + disk_bytenr, num_bytes,0 , +1 <<BTRFS_ORDERED_PREALLOC , +BTRFS_COMPRESS_NONE );if (ret) { btrfs_drop_extent_cache(inode, cur_offset, cur_offset + num_bytes - 1,
@@ -1796,9 +1797,11 @@ static noinline int run_delalloc_nocow(struct btrfs_inode *inode, } }else { ret =btrfs_add_ordered_extent (inode, cur_offset, + num_bytes, num_bytes, disk_bytenr, num_bytes, - num_bytes, -BTRFS_ORDERED_NOCOW ); +0 , +1 <<BTRFS_ORDERED_NOCOW , +BTRFS_COMPRESS_NONE );if (ret) goto error; }
@@ -2724,6 +2727,7 @@ static int insert_reserved_file_extent(struct btrfs_trans_handle *trans,struct btrfs_key ins;u64 disk_num_bytes =btrfs_stack_file_extent_disk_num_bytes (stack_fi);u64 disk_bytenr =btrfs_stack_file_extent_disk_bytenr (stack_fi); +u64 offset =btrfs_stack_file_extent_offset (stack_fi);u64 num_bytes =btrfs_stack_file_extent_num_bytes (stack_fi);u64 ram_bytes =btrfs_stack_file_extent_ram_bytes (stack_fi);struct btrfs_drop_extents_args drop_args = {0 };
@@ -2798,7 +2802,8 @@ static int insert_reserved_file_extent(struct btrfs_trans_handle *trans, goto out; ret =btrfs_alloc_reserved_file_extent (trans, root,btrfs_ino (inode), - file_pos, qgroup_reserved, &ins); + file_pos - offset, + qgroup_reserved, &ins); out:btrfs_free_path (path);
@@ -2824,20 +2829,20 @@ static int insert_ordered_extent_file_extent(struct btrfs_trans_handle *trans, struct btrfs_ordered_extent *oe) {struct btrfs_file_extent_item stack_fi; -u64 logical_len;bool update_inode_bytes; +u64 num_bytes = oe->num_bytes; +u64 ram_bytes = oe->ram_bytes;memset (&stack_fi,0 ,sizeof (stack_fi));btrfs_set_stack_file_extent_type (&stack_fi,BTRFS_FILE_EXTENT_REG );btrfs_set_stack_file_extent_disk_bytenr (&stack_fi, oe->disk_bytenr);btrfs_set_stack_file_extent_disk_num_bytes (&stack_fi, oe->disk_num_bytes); +btrfs_set_stack_file_extent_offset (&stack_fi, oe->offset);if (test_bit (BTRFS_ORDERED_TRUNCATED , &oe->flags)) - logical_len = oe->truncated_len; -else - logical_len = oe->num_bytes; -btrfs_set_stack_file_extent_num_bytes (&stack_fi, logical_len); -btrfs_set_stack_file_extent_ram_bytes (&stack_fi, logical_len); + num_bytes = ram_bytes = oe->truncated_len; +btrfs_set_stack_file_extent_num_bytes (&stack_fi, num_bytes); +btrfs_set_stack_file_extent_ram_bytes (&stack_fi, ram_bytes);btrfs_set_stack_file_extent_compression (&stack_fi, oe->compress_type);/* Encryption and other encoding is reserved and all 0 */
@@ -7221,8 +7226,11 @@ static struct extent_map *btrfs_create_dio_extent(struct btrfs_inode *inode,if (IS_ERR (em)) goto out; } - ret =btrfs_add_ordered_extent_dio (inode, start, block_start, len, - block_len, type); + ret =btrfs_add_ordered_extent (inode, start, len, len, block_start, + block_len,0 , + (1 << type) | + (1 <<BTRFS_ORDERED_DIRECT ), +BTRFS_COMPRESS_NONE );if (ret) {if (em) {free_extent_map (em);
fs/btrfs/ordered-data.c +31 -81
157 lines not on this page · raw message
fs/btrfs/ordered-data.h +13 -9
@@ -76,6 +76,13 @@ enum { BTRFS_ORDERED_PENDING, }; +/* BTRFS_ORDERED_* flags that specify the type of the extent. */ +#define BTRFS_ORDERED_TYPE_FLAGS ((1UL << BTRFS_ORDERED_REGULAR) | \ + (1UL << BTRFS_ORDERED_NOCOW) | \ + (1UL << BTRFS_ORDERED_PREALLOC) | \ + (1UL << BTRFS_ORDERED_COMPRESSED) | \ + (1UL << BTRFS_ORDERED_DIRECT)) +struct btrfs_ordered_extent {/* logical offset in the file */ u64 file_offset;
@@ -84,9 +91,11 @@ struct btrfs_ordered_extent {* These fields directly correspond to the same fields in * btrfs_file_extent_item. */ -u64 disk_bytenr;u64 num_bytes; +u64 ram_bytes; +u64 disk_bytenr;u64 disk_num_bytes; +u64 offset;/* number of bytes that still need writing */ u64 bytes_left;
@@ -180,14 +189,9 @@ bool btrfs_dec_test_first_ordered_pending(struct btrfs_inode *inode, u64 *file_offset, u64 io_size, int uptodate);int btrfs_add_ordered_extent (struct btrfs_inode *inode,u64 file_offset, -u64 disk_bytenr,u64 num_bytes,u64 disk_num_bytes, -int type); -int btrfs_add_ordered_extent_dio (struct btrfs_inode *inode,u64 file_offset, -u64 disk_bytenr,u64 num_bytes, -u64 disk_num_bytes,int type); -int btrfs_add_ordered_extent_compress (struct btrfs_inode *inode,u64 file_offset, -u64 disk_bytenr,u64 num_bytes, -u64 disk_num_bytes,int compress_type); +u64 num_bytes,u64 ram_bytes,u64 disk_bytenr, +u64 disk_num_bytes,u64 offset,int flags, +int compress_type);void btrfs_add_ordered_sum (struct btrfs_ordered_extent *entry,struct btrfs_ordered_sum *sum); struct btrfs_ordered_extent *btrfs_lookup_ordered_extent(struct btrfs_inode *inode,
Signature · 1 line
2.31.1
PATCH v9 6/9 btrfs: support different disk extent size for delalloc
In reply to Omar SandovalFrom: Omar Sandoval <[email protected]>
Currently, we always reserve the same extent size in the file and extent size on disk for delalloc because the former is the worst case for the latter. For RWF_ENCODED writes, we know the exact size of the extent on disk, which may be less than or greater than (for bookends) the size in the file. Add a disk_num_bytes parameter to btrfs_delalloc_reserve_metadata() so that we can reserve the correct amount of csum bytes. No functional change.
--- fs/btrfs/ctree.h | 3 ++- fs/btrfs/delalloc-space.c | 18 ++++++++++-------- fs/btrfs/file.c | 3 ++- fs/btrfs/inode.c | 2 +- fs/btrfs/relocation.c | 4 ++-- 5 files changed, 17 insertions(+), 13 deletions(-)
fs/btrfs/ctree.h +2 -1
@@ -2784,7 +2784,8 @@ void btrfs_subvolume_release_metadata(struct btrfs_root *root, struct btrfs_block_rsv *rsv);void btrfs_delalloc_release_extents (struct btrfs_inode *inode,u64 num_bytes); -int btrfs_delalloc_reserve_metadata (struct btrfs_inode *inode,u64 num_bytes); +int btrfs_delalloc_reserve_metadata (struct btrfs_inode *inode,u64 num_bytes, +u64 disk_num_bytes);u64 btrfs_account_ro_block_groups_free_space (struct btrfs_space_info *sinfo);int btrfs_error_unpin_extent_range (struct btrfs_fs_info *fs_info,u64 start,u64 end);
fs/btrfs/delalloc-space.c +10 -8
@@ -267,11 +267,11 @@ static void btrfs_calculate_inode_block_rsv_size(struct btrfs_fs_info *fs_info, }static void calc_inode_reservations (struct btrfs_fs_info *fs_info, -u64 num_bytes,u64 *meta_reserve, -u64 *qgroup_reserve) +u64 num_bytes,u64 disk_num_bytes, +u64 *meta_reserve,u64 *qgroup_reserve) {u64 nr_extents =count_max_extents (num_bytes); -u64 csum_leaves =btrfs_csum_bytes_to_leaves (fs_info, num_bytes); +u64 csum_leaves =btrfs_csum_bytes_to_leaves (fs_info, disk_num_bytes);u64 inode_update =btrfs_calc_metadata_size (fs_info,1 ); *meta_reserve = btrfs_calc_insert_metadata_size(fs_info,
@@ -285,7 +285,8 @@ static void calc_inode_reservations(struct btrfs_fs_info *fs_info, *qgroup_reserve = nr_extents * fs_info->nodesize; } -int btrfs_delalloc_reserve_metadata (struct btrfs_inode *inode,u64 num_bytes) +int btrfs_delalloc_reserve_metadata (struct btrfs_inode *inode,u64 num_bytes, +u64 disk_num_bytes) {struct btrfs_root *root = inode->root;struct btrfs_fs_info *fs_info = root->fs_info;
@@ -315,6 +316,7 @@ int btrfs_delalloc_reserve_metadata(struct btrfs_inode *inode, u64 num_bytes) } num_bytes =ALIGN (num_bytes, fs_info->sectorsize); + disk_num_bytes =ALIGN (disk_num_bytes, fs_info->sectorsize);/* * We always want to do it this way, every other way is wrong and ends
@@ -326,8 +328,8 @@ int btrfs_delalloc_reserve_metadata(struct btrfs_inode *inode, u64 num_bytes)* everything out and try again, which is bad. This way we just * over-reserve slightly, and clean up the mess when we are done. */ -calc_inode_reservations (fs_info, num_bytes, &meta_reserve, - &qgroup_reserve); +calc_inode_reservations (fs_info, num_bytes, disk_num_bytes, + &meta_reserve, &qgroup_reserve); ret =btrfs_qgroup_reserve_meta_prealloc (root, qgroup_reserve, true);if (ret)return ret;
@@ -346,7 +348,7 @@ int btrfs_delalloc_reserve_metadata(struct btrfs_inode *inode, u64 num_bytes)spin_lock (&inode->lock); nr_extents =count_max_extents (num_bytes);btrfs_mod_outstanding_extents (inode, nr_extents); - inode->csum_bytes += num_bytes; + inode->csum_bytes += disk_num_bytes;btrfs_calculate_inode_block_rsv_size (fs_info, inode);spin_unlock (&inode->lock);
@@ -451,7 +453,7 @@ int btrfs_delalloc_reserve_space(struct btrfs_inode *inode, ret =btrfs_check_data_free_space (inode, reserved, start, len);if (ret <0 )return ret; - ret =btrfs_delalloc_reserve_metadata (inode, len); + ret =btrfs_delalloc_reserve_metadata (inode, len, len);if (ret <0 )btrfs_free_reserved_data_space (inode, *reserved, start, len);return ret;
fs/btrfs/file.c +2 -1
@@ -1727,7 +1727,8 @@ static noinline ssize_t btrfs_buffered_write(struct kiocb *iocb, fs_info->sectorsize);WARN_ON (reserve_bytes ==0 ); ret =btrfs_delalloc_reserve_metadata (BTRFS_I (inode), - reserve_bytes); + reserve_bytes, + reserve_bytes);if (ret) {if (!only_release_metadata) btrfs_free_reserved_data_space(BTRFS_I(inode),
fs/btrfs/inode.c +1 -1
@@ -4870,7 +4870,7 @@ int btrfs_truncate_block(struct btrfs_inode *inode, loff_t from, loff_t len, goto out; } } - ret =btrfs_delalloc_reserve_metadata (inode, blocksize); + ret =btrfs_delalloc_reserve_metadata (inode, blocksize, blocksize);if (ret <0 ) {if (!only_release_metadata) btrfs_free_reserved_data_space(inode, data_reserved,
fs/btrfs/relocation.c +2 -2
@@ -2921,8 +2921,8 @@ static int relocate_file_extent_cluster(struct inode *inode, index = (cluster->start - offset) >>PAGE_SHIFT ; last_index = (cluster->end - offset) >>PAGE_SHIFT ;while (index <= last_index) { - ret =btrfs_delalloc_reserve_metadata (BTRFS_I (inode), -PAGE_SIZE ); + ret =btrfs_delalloc_reserve_metadata (BTRFS_I (inode),PAGE_SIZE , +PAGE_SIZE );if (ret) goto out;
Signature · 1 line
2.31.1
PATCH v9 7/9 btrfs: optionally extend i_size in cow_file_range_inline()
In reply to Omar SandovalFrom: Omar Sandoval <[email protected]>
Currently, an inline extent is always created after i_size is extended from btrfs_dirty_pages(). However, for encoded writes, we only want to update i_size after we successfully created the inline extent. Add an update_i_size parameter to cow_file_range_inline() and insert_inline_extent() and pass in the size of the extent rather than determining it from i_size. Since the start parameter is always passed as 0, get rid of it and simplify the logic in these two functions. While we're here, let's document the requirements for creating an inline extent.
--- fs/btrfs/inode.c | 100 +++++++++++++++++++++++------------------------ 1 file changed, 48 insertions(+), 52 deletions(-)
fs/btrfs/inode.c +48 -52
@@ -209,9 +209,10 @@ static int btrfs_init_inode_security(struct btrfs_trans_handle *trans,static int insert_inline_extent (struct btrfs_trans_handle *trans,struct btrfs_path *path,bool extent_inserted,struct btrfs_root *root,struct inode *inode, -u64 start,size_t size,size_t compressed_size, +size_t size,size_t compressed_size,int compress_type, -struct page **compressed_pages) +struct page **compressed_pages, +bool update_i_size) {struct extent_buffer *leaf;struct page *page =NULL ;
@@ -220,7 +221,7 @@ static int insert_inline_extent(struct btrfs_trans_handle *trans,struct btrfs_file_extent_item *ei;int ret;size_t cur_size = size; -unsigned long offset; +u64 i_size;ASSERT ((compressed_size >0 && compressed_pages) || (compressed_size ==0 && !compressed_pages));
@@ -233,7 +234,7 @@ static int insert_inline_extent(struct btrfs_trans_handle *trans,size_t datasize; key.objectid =btrfs_ino (BTRFS_I (inode)); - key.offset = start; + key.offset =0 ; key.type =BTRFS_EXTENT_DATA_KEY ; datasize =btrfs_file_extent_calc_inline_size (cur_size);
@@ -271,12 +272,10 @@ static int insert_inline_extent(struct btrfs_trans_handle *trans,btrfs_set_file_extent_compression (leaf, ei, compress_type); }else { - page =find_get_page (inode->i_mapping, - start >>PAGE_SHIFT ); + page =find_get_page (inode->i_mapping,0 );btrfs_set_file_extent_compression (leaf, ei,0 ); kaddr =kmap_atomic (page); - offset =offset_in_page (start); -write_extent_buffer (leaf, kaddr + offset, ptr, size); +write_extent_buffer (leaf, kaddr, ptr, size);kunmap_atomic (kaddr);put_page (page); }
@@ -287,8 +286,8 @@ static int insert_inline_extent(struct btrfs_trans_handle *trans,* We align size to sectorsize for inline extents just for simplicity * sake. */ - size =ALIGN (size, root->fs_info->sectorsize); - ret =btrfs_inode_set_file_extent_range (BTRFS_I (inode), start, size); + ret =btrfs_inode_set_file_extent_range (BTRFS_I (inode),0 , +ALIGN (size, root->fs_info->sectorsize));if (ret) goto fail;
@@ -301,7 +300,13 @@ static int insert_inline_extent(struct btrfs_trans_handle *trans,* before we unlock the pages. Otherwise we * could end up racing with unlink. */ -BTRFS_I (inode)->disk_i_size = inode->i_size; + i_size =i_size_read (inode); +if (update_i_size && size > i_size) { +i_size_write (inode, size); + i_size = size; + } +BTRFS_I (inode)->disk_i_size = i_size; + fail:return ret; }
@@ -312,35 +317,31 @@ static int insert_inline_extent(struct btrfs_trans_handle *trans,* does the checks required to make sure the data is small enough * to fit as an inline extent. */ -static noinline int cow_file_range_inline(struct btrfs_inode *inode, u64 start, -u64 end,size_t compressed_size, +static noinline int cow_file_range_inline(struct btrfs_inode *inode, u64 size, +size_t compressed_size,int compress_type, -struct page **compressed_pages) +struct page **compressed_pages, +bool update_i_size) {struct btrfs_drop_extents_args drop_args = {0 };struct btrfs_root *root = inode->root;struct btrfs_fs_info *fs_info = root->fs_info;struct btrfs_trans_handle *trans; -u64 isize =i_size_read (&inode->vfs_inode); -u64 actual_end =min (end +1 , isize); -u64 inline_len = actual_end - start; -u64 aligned_end =ALIGN (end, fs_info->sectorsize); -u64 data_len = inline_len; +u64 data_len = compressed_size ? compressed_size : size;int ret;struct btrfs_path *path; -if (compressed_size) - data_len = compressed_size; - -if (start >0 || - actual_end > fs_info->sectorsize || +/* +* We can create an inline extent if it ends at or beyond the current +* i_size, is no larger than a sector (decompressed), and the (possibly +* compressed) data fits in a leaf and the configured maximum inline +* size. +*/ +if (size <i_size_read (&inode->vfs_inode) || + size > fs_info->sectorsize || data_len >BTRFS_MAX_INLINE_DATA_SIZE (fs_info) || - (!compressed_size && - (actual_end & (fs_info->sectorsize -1 )) ==0 ) || - end +1 < isize || - data_len > fs_info->max_inline) { + data_len > fs_info->max_inline)return 1 ; - } path =btrfs_alloc_path ();if (!path)
@@ -354,30 +355,21 @@ static noinline int cow_file_range_inline(struct btrfs_inode *inode, u64 start, trans->block_rsv = &inode->block_rsv; drop_args.path = path; - drop_args.start = start; - drop_args.end = aligned_end; + drop_args.start =0 ; + drop_args.end = fs_info->sectorsize; drop_args.drop_cache = true; drop_args.replace_extent = true; - -if (compressed_size && compressed_pages) - drop_args.extent_item_size =btrfs_file_extent_calc_inline_size ( - compressed_size); -else - drop_args.extent_item_size =btrfs_file_extent_calc_inline_size ( - inline_len); - + drop_args.extent_item_size =btrfs_file_extent_calc_inline_size (data_len); ret =btrfs_drop_extents (trans, root, inode, &drop_args);if (ret) {btrfs_abort_transaction (trans, ret); goto out; } -if (isize > actual_end) - inline_len =min_t (u64, isize, actual_end); - ret =insert_inline_extent (trans, path, drop_args.extent_inserted, - root, &inode->vfs_inode, start, - inline_len, compressed_size, - compress_type, compressed_pages); + ret =insert_inline_extent (trans, path, drop_args.extent_inserted, root, + &inode->vfs_inode, size, compressed_size, + compress_type, compressed_pages, + update_i_size);if (ret && ret != -ENOSPC ) {btrfs_abort_transaction (trans, ret); goto out;
@@ -386,7 +378,7 @@ static noinline int cow_file_range_inline(struct btrfs_inode *inode, u64 start, goto out; } -btrfs_update_inode_bytes (inode, inline_len, drop_args.bytes_found); +btrfs_update_inode_bytes (inode, size, drop_args.bytes_found); ret =btrfs_update_inode (trans, root, inode);if (ret && ret != -ENOSPC ) {btrfs_abort_transaction (trans, ret);
@@ -662,14 +654,15 @@ static noinline int compress_file_range(struct async_chunk *async_chunk)/* we didn't compress the entire range, try * to make an uncompressed inline extent. */ - ret =cow_file_range_inline (BTRFS_I (inode), start, end, + ret =cow_file_range_inline (BTRFS_I (inode), actual_end,0 ,BTRFS_COMPRESS_NONE , -NULL ); +NULL , false); }else {/* try making a compressed inline extent */ - ret =cow_file_range_inline (BTRFS_I (inode), start, end, + ret =cow_file_range_inline (BTRFS_I (inode), actual_end, total_compressed, - compress_type, pages); + compress_type, pages, + false); }if (ret <=0 ) { unsigned long clear_flags = EXTENT_DELALLOC |
@@ -1054,9 +1047,12 @@ static noinline int cow_file_range(struct btrfs_inode *inode,inode_should_defrag (inode, start, end, num_bytes,SZ_64K );if (start ==0 ) { +u64 actual_end =min_t (u64,i_size_read (&inode->vfs_inode), + end +1 ); +/* lets try to make an inline extent */ - ret =cow_file_range_inline (inode, start, end,0 , -BTRFS_COMPRESS_NONE ,NULL ); + ret =cow_file_range_inline (inode, actual_end,0 , +BTRFS_COMPRESS_NONE ,NULL , false);if (ret ==0 ) {/* * We use DO_ACCOUNTING here because we need the
Signature · 1 line
2.31.1
PATCH v9 8/9 btrfs: implement RWF_ENCODED reads
In reply to Omar SandovalFrom: Omar Sandoval <[email protected]>
There are 4 main cases:
1. Inline extents: we copy the data straight out of the extent buffer.
2. Hole/preallocated extents: we fill in zeroes.
3. Regular, uncompressed extents: we read the sectors we need directly from disk.
4. Regular, compressed extents: we read the entire compressed extent from disk and indicate what subset of the decompressed extent is in the file.
This initial implementation simplifies a few things that can be improved in the future:
- We hold the inode lock during the operation.
- Cases 1, 3, and 4 allocate temporary memory to read into before copying out to userspace.
- We don't do read repair, because it turns out that read repair is currently broken for compressed data.
--- fs/btrfs/ctree.h | 2 + fs/btrfs/file.c | 5 + fs/btrfs/inode.c | 504 +++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 511 insertions(+)
fs/btrfs/ctree.h +2 -0
@@ -3190,6 +3190,8 @@ int btrfs_run_delalloc_range(struct btrfs_inode *inode, struct page *locked_pageint btrfs_writepage_cow_fixup (struct page *page,u64 start,u64 end);void btrfs_writepage_endio_finish_ordered (struct page *page,u64 start,u64 end,int uptodate); +ssize_t btrfs_encoded_read (struct kiocb *iocb,struct iov_iter *iter); +extern const struct dentry_operations btrfs_dentry_operations;extern const struct iomap_ops btrfs_dio_iomap_ops;extern const struct iomap_dio_ops btrfs_dio_ops;
fs/btrfs/file.c +5 -0
@@ -3636,6 +3636,11 @@ static ssize_t btrfs_file_read_iter(struct kiocb *iocb, struct iov_iter *to) {ssize_t ret =0 ; +if (iocb->ki_flags &IOCB_ENCODED ) { +if (iocb->ki_flags &IOCB_NOWAIT ) +return -EOPNOTSUPP ; +return btrfs_encoded_read (iocb, to); + }if (iocb->ki_flags &IOCB_DIRECT ) { ret =btrfs_direct_read (iocb, to); if (ret < 0 || !iov_iter_count(to) ||
fs/btrfs/inode.c +504 -0
516 lines not on this page · raw message
Signature · 1 line
2.31.1
PATCH v9 9/9 btrfs: implement RWF_ENCODED writes
In reply to Omar SandovalFrom: Omar Sandoval <[email protected]>
The implementation resembles direct I/O: we have to flush any ordered extents, invalidate the page cache, and do the io tree/delalloc/extent map/ordered extent dance. From there, we can reuse the compression code with a minor modification to distinguish the write from writeback. This also creates inline extents when possible.
Now that read and write are implemented, this also sets the FMODE_ENCODED_IO flag in btrfs_file_open().
--- fs/btrfs/compression.c | 7 +- fs/btrfs/compression.h | 6 +- fs/btrfs/ctree.h | 2 + fs/btrfs/file.c | 38 +++++- fs/btrfs/inode.c | 259 +++++++++++++++++++++++++++++++++++++++- fs/btrfs/ordered-data.c | 12 +- fs/btrfs/ordered-data.h | 5 +- 7 files changed, 316 insertions(+), 13 deletions(-)
fs/btrfs/compression.c +5 -2
@@ -354,7 +354,8 @@ static void end_compressed_bio_write(struct bio *bio) bio->bi_status == BLK_STS_OK); cb->compressed_pages[0 ]->mapping =NULL ; -end_compressed_writeback (inode, cb); +if (cb->writeback) +end_compressed_writeback (inode, cb);/* note, our inode could be gone now */ /*
@@ -390,7 +391,8 @@ blk_status_t btrfs_submit_compressed_write(struct btrfs_inode *inode, u64 start,struct page **compressed_pages, unsigned long nr_pages, unsigned int write_flags, - struct cgroup_subsys_state *blkcg_css) + struct cgroup_subsys_state *blkcg_css, + bool writeback) { struct btrfs_fs_info *fs_info = inode->root->fs_info;struct bio *bio =NULL ;
@@ -414,6 +416,7 @@ blk_status_t btrfs_submit_compressed_write(struct btrfs_inode *inode, u64 start, cb->mirror_num =0 ; cb->compressed_pages = compressed_pages; cb->compressed_len = compressed_len; + cb->writeback = writeback; cb->orig_bio =NULL ; cb->nr_pages = nr_pages;
fs/btrfs/compression.h +5 -1
@@ -49,6 +49,9 @@ struct compressed_bio {/* the compression algorithm for this bio */ int compress_type; +/* Whether this is a write for writeback. */ +bool writeback; +/* number of compressed pages in the array */ unsigned long nr_pages;
@@ -96,7 +99,8 @@ blk_status_t btrfs_submit_compressed_write(struct btrfs_inode *inode, u64 start,struct page **compressed_pages, unsigned long nr_pages, unsigned int write_flags, - struct cgroup_subsys_state *blkcg_css); + struct cgroup_subsys_state *blkcg_css, + bool writeback);blk_status_t btrfs_submit_compressed_read (struct inode *inode,struct bio *bio,int mirror_num,unsigned long bio_flags);
fs/btrfs/ctree.h +2 -0
@@ -3191,6 +3191,8 @@ int btrfs_writepage_cow_fixup(struct page *page, u64 start, u64 end);void btrfs_writepage_endio_finish_ordered (struct page *page,u64 start,u64 end,int uptodate);ssize_t btrfs_encoded_read (struct kiocb *iocb,struct iov_iter *iter); +ssize_t btrfs_do_encoded_write (struct kiocb *iocb,struct iov_iter *from, +struct encoded_iov *encoded);extern const struct dentry_operations btrfs_dentry_operations;extern const struct iomap_ops btrfs_dio_iomap_ops;
fs/btrfs/file.c +34 -4
@@ -3,6 +3,7 @@* Copyright (C) 2007 Oracle. All rights reserved. */ +#include <linux/encoded_io.h> #include <linux/fs.h> #include <linux/pagemap.h> #include <linux/time.h>
@@ -1987,6 +1988,32 @@ static ssize_t btrfs_direct_write(struct kiocb *iocb, struct iov_iter *from)return written ? written : err; } +static ssize_t btrfs_encoded_write (struct kiocb *iocb,struct iov_iter *from) +{ +struct file *file = iocb->ki_filp; +struct inode *inode =file_inode (file); +struct encoded_iov encoded; +ssize_t ret; + + ret =copy_encoded_iov_from_iter (&encoded, from); +if (ret) +return ret; + +btrfs_inode_lock (inode,0 ); + ret =generic_encoded_write_checks (iocb, &encoded); +if (ret || encoded.len ==0 ) + goto out; + + ret =btrfs_write_check (iocb, from, encoded.len); +if (ret <0 ) + goto out; + + ret =btrfs_do_encoded_write (iocb, from, &encoded); +out: +btrfs_inode_unlock (inode,0 ); +return ret; +} +static ssize_t btrfs_file_write_iter (struct kiocb *iocb,struct iov_iter *from) {
@@ -2003,14 +2030,17 @@ static ssize_t btrfs_file_write_iter(struct kiocb *iocb,if (test_bit (BTRFS_FS_STATE_ERROR , &inode->root->fs_info->fs_state))return -EROFS ; -if (!(iocb->ki_flags &IOCB_DIRECT ) && - (iocb->ki_flags &IOCB_NOWAIT )) +if ((iocb->ki_flags &IOCB_NOWAIT ) && + (!(iocb->ki_flags &IOCB_DIRECT ) || + (iocb->ki_flags &IOCB_ENCODED )))return -EOPNOTSUPP ;if (sync)atomic_inc (&inode->sync_writers); -if (iocb->ki_flags &IOCB_DIRECT ) +if (iocb->ki_flags &IOCB_ENCODED ) + num_written =btrfs_encoded_write (iocb, from); +else if (iocb->ki_flags &IOCB_DIRECT ) num_written =btrfs_direct_write (iocb, from);else num_written =btrfs_buffered_write (iocb, from);
@@ -3594,7 +3624,7 @@ static loff_t btrfs_file_llseek(struct file *file, loff_t offset, int whence)static int btrfs_file_open (struct inode *inode,struct file *filp) { - filp->f_mode |=FMODE_NOWAIT |FMODE_BUF_RASYNC ; + filp->f_mode |=FMODE_NOWAIT |FMODE_BUF_RASYNC |FMODE_ENCODED_IO ;return generic_file_open (inode, filp); }
fs/btrfs/inode.c +257 -2
283 lines not on this page · raw message
fs/btrfs/ordered-data.c +9 -3
@@ -464,9 +464,15 @@ void btrfs_remove_ordered_extent(struct btrfs_inode *btrfs_inode,spin_lock (&btrfs_inode->lock);btrfs_mod_outstanding_extents (btrfs_inode,-1 );spin_unlock (&btrfs_inode->lock); -if (root != fs_info->tree_root) -btrfs_delalloc_release_metadata (btrfs_inode, entry->num_bytes, - false); +if (root != fs_info->tree_root) { +u64 release; + +if (test_bit (BTRFS_ORDERED_ENCODED , &entry->flags)) + release = entry->disk_num_bytes; +else + release = entry->num_bytes; +btrfs_delalloc_release_metadata (btrfs_inode, release, false); + }percpu_counter_add_batch (&fs_info->ordered_bytes, -entry->num_bytes, fs_info->delalloc_batch);
fs/btrfs/ordered-data.h +4 -1
@@ -74,6 +74,8 @@ enum {BTRFS_ORDERED_LOGGED_CSUM ,/* We wait for this extent to complete in the current transaction */ BTRFS_ORDERED_PENDING , +/* RWF_ENCODED I/O */ + BTRFS_ORDERED_ENCODED, };/* BTRFS_ORDERED_* flags that specify the type of the extent. */
@@ -81,7 +83,8 @@ enum { (1UL <<BTRFS_ORDERED_NOCOW ) | \ (1UL <<BTRFS_ORDERED_PREALLOC ) | \ (1UL <<BTRFS_ORDERED_COMPRESSED ) | \ - (1UL << BTRFS_ORDERED_DIRECT)) + (1UL <<BTRFS_ORDERED_DIRECT ) | \ + (1UL << BTRFS_ORDERED_ENCODED)) struct btrfs_ordered_extent {/* logical offset in the file */
Signature · 1 line
2.31.1
Quoted 4 lines · Omar Sandoval
Patches 1-3 add the VFS support, UAPI, and documentation. Patches 4-7 are Btrfs prep patches. Patch 8 adds Btrfs encoded read support and patch 9 adds Btrfs encoded write support.
I don't love the RWF_ENCODED flag, but if that's the way people think this should be done, as a model this looks reasonable to me.
I'm not sure what the deal with the encryption metadata is. I realize there is currently only one encryption type ("none") in this series, but it's not clear how any other encryption type would actually ever be described. It's not like you can pass in the key (well, I guess passing in the key would be fine, but passing it back out certainly would not be). A key ID from a keyring?
So there's presumably some future plan for it, but it would be good to verify that that plan makes sense..
Linus
Quoted 16 lines · Linus Torvalds
Quoted 4 lines · Omar Sandoval
Patches 1-3 add the VFS support, UAPI, and documentation. Patches 4-7 are Btrfs prep patches. Patch 8 adds Btrfs encoded read support and patch 9 adds Btrfs encoded write support.
I don't love the
RWF_ENCODEDflag, but if that's the way people think this should be done, as a model this looks reasonable to me.I'm not sure what the deal with the encryption metadata is. I realize there is currently only one encryption type ("none") in this series, but it's not clear how any other encryption type would actually ever be described. It's not like you can pass in the key (well, I guess passing in the key would be fine, but passing it back out certainly would not be). A key ID from a keyring?
Quoted 2 lines
So there's presumably some future plan for it, but it would be good to verify that that plan makes sense..
What I'm imagining for fscrypt is:
1. Add ENCODED_IOV_ENCRYPTION_* types for fscrypt. Consumers at least need to be able to distinguish between encryption policy versions, DIRECT_KEY policies, and IV_INO_LBLK_{64,32} policies, and maybe other details.
2. Use RWF_ENCODED only for the data itself.
3. Add new fscrypt ioctls to get and set the encryption key.
The interesting part is (3). If I'm reading the fscrypt documentation correctly, in the default mode, each file is encrypted with a per-file key that is a function of the master key for the directory tree and a per-file nonce.
Userspace manages the master key, we have a FS_IOC_GET_ENCRYPTION_NONCE ioctl, and the key derivation function is documented. So, userspace already has all of the pieces it needs to get the encryption key, and all of the information it needs to decrypt the data it gets from RWF_ENCODED if it so desires.
On the set/write side, the user can set the same master key and policy with FS_IOC_SET_ENCRYPTION_POLICY, and we'd need something like an FS_IOC_SET_ENCRYPTION_NONCE ioctl (possibly with a requirement that it be set when the file is empty). I think that's it.
The details will vary for the other fscrypt policies, but that's the gist of it. I added the fscrypt maintainers to correct me if I missed something.
Thanks,
Omar
Quoted 40 lines · Omar Sandoval
Quoted 16 lines · Linus Torvalds
Quoted 4 lines · Omar Sandoval
Patches 1-3 add the VFS support, UAPI, and documentation. Patches 4-7 are Btrfs prep patches. Patch 8 adds Btrfs encoded read support and patch 9 adds Btrfs encoded write support.
I don't love the
RWF_ENCODEDflag, but if that's the way people think this should be done, as a model this looks reasonable to me.I'm not sure what the deal with the encryption metadata is. I realize there is currently only one encryption type ("none") in this series, but it's not clear how any other encryption type would actually ever be described. It's not like you can pass in the key (well, I guess passing in the key would be fine, but passing it back out certainly would not be). A key ID from a keyring?
Quoted 2 lines
So there's presumably some future plan for it, but it would be good to verify that that plan makes sense..
What I'm imagining for fscrypt is:
1. Add ENCODED_IOV_ENCRYPTION_* types for fscrypt. Consumers at least need to be able to distinguish between encryption policy versions,
DIRECT_KEYpolicies, and IV_INO_LBLK_{64,32} policies, and maybe other details.
2. UseRWF_ENCODEDonly for the data itself.
3. Add new fscrypt ioctls to get and set the encryption key.The interesting part is (3). If I'm reading the fscrypt documentation correctly, in the default mode, each file is encrypted with a per-file key that is a function of the master key for the directory tree and a per-file nonce.
Userspace manages the master key, we have a
FS_IOC_GET_ENCRYPTION_NONCEioctl, and the key derivation function is documented. So, userspace already has all of the pieces it needs to get the encryption key, and all of the information it needs to decrypt the data it gets fromRWF_ENCODEDif it so desires.
Quoted 9 lines
On the set/write side, the user can set the same master key and policy with
FS_IOC_SET_ENCRYPTION_POLICY, and we'd need something like anFS_IOC_SET_ENCRYPTION_NONCEioctl (possibly with a requirement that it be set when the file is empty). I think that's it.The details will vary for the other fscrypt policies, but that's the gist of it. I added the fscrypt maintainers to correct me if I missed something.
Well, assuming we're talking about regular files only (so file contents encryption, not filenames encryption), with fscrypt the information needed to understand a file's encrypted data is the following:
1. The encryption key
2. The filesystem's block size
3. The encryption context:
struct fscrypt_context_v2 {
u8 version; /* FSCRYPT_CONTEXT_V2 */
u8 contents_encryption_mode;
u8 filenames_encryption_mode;
u8 flags;
u8 __reserved[4];
u8 master_key_identifier[FSCRYPT_KEY_IDENTIFIER_SIZE];
u8 nonce[FSCRYPT_FILE_NONCE_SIZE];
}; (Or alternatively struct fscrypt_policy_v2 + the nonce field separately;
that results in the same fields as struct fscrypt_context_v2.)
This is definitely more complex than the compression cases like "the data is a zlib stream". So the question is, how much of this metadata (if any) should actually be passed around during RWF_ENCODED pread/pwrite operations, and how much should be out-of-band.
I feel like this should be mostly out-of-band (e.g. via the existing ioctls FS_IOC_{GET,SET}_ENCRYPTION_POLICY), especially given that compression and encryption could be combined which would make describing the on-disk data even more difficult.
But I'm not sure what you intended.
- Eric
Quoted 46 lines · Eric Biggers
Quoted 45 lines · Omar Sandoval
Quoted 16 lines · Linus Torvalds
Quoted 4 lines · Omar Sandoval
Patches 1-3 add the VFS support, UAPI, and documentation. Patches 4-7 are Btrfs prep patches. Patch 8 adds Btrfs encoded read support and patch 9 adds Btrfs encoded write support.
I don't love the
RWF_ENCODEDflag, but if that's the way people think this should be done, as a model this looks reasonable to me.I'm not sure what the deal with the encryption metadata is. I realize there is currently only one encryption type ("none") in this series, but it's not clear how any other encryption type would actually ever be described. It's not like you can pass in the key (well, I guess passing in the key would be fine, but passing it back out certainly would not be). A key ID from a keyring?
Quoted 2 lines
So there's presumably some future plan for it, but it would be good to verify that that plan makes sense..
What I'm imagining for fscrypt is:
1. Add ENCODED_IOV_ENCRYPTION_* types for fscrypt. Consumers at least need to be able to distinguish between encryption policy versions,
DIRECT_KEYpolicies, and IV_INO_LBLK_{64,32} policies, and maybe other details.
2. UseRWF_ENCODEDonly for the data itself.
3. Add new fscrypt ioctls to get and set the encryption key.The interesting part is (3). If I'm reading the fscrypt documentation correctly, in the default mode, each file is encrypted with a per-file key that is a function of the master key for the directory tree and a per-file nonce.
Userspace manages the master key, we have a
FS_IOC_GET_ENCRYPTION_NONCEioctl, and the key derivation function is documented. So, userspace already has all of the pieces it needs to get the encryption key, and all of the information it needs to decrypt the data it gets fromRWF_ENCODEDif it so desires.On the set/write side, the user can set the same master key and policy with
FS_IOC_SET_ENCRYPTION_POLICY, and we'd need something like anFS_IOC_SET_ENCRYPTION_NONCEioctl (possibly with a requirement that it be set when the file is empty). I think that's it.
Quoted 7 lines
Quoted 4 lines
The details will vary for the other fscrypt policies, but that's the gist of it. I added the fscrypt maintainers to correct me if I missed something.
Well, assuming we're talking about regular files only (so file contents encryption, not filenames encryption),
Yes, I was thinking of regular files. File operations using encrypted names sounds... interesting, but I think out of scope for this.
Quoted 27 lines
with fscrypt the information needed to understand a file's encrypted data is the following:
1. The encryption key
2. The filesystem's block size
3. The encryption context:
struct fscrypt_context_v2 { u8 version; /* FSCRYPT_CONTEXT_V2 */ u8 contents_encryption_mode; u8 filenames_encryption_mode; u8 flags; u8 __reserved[4]; u8 master_key_identifier[FSCRYPT_KEY_IDENTIFIER_SIZE]; u8 nonce[FSCRYPT_FILE_NONCE_SIZE]; };(Or alternatively struct
fscrypt_policy_v2+ the nonce field separately;
that results in the same fields as structfscrypt_context_v2.)This is definitely more complex than the compression cases like "the data is a zlib stream". So the question is, how much of this metadata (if any) should actually be passed around during
RWF_ENCODEDpread/pwrite operations, and how much should be out-of-band.
Quoted 6 lines
I feel like this should be mostly out-of-band (e.g. via the existing ioctls FS_IOC_{GET,SET}_ENCRYPTION_POLICY), especially given that compression and encryption could be combined which would make describing the on-disk data even more difficult.
But I'm not sure what you intended.
Okay, I think we're in agreement: RWF_ENCODED for the data and separate ioctls for the encryption context. Since the fscrypt policy struct includes all of the relevant information, RWF_ENCODED can probably just have a single ENCODED_IOV_ENCRYPTION_FSCRYPT encryption type. RWF_ENCODED can express data which is both compressed and encrypted, so that should be fine as well.
The only other missing piece that I see (other than filesystem support) is an FS_IOC_SET_ENCRYPTION_NONCE ioctl. Would such an interface be reasonable?
Quoted 11 lines · Omar Sandoval
Okay, I think we're in agreement:
RWF_ENCODEDfor the data and separate ioctls for the encryption context. Since the fscrypt policy struct includes all of the relevant information,RWF_ENCODEDcan probably just have a singleENCODED_IOV_ENCRYPTION_FSCRYPTencryption type.RWF_ENCODEDcan express data which is both compressed and encrypted, so that should be fine as well.The only other missing piece that I see (other than filesystem support) is an
FS_IOC_SET_ENCRYPTION_NONCEioctl. Would such an interface be reasonable?
In theory, it will be possible to add FS_IOC_SET_ENCRYPTION_NONCE. The implementation might be tricky. It would have to take the inode lock, verify that the file is empty, replace the encryption xattr, and re-derive and replace the file's encryption key. Replacing the key should be safe because the file is empty, but it's hard to be sure -- and what about directories? Another concern is that userspace could misuse this ioctl and somehow end up reusing nonces, which would be bad; probably this should be a CAP_SYS_ADMIN thing only.
A larger question is whether the goal is to support users backing up and restoring encrypted files without their encryption key being available -- in which case things would become *much* harder. First because of the filenames encryption, and second because we currently don't allow opening files without their encryption key.
- Eric
Quoted 5 lines · Omar Sandoval
Quoted 2 lines
Well, assuming we're talking about regular files only (so file contents encryption, not filenames encryption),
Yes, I was thinking of regular files. File operations using encrypted names sounds... interesting, but I think out of scope for this.
So the question I have is why would you want to get the raw encrypted data? One possible reason (and this is what Michael Halwcrow and I had tried designing years ago) was so you could backup a device that had multiple users' files without having all of the users' keys --- and then be able to restore them. So for example, suppose you had a tablet that is shared by multiple family members, and you want to be backup all of the data on the shared device so that it could be restored in case one of the kids drop the tablet in the swimming pool....
But in order to do that, you need to be able to restore the encrypted files in the encrypted directories. In practice, encrypted files generally exist in encrypted directories. That's because the typical way fscrypt gets used is we set a policy on an empty directory, and then all of the newly files created files have encrypted file names, inherit the directory's encryption policy, and then have encrypted file contents.
So do you have the encryption key, or not? If you do have the encryption key, then you can ignore the issue of the file name when you open the file, but what's the reason why you would want to extract out the raw encrypted data plus the raw encryption metadata? You're not going to be able to restore the encrypted file, in the encrypted directory name. Perhaps it's because you want to keep the data encrypted while you're tranferring it --- but the filename needs to be encrypted as well, and given modern CPU's, with or without inline-crypto engines, the cost of decrypting the file data and then re-encrypting it in the backup key isn't really that large.
If you don't have the encryption key, then you need to be able to open the file using using the encrypted name (which fscrypt does support) and then extract out the encrypted file name using another bundle of encryption metadata. So that's a bit more complicated, but it's doable.
The *really* hard part is *restoring* an encrypted directory hierarchy. Michael and I did create a straw design proposal (which is too small to fit in the margins of this e-mail :-), but suffice it to say that the standard Posix system calls are not sufficient to be able to create encrypted files and encrypted directories, and it would have been messy as all hell. Which is why we breathed a sign of relief when the original product requirement of being able to do
backup/restore of shared devices went away. :-)
The thing is, though, just being able to extract out regular files in their raw encrypted on-disk form, along with their filename metadata, seems to be a bit of a party trick without a compelling use case that I can see. But perhaps you have something in mind?
- Ted
Quoted 50 lines · Theodore Y. Ts'o
Quoted 5 lines · Omar Sandoval
Quoted 2 lines
Well, assuming we're talking about regular files only (so file contents encryption, not filenames encryption),
Yes, I was thinking of regular files. File operations using encrypted names sounds... interesting, but I think out of scope for this.
So the question I have is why would you want to get the raw encrypted data? One possible reason (and this is what Michael Halwcrow and I had tried designing years ago) was so you could backup a device that had multiple users' files without having all of the users' keys --- and then be able to restore them. So for example, suppose you had a tablet that is shared by multiple family members, and you want to be backup all of the data on the shared device so that it could be restored in case one of the kids drop the tablet in the swimming pool....
But in order to do that, you need to be able to restore the encrypted files in the encrypted directories. In practice, encrypted files generally exist in encrypted directories. That's because the typical way fscrypt gets used is we set a policy on an empty directory, and then all of the newly files created files have encrypted file names, inherit the directory's encryption policy, and then have encrypted file contents.
So do you have the encryption key, or not? If you do have the encryption key, then you can ignore the issue of the file name when you open the file, but what's the reason why you would want to extract out the raw encrypted data plus the raw encryption metadata? You're not going to be able to restore the encrypted file, in the encrypted directory name. Perhaps it's because you want to keep the data encrypted while you're tranferring it --- but the filename needs to be encrypted as well, and given modern CPU's, with or without inline-crypto engines, the cost of decrypting the file data and then re-encrypting it in the backup key isn't really that large.
If you don't have the encryption key, then you need to be able to open the file using using the encrypted name (which fscrypt does support) and then extract out the encrypted file name using another bundle of encryption metadata. So that's a bit more complicated, but it's doable.
The *really* hard part is *restoring* an encrypted directory hierarchy. Michael and I did create a straw design proposal (which is too small to fit in the margins of this e-mail :-), but suffice it to say that the standard Posix system calls are not sufficient to be able to create encrypted files and encrypted directories, and it would have been messy as all hell. Which is why we breathed a sign of relief when the original product requirement of being able to do
backup/restore of shared devices went away. :-)
Quoted 4 lines
The thing is, though, just being able to extract out regular files in their raw encrypted on-disk form, along with their filename metadata, seems to be a bit of a party trick without a compelling use case that I can see. But perhaps you have something in mind?
Thanks for the detailed response, Ted. I personally don't have a use case for reading and writing encrypted data. I only care about skipping compression/decompression, but early on it was pointed out that this API could potentially also be used for encrypted data. The question at this point is: if someone else comes along and solves the problems with restoring encrypted filenames, is this interface enough for them to restore the encrypted file data? It seems like the answer is yes, with a couple of additions to fscrypt. I should've been clearer that I don't have concrete plans to do this, I just wanted to leave the door open for it so that we don't need a second, very similar interface.
Thanks,
Omar
Quoted 10 lines · Omar Sandoval
Thanks for the detailed response, Ted. I personally don't have a use case for reading and writing encrypted data. I only care about skipping compression/decompression, but early on it was pointed out that this API could potentially also be used for encrypted data. The question at this point is: if someone else comes along and solves the problems with restoring encrypted filenames, is this interface enough for them to restore the encrypted file data? It seems like the answer is yes, with a couple of additions to fscrypt. I should've been clearer that I don't have concrete plans to do this, I just wanted to leave the door open for it so that we don't need a second, very similar interface.
Well, practically speaking, we would need to have a way to extract out the encrypted file name information; and given that an encrypted file could have hard links, we need to be able to obtain the encrypted file name information for the dentry that was used to open that file. This arguably should be separate from the encryption information for data stream itself, so if we want to handwave how we fetch the encrypted filename info (maybe some magic ioctl, or maybe via using some kind of magic RWF flag used for reading encrypted directories that are opened via O_DIRECTORY, which sorta-works like readdir() but also returns some additional metadata information for each directory entry), sure it should be possible to use your proposed interface as a starting point.
I'm not sure we want to try to design all of the details of how to get the encrypted data plus encryption metadata for the data stream, but in theory, so long as there is a way to get the encryption metadata, sure, it could work. One other approach is to just abuse the xattr interface, the way we do with Posix ACL's and Capabilities, where the on-disk format and the format used when we query a file's ACL via the xattr interface don't necessary have to be identical. I'm sure that will result in howls of outrage in some quarters, but this is something for which we have a precedent.
Cheers,
- Ted
Quoted 16 lines · Linus Torvalds
Quoted 4 lines · Omar Sandoval
Patches 1-3 add the VFS support, UAPI, and documentation. Patches 4-7 are Btrfs prep patches. Patch 8 adds Btrfs encoded read support and patch 9 adds Btrfs encoded write support.
I don't love the
RWF_ENCODEDflag, but if that's the way people think this should be done, as a model this looks reasonable to me.I'm not sure what the deal with the encryption metadata is. I realize there is currently only one encryption type ("none") in this series, but it's not clear how any other encryption type would actually ever be described. It's not like you can pass in the key (well, I guess passing in the key would be fine, but passing it back out certainly would not be). A key ID from a keyring?
Quoted 2 lines
So there's presumably some future plan for it, but it would be good to verify that that plan makes sense..
To summarize the discussion and answer your original question, using RWF_ENCODED for encryption will require additional support for getting encryption metadata, but that support is best suited for a separate interface, with RWF_ENCODED purely for the encrypted data itself. The harder part of encrypted backups is restoring filenames, and that would also be best as a separate interface.
My use case is only for compression, so none of that is a blocker for RWF_ENCODED.
What else can I do to move this along?
Thanks,
Omar