From: David Sterba <dsterba@suse.cz>
To: Boris Burkov <boris@bur.io>
Cc: linux-btrfs@vger.kernel.org, linux-fscrypt@vger.kernel.org,
kernel-team@fb.com
Subject: Re: [PATCH v4 2/5] btrfs: initial fsverity support
Date: Wed, 12 May 2021 19:34:23 +0200 [thread overview]
Message-ID: <20210512173423.GU7604@twin.jikos.cz> (raw)
In-Reply-To: <dd0cfc38c6de927de63f34f96499dc8f80398754.1620241221.git.boris@bur.io>
On Wed, May 05, 2021 at 12:20:40PM -0700, Boris Burkov wrote:
> +/*
> + * Insert and write inode items with a given key type and offset.
> + * @inode: The inode to insert for.
> + * @key_type: The key type to insert.
> + * @offset: The item offset to insert at.
> + * @src: Source data to write.
> + * @len: Length of source data to write.
> + *
> + * Write len bytes from src into items of up to 1k length.
> + * The inserted items will have key <ino, key_type, offset + off> where
> + * off is consecutively increasing from 0 up to the last item ending at
> + * offset + len.
> + *
> + * Returns 0 on success and a negative error code on failure.
> + */
> +static int write_key_bytes(struct btrfs_inode *inode, u8 key_type, u64 offset,
> + const char *src, u64 len)
> +{
> + struct btrfs_trans_handle *trans;
> + struct btrfs_path *path;
> + struct btrfs_root *root = inode->root;
> + struct extent_buffer *leaf;
> + struct btrfs_key key;
> + u64 copied = 0;
> + unsigned long copy_bytes;
> + unsigned long src_offset = 0;
> + void *data;
> + int ret;
> +
> + path = btrfs_alloc_path();
> + if (!path)
> + return -ENOMEM;
> +
> + while (len > 0) {
> + trans = btrfs_start_transaction(root, 1);
This starts transaction for each 1K of written data, this can become
potentially slow. In btrfs_end_enable_verity it's called 3 times and
then there's another transaction started to set the VERITY bit on the
inode. There's no commit called so it's not forced but it could happen
at any time independently. So this could result in partial verity data
stored.
We can't use join_transaction, or not without some block reserve magic.
> + if (IS_ERR(trans)) {
> + ret = PTR_ERR(trans);
> + break;
> + }
> +
> + key.objectid = btrfs_ino(inode);
> + key.offset = offset;
> + key.type = key_type;
> +
> + /*
> + * insert 1K at a time mostly to be friendly for smaller
> + * leaf size filesystems
> + */
> + copy_bytes = min_t(u64, len, 1024);
The smallest we consider is 4K, I'm not sure if we would do eg. 2K to
allow testing the subpage blocksize even on x86_64. Otherwise I'd target
4K and adjust the limits accordingly. To reduce the transaction start
count, eg. 2K per round could half the number.
> +
> + ret = btrfs_insert_empty_item(trans, root, path, &key, copy_bytes);
> + if (ret) {
Does this also need to abort the transaction? This could lead to
filesystem in some incomplete state. If the whole operation is
restartable then it could avoid the abort and just return error, but
also must undo all changes. This is not always possible so aborting is
the only option left.
> + btrfs_end_transaction(trans);
> + break;
> + }
> +
> + leaf = path->nodes[0];
> +
> + data = btrfs_item_ptr(leaf, path->slots[0], void);
> + write_extent_buffer(leaf, src + src_offset,
> + (unsigned long)data, copy_bytes);
> + offset += copy_bytes;
> + src_offset += copy_bytes;
> + len -= copy_bytes;
> + copied += copy_bytes;
> +
> + btrfs_release_path(path);
> + btrfs_end_transaction(trans);
> + }
> +
> + btrfs_free_path(path);
> + return ret;
> +}
next prev parent reply other threads:[~2021-05-12 18:38 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1620241221.git.boris@bur.io>
2021-05-05 19:20 ` [PATCH v4 1/5] btrfs: add compat_flags to btrfs_inode_item Boris Burkov
2021-05-11 19:11 ` David Sterba
2021-05-17 21:48 ` David Sterba
2021-05-19 21:45 ` Boris Burkov
2021-06-07 21:43 ` David Sterba
2021-05-25 18:12 ` Eric Biggers
2021-06-07 21:10 ` David Sterba
2021-05-05 19:20 ` [PATCH v4 2/5] btrfs: initial fsverity support Boris Burkov
2021-05-06 0:09 ` kernel test robot
2021-05-11 19:20 ` David Sterba
2021-05-11 20:31 ` David Sterba
2021-05-11 21:52 ` Boris Burkov
2021-05-12 17:10 ` David Sterba
2021-05-13 19:19 ` Boris Burkov
2021-05-17 21:40 ` David Sterba
2021-05-12 17:34 ` David Sterba [this message]
2021-05-05 19:20 ` [PATCH v4 3/5] btrfs: check verity for reads of inline extents and holes Boris Burkov
2021-05-12 17:57 ` David Sterba
2021-05-12 18:25 ` Boris Burkov
2021-05-05 19:20 ` [PATCH v4 4/5] btrfs: fallback to buffered io for verity files Boris Burkov
2021-05-05 19:20 ` [PATCH v4 5/5] btrfs: verity metadata orphan items Boris Burkov
2021-05-12 17:48 ` David Sterba
2021-05-12 18:08 ` Boris Burkov
2021-05-12 23:36 ` David Sterba
2021-05-05 19:20 [PATCH v4 0/5] btrfs: support fsverity Boris Burkov
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=20210512173423.GU7604@twin.jikos.cz \
--to=dsterba@suse.cz \
--cc=boris@bur.io \
--cc=kernel-team@fb.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fscrypt@vger.kernel.org \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox