On Wed, Sep 9, 2015 at 11:22 AM, HEWLETT, Paul (Paul)
<paul.hewlett@xxxxxxxxxxxxxxxxxx> wrote:
> By setting a parameter osd_max_write_size to 2047Š
> This normally defaults to 90
>
> Setting to 2048 exposes a bug in Ceph where signed overflow occurs...
>
> Part of the problem is my expectations. Ilya pointed out that one can use
> libradosstriper to stripe a large object over many OSD¹s. I expected this
> to happen automatically for any object > osd_max_write_size (=90MB) but it
> does not. Instead one has to set special attributes to trigger striping.
>
> Additionally interaction with erasure coding is unclear - apparently the
> error is reached when the total file size exceeds the limit - if EC is
> enabled then maybe a better solution would be to test the size of the
> chunk written to the OSD which will be only part of the total file size.
> Or do I have that wrong?
That limit is from before EC times and it's a request size limit, as in
"reject any write requests bigger than that with EMSGSIZE". The
primary OSD sees the entire write, so the fact that the request may be
split into EC chunks later down the road is irrelevant.
>
> If EC is being used then would the individual chunks after splitting the
> file then be erasure coded ? I.e if we decide to split a large file into 5
> striped chunks does ceph then EC the individual chunks?
What libradosstriper is doing is slicing your huge object into smaller
objects. Such an object is then treated as any other "normal" object
would be - if there is EC involved, it'll get get split into chunks,
additional erasure chunks will be computed, etc. EC is handled in
librados, and libradosstriper is just some code that sits on top of
librados. So I think the answer is yes.
Thanks,
Ilya
_______________________________________________
ceph-users mailing list
ceph-users@xxxxxxxxxxxxxx
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
