Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

Dave Chinner
2016-03-03T22:57:19Z

On Thu, Mar 03, 2016 at 01:54:54PM -0500, Martin K. Petersen wrote:
> >>>>> "Christoph" == Christoph Hellwig <hch@infradead.org> 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@fromorbit.com