Messages in this thread | | | Date | Fri, 15 Jun 2018 11:33:14 -0400 | From | "Theodore Y. Ts'o" <> | Subject | Re: [PATCH] vfs: Support FALLOC_FL_NO_HIDE_STALE flag with fallocate |
| |
On Fri, Jun 15, 2018 at 06:51:08PM +0800, Sig Shen wrote: > FALLOC_FL_NO_HIDE_STALE flag must be set if user want to issue > a discard request for block devices. But vfs_fallocate() will > return with an error -EOPNOTSUPP indicating lack of support > if this flag is set. > > fix it by allowing FALLOC_FL_NO_HIDE_STALE flag in vfs_fallocate > > Fixes: 25f4c41415e5 ("block: implement (some of) fallocate for block devices") > Signed-off-by: Sig Shen <sigshen@synology.com>
The commit description is not quite correct. What the NO_HIDE_STALE flag does is allow a discard request for those block devices which do not have the DISCARD_ZEROES_DATA flag.
I will note that the FALLOC_FL_NO_HIDE_STALE flag is a bit controversial in linux-fsdevel. I have a similar patch in the VFS in Google's internal data center kernel, as well as an internal patch which implements support for this flag in ext4. However, the patches are out of tree, because pretty much all of the file system developers who work for enterpise distributions were against this functionality.
I know of one other major cloud provider (in China) using the functionality as an out-of-tree patch, but with no one else speaking in favor of it, and everyone else NAK'ing the patch and enterprise distro's saying they would revert the patch in their distro kernels, the compromise we came to was that the code point for NO_HIDE_STALE_FL would be reserved so that users of the out-of-tree patches wouldn't collide with future fallocate flags; and I would stop trying to push the patches upstream.
I have no idea how Darrick was able to get commit 25f4c41415e5 upstream, but I guess it was less controversial for block devices than for file systems.
So I'm certainly in favor of this patch landing in mainline, but you should be aware that there may be some opposition to it.
Cheers,
- Ted
| |