On Thu, Mar 03, 2016 at 01:54:54PM -0500, Martin K. Petersen wrote: > >>>>> "Christoph" == Christoph Hellwig <hch@xxxxxxxxxxxxx> writes: > > Christoph> - FALLOC_FL_PUNCH_HOLE assures zeroes are returned, but > Christoph> space is deallocated as much as possible - > Christoph> FALLOC_FL_ZERO_RANGE assures zeroes are returned, AND blocks > Christoph> are actually allocated > > That works for me. I think it would be great if we could have consistent > interfaces for fs and block. The more commonality the merrier. So a question I have is do we want to add a "discard-as-a-hint" analog for fallocate? In the past we've said no because we don't trust userspace. (We seem to have as a core held belief that application programmers are idiots and are not to be trusted with anything dangerous, even if it would be highly useful in certain use cases.) As a result I'm carrying an out-of-tree patch in our Google kernels so that ext4 will honor BLKDISCARD on files. I can't remember if I floated it on linux-fsdevel, or I didn't bother because I knew it would instantly shot down. I believe it was the former, but I can't be 100% sure. It would be kind of nice, though, if we had some kind of agreement on a consistent, unified interface for all three kinds of "discard-as-a-hint", "zeroout", and "zeroout with deallocation" that worked on block devices and files. Whether it's via fallocate(2) or BLK* ioctls, I'm agnostic. - Ted P.S. Speaking of things that are powerful and too dangerous for application programmers, after the Linux FAST workshop, I was having dinner with the Ceph developers and Ric Wheeler, and we were talking about things they really needed. Turns out they also could use an FALLOC_FL_NO_HIDE_STALE functionality. I told them I had an out-of-tree patch that had that functionality, and even Ric Wheeler started getting tempted.... :-) -- 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
