On Fri, Feb 14, 2014 at 05:05:13AM -0800, Christoph Hellwig wrote: > (4): add a new flag to blkdev_issue_zeroout to say if deallocating the > blocks is okay, and if yes proceed like (1). > > Requiring blocks to be zeroed, but not wanting to remove the > provisioning seems like a perfectly valid request, especially from > userspace (e.g. databases) That seems reasonable. Should the default be to try to use discard if it is available, or to keep the current behavior? I'm leaning towards defining BLKDEV_ZEROOUT_DISCARD, and changing all of the existing calls to blkdev_issue_zeroout() to pass in 0 for the flags. This implies that if any file system does want to use discard for things like fallocate(), they have to explicitly request it. Which brings up a few additional questions, for which I'd appreciate suggestions/opinons: Should we try to have some kind of informal naming scheme for a mount option so that file systems can explicitly request this behavior, i.e. "mount -o zeroout_discard"? Of course, if we do this, very few people will probably end up using it. So should we try to set up some standard hueristics so that for certain class of devices (such as flash) we default to using zeroout _discard, and for certain other classes of devices (maybe thinp) we don't? Perhaps we should make it be tunable based on the number of blocks that are being discarded, i.e., "mount -o zeroout_discard=128k" means to use the zeroout_discard flag if we are trying to zeroout more than 128k? Also, is it worth creating a new ioctl, BLKZZEROOUT, or perhaps BLKZEROOUTF, which takes a flags argument, so we can expose this to userspace? I'm not sure it is worth it, since at least for e2fsprogs, I won't want to depend on the user using a new enough kernel to support the new ioctl, and while it is a bit painful to query the /sys/block/sdXX/queue/discard_* files, I'm doing it already for other reasons. Cheers, - Ted -- 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
