From: Gabriel de Perthuis <g2p.code@gmail.com>
To: linux-bcache@vger.kernel.org
Subject: Re: Moving a backing device between 2 cachesets
Date: Wed, 29 Jan 2014 10:42:13 +0000 (UTC) [thread overview]
Message-ID: <lcalu5$iek$1@ger.gmane.org> (raw)
In-Reply-To: 338c5bf03af2422ab712a3552c981390@navex1.navixia.local
On Tue, 28 Jan 2014 21:59:02 +0000, Patrick Zwahlen wrote:
> Hi,
>
> We're working on a 2-nodes pacemaker cluster that provides iSCSI LUNs via
> SCST. The LUNs are either software RAID arrays located in a shared JBOD, or
> DRBD ressources (active/passive).
>
> We are adding bcache to the game with local SSDs (ie not shared, but
> dedicated to each cluster node).
>
> We are using write-through.
>
> I need to evaluate the risk when moving a backing device (md) from cacheset1
> (on node #1) to cacheset2 (on node #2) and then back to cacheset #1.
>
> Scenario
> - md attached to cacheset1 and working (on node 1)
> - md detached from cacheset1
> - md stopped on node 1
> - md started on node 2
> - md attached to cacheset2 on node 2
>
> At this point, cacheset1 is attached to nothing, but still has valid blocks
> "linked" to the backing md device
From bcache.h:
When you register a newly formatted backing device it'll come up
in passthrough mode, and then you can attach and detach a backing device from
a cache set at runtime - while it's mounted and in use. Detaching implicitly
invalidates any cached data for that backing device.
After flushing, detaching does two things:
- the backing device gets flagged as detached
- the backing device is removed from the cache set's metadata
(stored as uuid_entry in a special bucket; the entry is flagged
with a bogus uuid but not reused). The offset in that uuids
array constitutes an id, local to the cache set, that is not
reused after detaching.
The second step invalidates the backing device's id in the cache set,
and indirectly invalidates all buckets that referenced it (through
bkey->inode in the bucket key).
> - md detached from cacheset2
> - md stopped on node 2
> - md started on node 1
> - md RE-attached to cacheset1 on node 1
>
> At this point, I need to make sure that bcache will not serve "old" blocks
> that were linked to the backing device.
>
> My understanding is that as we have attached the backing device to a new
> cacheset (#2) in-between, this will be "recorded" in the bcache headers and
> all the blocks that used to be valid in the first place won't be served.
>
> Can you please validate if this is safe or if we need to take special care
> about invalidating the original cacheset ?
> Thanks a lot, - Patrick -
next prev parent reply other threads:[~2014-01-29 10:42 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-28 21:59 Moving a backing device between 2 cachesets Patrick Zwahlen
2014-01-28 22:35 ` matthew patton
2014-01-29 7:49 ` Patrick Zwahlen
2014-01-29 10:42 ` Gabriel de Perthuis [this message]
2014-01-29 15:55 ` Patrick Zwahlen
2014-01-29 17:50 ` matthew patton
2014-01-29 18:07 ` Patrick Zwahlen
2014-01-29 18:42 ` matthew patton
[not found] ` < lcalu5$iek$1@ger.gmane.org>
[not found] ` <56b62eb646f94bbe868ae6b2f26d94e8@navex1. navixia.local>
2014-01-29 17:01 ` Gabriel de Perthuis
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='lcalu5$iek$1@ger.gmane.org' \
--to=g2p.code@gmail.com \
--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.