On Thu, Mar 03, 2016 at 10:09:24AM -0800, Christoph Hellwig wrote: > On Thu, Mar 03, 2016 at 01:01:11PM -0500, Martin K. Petersen wrote: > > That's not entirely true. Writing the blocks may cause them to be > > allocated on the storage device (depending on which flags we feed it in > > WRITE SAME). > > > > The filesystems people were wanted the following semantics: > > > > - deallocate, don't care about contents for future reads (discard) > > - deallocate, guarantee zeroes on future reads (zeroout) > > - (re)allocate, guarantee zeroes on future reads (zeroout) > > > > Maybe we just need a better naming scheme... > > In filesystem terms we have two and three: > > - FALLOC_FL_PUNCH_HOLE assures zeroes are returned, but space is > deallocated as much as possible > - FALLOC_FL_ZERO_RANGE assures zeroes are returned, AND blocks are > actually allocated > > Returning stale blocks in a file system is a nasty security risk, so > we don't do that, and so shouldn't storage that offers any kind > of multi tenancy, and if it's just VMs using multiple partitions on it. Any particular reason why we can't just implement those two fallocate flags for block devices? --D -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
