From: Chris Mason <chris.mason@oracle.com>
To: Li Zefan <lizf@cn.fujitsu.com>
Cc: Josef Bacik <josef@redhat.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:11:17 -0400 [thread overview]
Message-ID: <1307974249-sup-2733@shiny> (raw)
In-Reply-To: <4DF573FB.1080709@cn.fujitsu.com>
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.
-chris
next prev parent reply other threads:[~2011-06-13 14:11 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 [this message]
2011-06-13 14:26 ` Josef Bacik
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=1307974249-sup-2733@shiny \
--to=chris.mason@oracle.com \
--cc=josef@redhat.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 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.