Re: [PATCH RFC] block: use discard if possible in blkdev_issue_discard()

quoted

quoted

quoted

quoted

"Ted" == Theodore Ts'o [off-list ref] writes:

Ted> Ultimately the storage device (or host OS) can always decide to
Ted> deprovision the space if it is given a write of all zeroes; there's
Ted> nothing in the specs that say anything at all about performance
Ted> considerations, or what the back-end storage decides to do in order
Ted> to handle a particular write command, so long as a subsequent read
Ted> returns the correct data.

Well, that has changed a bit with the logical block provisioning bits in
SCSI. That's why I brought up the allocation/deallocation assumptions in
the existing two blkdev_issue_foo() calls.

Ted> Does that make sense?

Yeah. So deprovision with guaranteed zero on read is what you're
after. I'll chew on that a bit tomorrow.

Ted> What does "anchored" mean?  Does is it the equivalent of using
Ted> fallocate() to allocate the block, but it's marked uninitialized so
Ted> any attempt to read it returns zeroes?

It means that any allocations internal to the storage device which are
required to subsequently perform a write to that block have been
made. So it's a way to reserve space without actually writing the
blocks. Whether reading an anchored block returns zeroes or something
else depends on the usual twisted maze of conflicting and confusing
flags.

-- 
Martin K. Petersen	Oracle Linux Engineering