From: David Sterba <dsterba@suse.cz>
To: fdmanana@kernel.org
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH v3 2/2] Btrfs: fix ENOSPC errors, leading to transaction aborts, when cloning extents
Date: Wed, 24 Jul 2019 16:30:31 +0200 [thread overview]
Message-ID: <20190724143031.GO2868@twin.jikos.cz> (raw)
In-Reply-To: <20190705100950.14917-1-fdmanana@kernel.org>
On Fri, Jul 05, 2019 at 11:09:50AM +0100, fdmanana@kernel.org wrote:
> From: Filipe Manana <fdmanana@suse.com>
>
> When cloning extents (or deduplicating) we create a transaction with a
> space reservation that considers we will drop or update a single file
> extent item of the destination inode (that we modify a single leaf). That
> is fine for the vast majority of scenarios, however it might happen that
> we need to drop many file extent items, and adjust at most two file extent
> items, in the destination root, which can span multiple leafs. This will
> lead to either the call to btrfs_drop_extents() to fail with ENOSPC or
> the subsequent calls to btrfs_insert_empty_item() or btrfs_update_inode()
> (called through clone_finish_inode_update()) to fail with ENOSPC. Such
> failure results in a transaction abort, leaving the filesystem in a
> read-only mode.
>
> In order to fix this we need to follow the same approach as the hole
> punching code, where we create a local reservation with 1 unit and keep
> ending and starting transactions, after balancing the btree inode,
> when __btrfs_drop_extents() returns ENOSPC. So fix this by making the
> extent cloning call calls the recently added btrfs_punch_hole_range()
> helper, which is what does the mentioned work for hole punching, and
> make sure whenever we drop extent items in a transaction, we also add a
> replacing file extent item, to avoid corruption (a hole) if after ending
> a transaction and before starting a new one, the old transaction gets
> committed and a power failure happens before we finish cloning.
>
> A test case for fstests follows soon.
>
> Reported-by: David Goodwin <david@codepoets.co.uk>
> Link: https://lore.kernel.org/linux-btrfs/a4a4cf31-9cf4-e52c-1f86-c62d336c9cd1@codepoets.co.uk/
> Reported-by: Sam Tygier <sam@tygier.co.uk>
> Link: https://lore.kernel.org/linux-btrfs/82aace9f-a1e3-1f0b-055f-3ea75f7a41a0@tygier.co.uk/
> Fixes: b6f3409b2197e8f ("Btrfs: reserve sufficient space for ioctl clone")
> Signed-off-by: Filipe Manana <fdmanana@suse.com>
Added to misc-next (some time ago), thanks.
prev parent reply other threads:[~2019-07-24 14:29 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-27 17:00 [PATCH 2/2] Btrfs: fix ENOSPC errors, leading to transaction aborts, when cloning extents fdmanana
2019-06-28 22:11 ` [PATCH v2 " fdmanana
2019-07-05 10:09 ` [PATCH v3 " fdmanana
2019-07-24 14:30 ` David Sterba [this message]
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=20190724143031.GO2868@twin.jikos.cz \
--to=dsterba@suse.cz \
--cc=fdmanana@kernel.org \
--cc=linux-btrfs@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;
as well as URLs for NNTP newsgroup(s).