On Mon, 4 Apr 2016, Haomai Wang wrote: > Hi sage, > > I have a few questions regards to bluestore want to confirm from > design view, I mean some cases is true for current kerneldevice impl, > but it doesn't required by BlueStore(upper layer): > > 1. Two IOContext need to share data for buffer ops? and what about > read_buffered. like: > > IOContext a, b; > bdev->aio_write(a, 0, 100, true) > bdev->read(b, 0, 100, true) > bdev->read_buffered(0, 100) > > b could read data from another "a" which haven't call bdev->flush(). > or this overlap case is guard by BlueStore already? b can read a only if a's IO completed. bdev->flush() is only needed for persistence/durability (it triggers any hardware-specific flush that is needed). > 2. Is it possible exists single IOContext overlap ops? like: > > IOContext a; > bdev->aio_write(a, 0, 100, true) > bdev->read(a, 0, 50, true) > > OR > IOContext a; > bdev->aio_write(a, 0, 100, false) > bdev->read(a, 0, 50, false) > > read op need to aware of the inflight write ops from the same > IOContext? or bluestore will prevent this? The OSD prevents it (see ObcLockManager and ObjectContext::RWState::State). BlueStore doesn't do anything.. if you submit racing reads and writes at the ObjectStore layer the result is undefined. The main read/write issue BlueStore needs to worry about is Onode::flush(), which waits for any pending WAL work to complete. 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
