It's very important, several kinds of blocking are done at object granularity. Off the top of my head, large objects would cause deep scrub and recovery to stall requests for longer. Elephant objects would also be able to skew data distribution. -Sam On Mon, May 5, 2014 at 10:38 AM, Jeff Darcy <jdarcy@xxxxxxxxxx> wrote: >> One important caveat is that rados objects should be limited in size >> (4MB for rbd blocks), so you'll want to chunk files somewhere before >> rados. > > OK, that's going to make life interesting. How dire are the results > of not chunking like this? Is it just that the data won't be > distributed across multiple OSDs and therefore you'll only get one > OSD's worth of throughput? Or is it something worse? There might > be a way that we can use the GlusterFS striping translator on top > of the RADOS translator, but since it currently sits one level lower > (still above replication but below distribution) there might be some > issues there. -- 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
