On Wed, Jan 30, 2019 at 2:53 PM Jason Dillaman <jdillama@xxxxxxxxxx> wrote:
>
> Should we try to ensure that librbd and krbd have (semi) matching
> discard behavior? In librbd, a full object discard on an overlapping
> child will truncate the child object to size zero instead of issuing a
> delete. With this krbd change, if a child object had previously been
> written and now was discarded, the parent data will become visible
> again since the child object is deleted. This could be prevented by
Right, this is what librbd was doing until about a year ago when
I fixed the parent data exposure with a compound create+truncate.
> issuing a "assert_exists" + "truncate(0)" op to prevent the implicit
> zeroing of a full object extent if it was never written and would
> prevent the parent data from becoming visible again after a discard.
truncate on a non-existent object is a no-op, so I'm not sure how
assert_exists+truncate(0) is different from plain truncate(0).
> Obviously the data is still consistent either way but it would be good
> to match.
I thought about this, but decided to drop reverse mapping and overlap
calculation code from rbd_obj_setup_discard() simply because it would
have been semi-matching at best. It also seems clearer to me: in the
zeroout case we worry about copyups and parent blocks, in the discard
case we don't. Special casing whole-object discards felt like mixing
them up without a good reason.
Thanks,
Ilya
