On Mon, 21 Jan 2019 08:58:22 -0500, Jason Dillaman wrote: > > Indeed, the users of REQ_NONUMAP are ioctl() and fallocate(), so the > > only > > practical value which comes to mind is performance (preallocate zeroed > > blocks and format any fs, etc) and possible secure-erase. After some > > internal discussions about performance of writing zeroes (instead of > > true DISCARD) this seems does not bring any value, at least on > > bluestore, > > but secure wipe can make sense (for example using blkdiscard --zerouut). Another possible use case could be space reservations for thin (over) provisioned storage. E.g. I don't have anything to write now, but want to make sure that the array won't reject writes to this region in future. > The zeroed writes would need to be smaller than the bluestore min > alloc size for that to work. Otherwise, bluestore will just allocate a > new blob extent, write zeroes to it, and pivot the object metadata to > point to the new allocation. I think we'll need some form of only-ack-when-the-previous-data-is-gone guarantee from bluestore in future, at least if we want to work towards supporting things like REQ_OP_SECURE_ERASE on the client side. Cheers, David
