From: Boris Burkov <boris@bur.io>
To: dsterba@suse.cz, Josef Bacik <josef@toxicpanda.com>,
linux-btrfs@vger.kernel.org, kernel-team@fb.com
Subject: Re: [PATCH 2/4] btrfs: use sb state to print space_cache mount option
Date: Mon, 21 Sep 2020 10:13:17 -0700 [thread overview]
Message-ID: <20200921171317.GA4045720@devvm842.ftw2.facebook.com> (raw)
In-Reply-To: <20200921170405.GL6756@twin.jikos.cz>
On Mon, Sep 21, 2020 at 07:04:05PM +0200, David Sterba wrote:
> On Mon, Sep 21, 2020 at 10:50:25AM -0400, Josef Bacik wrote:
> > On 9/17/20 2:13 PM, Boris Burkov wrote:
> > > To make the contents of /proc/mounts better match the actual state of
> > > the file system, base the display of the space cache mount options off
> > > the contents of the super block rather than the last mount options
> > > passed in. Since there are many scenarios where the mount will ignore a
> > > space cache option, simply showing the passed in option is misleading.
> > >
> > > For example, if we mount with -o remount,space_cache=v2 on a read-write
> > > file system without an existing free space tree, we won't build a free
> > > space tree, but /proc/mounts will read space_cache=v2 (until we mount
> > > again and it goes away)
> > >
> > > There is already mount logic based on the super block's cache_generation
> > > and free space tree flag that helps decide a consistent setting for the
> > > space cache options, so we just bring those further to the fore. For
> > > free space tree, the flag is already consistent, so we just switch mount
> > > option display to use it. cache_generation is not always reliably set
> > > correctly, so we ensure that cache_generation > 0 iff the file system
> > > is using space_cache v1. This requires committing a transaction on any
> > > mount which changes whether we are using v1. (v1->nospace_cache, v1->v2,
> > > nospace_cache->v1, v2->v1).
> > >
> > > References: https://github.com/btrfs/btrfs-todo/issues/5
> > > Signed-off-by: Boris Burkov <boris@bur.io>
> >
> > Dave already took this, but next time I'd prefer if we'd keep logical changes
> > separate. So one patch to change /proc/mounts, one patch to deal with clearing
> > the free space generation field if we're not using it.
>
> I haven't taken it yet, adding branches to for-next is only to get test
> coverage, by 'taken' you can count addig it to misc-next.
Would you guys like me to split it up? I felt it was worth keeping the
two changes together because changing the mount options without clearing
the generation will break /proc/mounts in cases that currently work OK.
e.g., I believe it will never show space_cache=v2 if you have the
space_cache if look at generation, and the generation has ever been set.
next prev parent reply other threads:[~2020-09-21 17:20 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-17 18:13 [PATCH v3 0/4] btrfs: free space tree mounting fixes Boris Burkov
2020-09-17 18:13 ` [PATCH v3 1/4] btrfs: support remount of ro fs with free space tree Boris Burkov
2020-09-21 14:35 ` Josef Bacik
2020-09-24 17:02 ` David Sterba
2020-09-17 18:13 ` [PATCH 2/4] btrfs: use sb state to print space_cache mount option Boris Burkov
2020-09-21 14:50 ` Josef Bacik
2020-09-21 17:04 ` David Sterba
2020-09-21 17:13 ` Boris Burkov [this message]
2020-09-24 17:04 ` David Sterba
2020-09-17 18:13 ` [PATCH v3 3/4] btrfs: remove free space items when creating free space tree Boris Burkov
2020-09-21 14:54 ` Josef Bacik
2020-09-21 17:13 ` David Sterba
2020-09-21 18:22 ` Boris Burkov
2020-09-21 19:01 ` Josef Bacik
2020-09-24 17:07 ` David Sterba
2020-09-17 18:13 ` [PATCH 4/4] btrfs: skip space_cache v1 setup when not using it Boris Burkov
2020-09-21 14:54 ` Josef Bacik
2020-09-18 14:23 ` [PATCH v3 0/4] btrfs: free space tree mounting fixes David Sterba
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=20200921171317.GA4045720@devvm842.ftw2.facebook.com \
--to=boris@bur.io \
--cc=dsterba@suse.cz \
--cc=josef@toxicpanda.com \
--cc=kernel-team@fb.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.