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. Absolutely in agreement here. it would be much nicer if filesystems could just call bdev->ops->fallocate(PUNCH_HOLE, off, len) and bdev->ops->fallocate(ZERO_RANGE, off, len) than all the weird "technology specific" blkdev_issue_foo() functions we have grown over time. Let the block device implement them as it sees fit - the higher levels don't need to care about protocol/technology details. --- FWIW, this reminds me of a "bigger picture" I think we should be working towards. Does anyone remember this: https://lwn.net/Articles/592091/ (Splitting filesytems in two) i.e. if we add fallocate support to punch holes, zero ranges and *allocate blocks* to a block device, we're mostly at the point where we can offload all freespace management that the filesystem currently does to the underlying block device. There's really only a small extension we'd need - the block allocation done by the block device needs to be able to return the the sector and length of the newly allocated extent. Indeed, this is something we talked about last year at LSFMM as a solution to the SMR write ordering problem: https://lwn.net/Articles/637035/ (near the end, paragraph talking about a "new kind of write command") That "new kind of write command" would enable delayed allocation algorithms to continue to work at the filesystem level on block devices that freespace management completely is offloaded to... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
