From: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
To: "Holger Hoffstätte" <holger@applied-asynchrony.com>,
dsterba@suse.cz, linux-btrfs@vger.kernel.org,
quwenruo@cn.fujitsu.com, osandov@fb.com
Subject: Re: Status of free-space-tree feature
Date: Wed, 21 Sep 2016 08:12:51 -0400 [thread overview]
Message-ID: <85fb7ee0-7f6a-e8a0-46c6-dac12c3e69d2@gmail.com> (raw)
In-Reply-To: <57E2602C.7050703@applied-asynchrony.com>
On 2016-09-21 06:25, Holger Hoffstätte wrote:
> On 09/21/16 11:24, David Sterba wrote:
>> Hi,
>>
>> as you might have noticed, the [1] wiki Status page lists the
>> free-space-tree as 'Unstable', referencing a problem with the bitmap
>> endianity. This will affect only bigendian systems.
>>
>> There's one more problem that I overlooked but was pointed to by Omar
>> recently. The initial FST support in btrfs-progs is read-only,
>>
>> https://marc.info/?l=linux-btrfs&m=144113538017042
>>
>> "However, we're not adding the FREE_SPACE_TREE read-only compat bit to
>> the set of supported bits because progs doesn't know how to keep the
>> free space tree consistent."
>>
>> Historically, the initial patchset version did not recognize FST feature
>> and thus refused to write, but then it was pointed by Qu and Holger that
>> the compat_ro bit is missing for FST. I've added it but this was a
>> mistake. This change is going to be reverted.
>
> I'm not sure I understand - can you explain why this is was so wrong?
> Or Omar maybe?
>
> If btrfsck wants to correct something (write), it can simply always
> and unconditionally invalidate the fst instead of trying to "repair"
> it..and I think that's what happens at the moment (at least I think
> it did for me recently). That seems like a safe and simple way.
I know this is what it does with the regular FSC, but I'm not sure if it
does so with the FST. If it doesn't, it probably should though.
>
> The fst by itself seems to be working really well even in extreme
> scenarios (Stefan Priebe's 50+ TB filesystems come to mind, which fell
> over on a regular basis before I merged the fst into my "stable++"
> kernels), and considering how many bugs we've seen in the past from
> the v1 cache, I was really hoping that we can make v2 the default
> soon instead of skirting around the issue even longer.
I entirely agree regarding this. I've not tested it on anywhere near
that scale, but I've been running it since shortly after support was
present in both stable kernels and userspace, and I've not seen a single
issue on any of my systems except for the aforementioned big endian
issue (which hasn't really affected me that much, since all my big
endian systems are test VM's anyway).
>
> Of course if there are plain old runtime bugs in the fst then they need
> to be considered, but this seems to be about btrfs-progs support.
next prev parent reply other threads:[~2016-09-21 12:12 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-21 9:24 Status of free-space-tree feature David Sterba
2016-09-21 10:25 ` Holger Hoffstätte
2016-09-21 12:12 ` Austin S. Hemmelgarn [this message]
2016-09-21 20:31 ` Omar Sandoval
2016-09-22 8:52 ` David Sterba
2016-09-22 10:10 ` Hans van Kranenburg
2016-09-22 17:26 ` Omar Sandoval
2016-09-22 17:47 ` ojab
2016-09-22 17:50 ` Omar Sandoval
2016-09-22 17:02 ` Omar Sandoval
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=85fb7ee0-7f6a-e8a0-46c6-dac12c3e69d2@gmail.com \
--to=ahferroin7@gmail.com \
--cc=dsterba@suse.cz \
--cc=holger@applied-asynchrony.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=osandov@fb.com \
--cc=quwenruo@cn.fujitsu.com \
/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).