RE: Metadata vs UserData caching in BlueStore

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

 



I don't think Kernel is caching anything as we are using O_DIRECT writes.
I think for random there is no point of caching data but for sequential if we are planning to implement read_ahead in bluestore , data cache should help.

Thanks & Regards
Somnath

-----Original Message-----
From: ceph-devel-owner@xxxxxxxxxxxxxxx [mailto:ceph-devel-owner@xxxxxxxxxxxxxxx] On Behalf Of Igor Fedotov
Sent: Thursday, December 15, 2016 9:45 AM
To: Mark Nelson; ceph-devel
Subject: Re: Metadata vs UserData caching in BlueStore

On 15.12.2016 20:34, Mark Nelson wrote:
>
>
> On 12/15/2016 11:24 AM, Igor Fedotov wrote:
>> Sage et al,
>>
>> shouldn't we have bluestore_cache_metadata_ratio set to 1 by default?
>> To concentrate on metadata caching..
>
> I would contend that it should be high (we've already bumped it up,
> I'd go higher still), but isn't 1 a little excessive? Ultimately this
> should all be automatic based on heuristics imho.
>
Well, Mark - what's the use case for user data caching? It means that user either retrieves just written data or reads them repeatedly or in an unaligned manner. Or there are multiple users working with the same object.
Any of that is IMHO a corner case... That can be handled by using that ratio setting if needed.

>>
>> IMHO Onode caching is much more important and profitable than user
>> data one. It's rather a client misbehavior to cause cache hit when
>> accessing user data but it's  highly expected for onode metadata.
>
> We should take care not to run into the same problem the kernel does.
> With too many cached entries things can get slow.  It's another
> trade-off we need to watch out for.  There may need to be a (hopefully
> automatically generated) soft limit, and potentially a hard limit.
Doesn't our cache size limit server that purpose?
>
>>
>> Moreover user data caching is probably already exists at block device
>> level hence we rather duplicate disk cache....
>>
>> What do you think?
>>
>> Thanks,
>>
>> Igor
>>
>> --
>> 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

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

________________________________

PLEASE NOTE: The information contained in this electronic mail message is intended only for the use of the designated recipient(s) named above. If the reader of this message is not the intended recipient, you are hereby notified that you have received this message in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify the sender by telephone or e-mail (as shown above) immediately and destroy any and all copies of this message in your possession (whether hard copies or electronically stored copies).

��.n��������+%������w��{.n����z��u���ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f




[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