> -----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
