From: Josef Bacik <josef@redhat.com>
To: Chris Mason <chris.mason@oracle.com>
Cc: Li Zefan <lizf@cn.fujitsu.com>,
linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: [PATCH] Btrfs: use the normal checksumming infrastructure for free space cache
Date: Mon, 13 Jun 2011 10:26:25 -0400 [thread overview]
Message-ID: <4DF61E11.7070702@redhat.com> (raw)
In-Reply-To: <1307974249-sup-2733@shiny>
On 06/13/2011 10:11 AM, Chris Mason wrote:
> Excerpts from Li Zefan's message of 2011-06-12 22:20:43 -0400:
>> Chris Mason wrote:
>>> Excerpts from Li Zefan's message of 2011-06-12 21:52:32 -0400:
>>>> Josef Bacik wrote:
>>>>> We used to store the checksums of the space cache directly in the space cache,
>>>>> however that doesn't work out too well if we have more space than we can fit the
>>>>> checksums into the first page. So instead use the normal checksumming
>>>>> infrastructure. There were problems with doing this originally but those
>>>>> problems don't exist now so this works out fine. Thanks,
>>>>>
>>>>
>>>> This looks great, so I'll drop my patch that extends the original code to
>>>> allow more than 1 crc page.
>>>
>>> I do like them a lot, but what happens when a special case crc kernel
>>> mounts a free space cache created by this patch?
>>>
>>
>> The generation number will be checked, and then we'll get this warning:
>>
>> "btrfs: space cache generation xx does not match inode yy"
>>
>> If xx happens to be equal to yy, crcs will be checked and this warning
>> will pop up:
>>
>> "btrfs: crc mismatch for page zz"
>>
>> but it won't crash (not tested).
>
> Right, but that's a lot of trust to put into our small crcs.
Yeah we're trusting that the crc's or the generation won't match, which
really should be the case always. Unfortunately there is no real way to
force the old kernels to flush the space cache with the new format, we
just have to assume that it will get the wrong checksum, which really it
should. Course now that I've said this some user will hit that one in a
hundred trillion chance that the entries will end up having valid crc's
for the pages. Thanks,
Josef
next prev parent reply other threads:[~2011-06-13 14:26 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-10 19:40 [PATCH] Btrfs: use the normal checksumming infrastructure for free space cache Josef Bacik
2011-06-13 1:52 ` Li Zefan
2011-06-13 1:53 ` Chris Mason
2011-06-13 2:05 ` Li Zefan
2011-06-13 2:10 ` Li Zefan
2011-06-13 2:20 ` Li Zefan
2011-06-13 14:11 ` Chris Mason
2011-06-13 14:26 ` Josef Bacik [this message]
2011-06-13 13:56 ` Josef Bacik
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=4DF61E11.7070702@redhat.com \
--to=josef@redhat.com \
--cc=chris.mason@oracle.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=lizf@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).