RE: Cache Layer on NVME driver

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

 



On Wed, 18 May 2016, Jianjian Huo wrote:
> On Wed, May 18, 2016 at 10:19 AM, Sage Weil <sage@xxxxxxxxxxxx> wrote:
> >
> > Hi Rajath!
> >
> > Great to hear you're interested in working with us outside of GSoC!
> >
> > On Wed, 18 May 2016, Haomai Wang wrote:
> > > Hi Rajath,
> > >
> > > We are glad to see your passion, from my view, sage is planning to
> > > implement a userspace cache in bluestore itself. Like
> > > (https://github.com/ceph/ceph/commit/b9ac31afe5a162176f019baa25348014a77f6ab8#commitcomment-17488250).
> > >
> > > I guess the cache won't be a generic cache interface. Instead it will
> > > be bound to specified needed object. So sage may give a brief?
> >
> > Part of the reason why this project wasn't at the top of our list (we got
> > fewer slots than we had projects) was because the BlueStore code is in
> > flux and moving quite quickly.  For the BlueStore side, we are building a
> > simple buffer cache that is tied to an Onode (in-memory per-object
> > metadata structure) and integrated tightly with the read and write IO
> > paths.  This will eliminate our use of the block device buffer cache for
> > user/object data.
> >
> > The other half of the picture, though, is the BlueFS layer that is
> > consumed by rocksdb: it also needs caching in order for rocksdb to perform
> > at all.  My hope is that the code we write for the use data can be re-used
> > here as well, but it is still evolving.
> 
> When Bluestore moves away from kernel cache to its own buffer cache, RocksDB can use its own buffer cache as well. 
> RocksDB has this size configurable block cache to cache uncompressed data blocks, it can serve as buffer cache, 
> since Bluestore don't compress meta data in RocksDB.

What options control this?  I was having trouble finding it the last time 
I looked.  We should switch it now (and use unbuffered IO from BlueFS) if 
we can.

Thanks!
sage
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [CEPH Users]     [Ceph Large]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux