Re: benefit of using stripingv2

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

 



On Thu, Sep 17, 2015 at 7:55 AM, Corin Langosch
<corin.langosch@xxxxxxxxxxx> wrote:
> Hi Greg,
>
> Am 17.09.2015 um 16:42 schrieb Gregory Farnum:
>> Briefly, if you do a lot of small direct IOs (for instance, a database
>> journal) then striping lets you send each sequential write to a
>> separate object. This means they don't pile up behind each other
>> grabbing write locks and can complete in parallel. Striping them
>> instead of just having small block-sized objects means the objects are
>> still of a reasonable size for RADOS.
>>
>
> Sounds good - why not enabled it always/ by default? Is the only drawback
> that there's no support by kernel rbd? What's the recommended stripe size
> for "normal" qemu workloads? 64k?

If you're doing large streaming writes then having to split them up
across multiple objects is slower. It's just a knob you can twirl
depending on the workload of the machine using this disk.

>
>> I *think* that's just because the features are only filled in if
>> they're in use (the kernel doesn't/didn't support striping, despite
>> supporting other V2 image features) and required to understand the
>> image, but maybe I'm misunderstanding you or forgetting how the RBD
>> team set things up.
>
> That doesn't seem to be the case. When I use librbd direcly (for example
> using ceph-ruby) the feature is immediately visible, just as all other
> features.

Dunno then, Josh or Jason maybe?
_______________________________________________
ceph-users mailing list
ceph-users@xxxxxxxxxxxxxx
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com



[Index of Archives]     [Information on CEPH]     [Linux Filesystem Development]     [Ceph Development]     [Ceph Large]     [Ceph Dev]     [Linux USB Development]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [xfs]


  Powered by Linux