How does FileStore handle this case? Why are we doing anything different? > -----Original Message----- > From: ceph-devel-owner@xxxxxxxxxxxxxxx [mailto:ceph-devel- > owner@xxxxxxxxxxxxxxx] On Behalf Of Igor Fedotov > Sent: Monday, June 20, 2016 6:57 AM > To: Sage Weil <sweil@xxxxxxxxxx> > Cc: ceph-devel <ceph-devel@xxxxxxxxxxxxxxx> > Subject: Re: zero length write fro store_test to bluestore > > > > On 20.06.2016 16:55, Sage Weil wrote: > > On Mon, 20 Jun 2016, Igor Fedotov wrote: > >> Hi All, > >> > >> I'm hitting the following issue while running Synthetic test case > >> (from > >> store_test.cc) against bluestore: > >> > >> store_test asserts on read data mismatch when read happens after the > >> zero-length write above object boundary. > >> > >> Test case assumes all the data between the old and new object > >> boundaries are filled with zeros. But current bluestore write path > >> implementation simply discards zero-length writes and hence doesn't > >> raise object size. As a result subsequent read doesn't return anything > above the old boundary. > >> > >> The question is what's the proper fix for that: > >> > >> 1) Ignore zero-length writes in the test case and do not increase > >> object size/fill content on them. > >> > >> or > >> > >> 2) Increase object content size on such writes in the bluestore. > > Heh, I just hit this too. I think it makes more sense for 0 length > > writes to not affect object size. I added a test for it and fixed > > Memstore. store_test.cc needs to be adjusted still though... > > > > Pushed patches to top of wip-bluestore-2q, do you mind pulling those 2 > > out and fixing store_test in another PR? > OK, will do. > > > > 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 -- 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
