> -----Original Message----- > From: Dr. Greg Wettstein [mailto:greg@xxxxxxxxxxxxxxxxx] > Sent: mardi 28 janvier 2014 15:20 > To: Patrick Zwahlen; linux-bcache@xxxxxxxxxxxxxxx > Cc: scst-devel@xxxxxxxxxxxxxxxxxxxxx > Subject: RE: How important is bcache cache device in write-thru mode? > (was Re: Tiered bcache) > > Interestingly enough we have been working on infrastructure to support > this type of model for some time. Our primary focus is on > accelerating SCST based storage targets and software defined storage > (SDS) devices. > > At one point in time we had entertained discussions with the SCST > developers to pay for an implementation of RAM based block device > cacheing in SCST itself, for a variety of reasons that didn't move > forward. We recognized early on that Kent's work with bcache was > going to make that strategy irrelevant. > > SCST using FILEIO is blindingly fast but I don't know of any serious > storage architects that are going to trust 50-60 gigabytes of a > database or filesystem to the Linux pagecache and associated vagaries > of VM writeback behavior. So the architectural question becomes how > to take advantage of the fact that it is now tractable to provision > commodity based storage targets with a quarter terrabyte of RAM and > how to take advantage of this in a manner which protects data and > provides deterministic performance characteristics. > > So Izzy (our golden retriever) and I spent a lot of time down at our > lake place over the holidays cross-country skiing and working on a > hugepage backed block device driver. We are in the process of putting > the beta through various beatings and addressing some issues with the > device model implementation. We are hoping to have something to > release in the next week or so before we leave for Colorado and some > downhill skiing. > > The goal for this driver is a block based interface to RAM for use as > a cache set for bcache. Since it sits directly on the physical > hugepage allocator and associated page magazine the block devices can > be dynamically configured, unlike the current RAM based block device, > which also has the disadvantage of being implemented on top of page > cache. None of this should be construed as a gripe against the Linux > VM but obviously one does not want memory pressure to start driving a > high speed cache store out onto disk. Our initial idea with btier and bcache was to use both SSD and DRAM. I understand that you focus on DRAM only. However, I also understand that at some point we might be able to mix several cachesets so we can dream of a kind of tiered cache implemented entirely within bcache. > > This model is obviously dependent on solid behavior of bcache in > write-through mode. We are testing aggressively against 3.10.x and > haven't tipped it over it but we will turn up the pressure on that and > see if it gives. I'm pretty confident there is enough community and > commercial interest in all this to get the bugs beaten out pretty > thoroughly, provided people report them back.... :-) > > We will copy both the bcache and SCST lists when we have something up > on the FTP site as it would seem to be of interest to both > communities. Regards, - Patrick -
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
