All of lore.kernel.org
 help / color / mirror / Atom feed
From: 杨东升 <dongsheng.yang@easystack.cn>
To: 杨东升 <dongsheng.yang@easystack.cn>
Cc: colyli <colyli@suse.de>, linux-bcache <linux-bcache@vger.kernel.org>
Subject: Re:Fw:About bcache-check
Date: Wed, 16 Sep 2020 14:41:21 +0800 (GMT+08:00)	[thread overview]
Message-ID: <AD6A1QD4E21lMp*RygLTOari.3.1600238481257.Hmail.dongsheng.yang@easystack.cn> (raw)
In-Reply-To: <AMsATAA4E*Dlrpq6fL0rxqqL.8.1600237186053.Hmail.dongsheng.yang@easystack.cn>

Hi Coly,

    Hmm, after a second thought, this problem sounds cant happen in the discard disabled reason:
because the seq is a random number, 

get_random_bytes(&i->seq, sizeof(uint64_t));

So it's not possible to get a same random seq in last invalidated bucket and the new bucket. 
But what about the power-cut case?

Yang




发件人:"杨东升" <dongsheng.yang@easystack.cn>
发送日期:2020-09-16 14:19:46
收件人:colyli <colyli@suse.de>
抄送人:linux-bcache <linux-bcache@vger.kernel.org>
主题:Fw:About bcache-check>Resending with no HTML format  ... ...
>
>
>Hi Coly and all,
>     I found there is an error message in our testing:
>
>
>Sep 27 17:43:00 node-1 kernel: bcache: error on 
>c2914b7e-d665-4ec1-80e1-272755de19ef: unsupported bset version at bucket
> 58290, block 0, 40818810 keys, disabling caching
>
>
>I checked the code in bch_btree_node_read_done() around this message:
>
> 214         for (;
> 215              b->written < btree_blocks(b) && i->seq == b->keys.set[0].data->seq;
> 216              i = write_block(b)) {
> 217                 err = "unsupported bset version";
> 218                 if (i->version > BCACHE_BSET_VERSION)
> 219                         goto err;
> 220 
>The problem is we found the i->seq is what we expected for this btree_node, but the version is not BCACHE_BSET_VERSION (1)
>
>
>
>I think there would be two reasons to cause this messages:
>(1) cache discard is not enabled.
>      When we allocate a bucket, if we dont enable discard, there could be some outdated data in this bucket, 
>
>and there is possibility that the location of i->seq is equal to what we expected,
>
>but that's really not an bset at all, so we will found version, magic and bset_csum are all unexpected, 
>
>currently we will goto err and stop cache_set.
>
>
>(2) power-cut.
>       When we are doing btree_node_write, if there is a power-cut happen, we could write a partial btree.
> 
>
>But when we meet this kind of problems, we cant use this cache device. There is no tool to recovery from this kind of problem.
>
>I think I can cook a bcache-check in bcache-tools, something like fsck. to check this kind of problem
>
>and allow user to repair it, warning on user force-repaire is risky.
>
>
>
>Please help to point out if there is something I am missing. 
>
>
>
>Thanx
>Dongsheng
>
>
>



      reply	other threads:[~2020-09-16  6:41 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-16  6:19 Fw:About bcache-check 杨东升
2020-09-16  6:41 ` 杨东升 [this message]

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='AD6A1QD4E21lMp*RygLTOari.3.1600238481257.Hmail.dongsheng.yang@easystack.cn' \
    --to=dongsheng.yang@easystack.cn \
    --cc=colyli@suse.de \
    --cc=linux-bcache@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.