From: Nikolay Borisov <nborisov@suse.com>
To: Anand Jain <anand.jain@oracle.com>, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 4/4 RESEND] btrfs: fix property validate fail should not increment generation
Date: Tue, 2 Apr 2019 16:45:23 +0300 [thread overview]
Message-ID: <e13f6e8f-483e-85f5-e2aa-b0efaf66e621@suse.com> (raw)
In-Reply-To: <20190402100742.8355-6-anand.jain@oracle.com>
On 2.04.19 г. 13:07 ч., Anand Jain wrote:
> When the property fails to pass the prop_handlers::validate() check, the
> thread should exit with no changes in the kernel, but as we are starting
> the transaction too early, we have just updated the generation even if
> there is no change.
>
> For example:
> btrfs prop get /btrfs compression
> compression=lzo
> sync
> btrfs in dump-super /dev/sdb | grep "^generation"
> generation 32
>
> Try to set an incomplete compression type
>
> btrfs prop set /btrfs compression zli
> ERROR: failed to set compression for /btrfs: Invalid argument
> sync
>
> Set failed but generation is incremented
> btrfs in dump-super /dev/sdb | grep "^generation"
> generation 33 <--
>
> Fix it by collapsing btrfs_set_prop_trans() into btrfs_set_prop(), which
> provides flexibility to start the transaction after the
> prop_handlers::validate() has been checked.
>
> As of now if the prop_handlers::apply() fails then we still increment
> the generation, but if there is strong prop_handlers::validate() then
> the prop_handlers::apply() can never fail.
>
> Signed-off-by: Anand Jain <anand.jain@oracle.com>
SO what do we gain by this patch? Whether the transaction generation
number (actually in your changelog it will be an improvement to mention
transaction generation explicitly, because there is also inode
generation...) is incremented or not is an implementation detail. It can
be argued both ways whether it should or shouldn't be incremented? Does
this have to do with how btrfs' log works? I.e the transaction
generation is used to
next prev parent reply other threads:[~2019-04-02 13:45 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-02 10:07 [PATCH 0/4 RESEND] btrfs: fix property bugs Anand Jain
2019-04-02 10:07 ` [PATCH 1/4 RESEND] btrfs: fix zstd compression parameter Anand Jain
2019-04-02 22:09 ` David Sterba
2019-04-02 10:07 ` [PATCH] fstests: btrfs/048: amend property validation cases Anand Jain
2019-04-02 12:51 ` Nikolay Borisov
2019-04-03 0:32 ` Anand Jain
2019-04-02 10:07 ` [PATCH 2/4 RESEND] btrfs: fix vanished compression property after failed set Anand Jain
2019-04-02 13:00 ` Nikolay Borisov
2019-04-02 22:14 ` David Sterba
2019-04-02 10:07 ` [PATCH 3/4 RESEND] btrfs: open code btrfs_set_prop in inherit_prop Anand Jain
2019-04-02 13:35 ` Nikolay Borisov
2019-04-02 21:41 ` David Sterba
2019-04-02 23:24 ` David Sterba
2019-04-03 0:42 ` Anand Jain
2019-04-02 21:41 ` David Sterba
2019-04-02 10:07 ` [PATCH 4/4 RESEND] btrfs: fix property validate fail should not increment generation Anand Jain
2019-04-02 13:45 ` Nikolay Borisov [this message]
2019-04-02 21:13 ` David Sterba
2019-04-02 22:04 ` David Sterba
2019-04-02 23:03 ` Anand Jain
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=e13f6e8f-483e-85f5-e2aa-b0efaf66e621@suse.com \
--to=nborisov@suse.com \
--cc=anand.jain@oracle.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.