When reading file blocks, the ..._get_range call should be snapshot; we don't have any obligation to return a specific version of the blocks, and don't want to conflict with writes. Though we might end up conflicting on the inode, if we're updating access times. At a minimum the snapshot read will produce one less conflict range to send & check. (Tiny optimization? Yes)
Similarly when performing a write, we should produce a single write range conflict covering all possibly affected blocks, instead of the maybe 3 conflicts we'd currently produce (start block, middle range clear, stop block). Again, tiny optimization, slightly fewer ranges to send over the wire, and fewer for the resolver to check.
When reading file blocks, the
..._get_rangecall should be snapshot; we don't have any obligation to return a specific version of the blocks, and don't want to conflict with writes. Though we might end up conflicting on the inode, if we're updating access times. At a minimum the snapshot read will produce one less conflict range to send & check. (Tiny optimization? Yes)Similarly when performing a write, we should produce a single write range conflict covering all possibly affected blocks, instead of the maybe 3 conflicts we'd currently produce (start block, middle range clear, stop block). Again, tiny optimization, slightly fewer ranges to send over the wire, and fewer for the resolver to check.