RE: How important is bcache cache device in write-thru mode? (was Re: Tiered bcache)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> -----Original Message-----
> From: linux-bcache-owner@xxxxxxxxxxxxxxx [mailto:linux-bcache-
> owner@xxxxxxxxxxxxxxx] On Behalf Of matthew patton
> Sent: mardi 21 janvier 2014 18:35
> To: linux-bcache@xxxxxxxxxxxxxxx
> Cc: Patrick Zwahlen
> Subject: How important is bcache cache device in write-thru mode? (was
> Re: Tiered bcache)
> 
> >>  wait, the cache DEVICE for bcache is a Btier device composed of an
> SSD
> 
> >>  and RAM? So in effect you want btier to move the really hot blocks
> >>  within the bcache cache device into RAM? So effectively bcache
> metadata
> >>  and any really hot blocks will live in RAM and the rest of the
> > 'read'
> >>  cache will sit on the SSD.
> >
> > Exactly! Apologies if that wasn't clear in the first place but that
> > describes 100% what we're currently testing.
> 
> 
> you REALLY want to check with Kent as to what happens when the bcache
> caching device (and any meta-data it stores there) routinely get blown
> away or run a high risk of experiencing sudden destruction. I'm afraid
> this is not a test case that has undergone enough scrutiny.

Thanks Matthew for raising this in this list.

I should add that we have two SAN servers sharing the JBOD. Clustering is
managed by pacemaker. During normal operations, we can migrate a whole RAID
from one node to the other and we do a proper cache detach on node #1 (that
would even write dirty data if were doing write-back) and re-attach the RAID
to the existing cache on the node #2. Beauty here is we can "share" a cache
set between multiple backend devices.

We made the assumption that as bcache is designed for potentially failing
SSDs, moving to a potentially failing SSD+RAM shouldn't make a difference. 

I'm definitely not expert enough to assess the risk any further and I rely
on you guys.

- Patrick -

Attachment: smime.p7s
Description: S/MIME cryptographic signature


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux ARM Kernel]     [Linux Filesystem Development]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux