public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Sig Shen <sigshen@synology.com>
Cc: Philippe Ombredanne <pombredanne@nexb.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Kate Stewart <kstewart@linuxfoundation.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] vfs: Support FALLOC_FL_NO_HIDE_STALE flag with fallocate
Date: Fri, 15 Jun 2018 11:33:14 -0400	[thread overview]
Message-ID: <20180615153314.GA19476@thunk.org> (raw)
In-Reply-To: <1529059871-11971-1-git-send-email-sigshen@synology.com>

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

      reply	other threads:[~2018-06-15 15:33 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-15 10:51 [PATCH] vfs: Support FALLOC_FL_NO_HIDE_STALE flag with fallocate Sig Shen
2018-06-15 15:33 ` Theodore Y. Ts'o [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180615153314.GA19476@thunk.org \
    --to=tytso@mit.edu \
    --cc=gregkh@linuxfoundation.org \
    --cc=kstewart@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pombredanne@nexb.com \
    --cc=sigshen@synology.com \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox