Re: [f2fs-dev] [PATCH v2] f2fs: another way to set large folio by remembering inode number

[Jaegeuk Kim <jaegeuk@kernel.org>]

On 05/22, Theodore Tso wrote:
> On Fri, May 22, 2026 at 03:32:39AM +0000, Jaegeuk Kim wrote:
> > I went this route because Android heavily restricts ioctl() permissions
> > and we needed broader access for this to work within the framework. It’s
> > definitely a pragmatic choice just to get it running in production.
> > 
> > If ioctl() is a right way for upstream, I'm happy to change this patch. By
> > the way, I really don't understand why all the messages are so offensive,
> > even without trying to understand the problem or guiding right directions.
> 
> The reason why some people were getting annoyed was because as a Linux
> file system maintainer, there was an assumption that you would
> understand that extended attributes --- especially in the user.*
> namespace --- have an intended use case of storing a user-chosen small
> piece of metadata that would be stored in the file system.
> 
> Hijacking user.fadvise such that it no longer persistent stores an
> extended attribute for one specific file system --- such that if a
> hypothetical user application might decide to store a piece of
> application data in the extended attribute named "fadvise" would do
> something completely different on a single mainline file system is in
> such poor taste that I would have *hoped* that any Linux file system
> maintainer would know that this a Really Bad Thing, such that if
> someone in your development community suggested such an idea, you
> would reject it.

Thank you for the explanation. It seems I made a wrong assumption on the
usage of "user." prefix where each filesystem can support in different
ways.

> 
> And then, when people complained that it was a bad idea, and you
> decided to put in the f2fs branch, such that it would show up in
> linux-next, and there was no way for other file system developers to
> object (short of appealing to Linus) --- well, that's basically you
> taking advantage of your file system maintainer privileges.  And this
> is why I started proposing whether we needed to appeal this to Linus
> so he could make the call to reject something that the community had
> already told you was in terrible, terrible taste.

To be fair, I hadn't queued it in linux-next for weeks since the first
post, and was waiting for more feedbacks. If I was able to hear "user."
is a generic prefix used for all filesystems and use ioctl from the beginning,
I'd just drop and be able to start arguing with security folks back. Since
my employer is funding for production mainly, not much upstream work, I
couldn't sit and wait for the response for months. :(

> 
> As far as trying to understand why you were doing this --- I have to
> turn that question around.  Why didn't *you* explain why you needed to
> do this thing?  I went through the e-mail history, and I couldn't find
> an explanation of why you decided to do this thing.  

I shared some motivation when replying to Darrick's feedback [1], but yes,
it was not enough for all heads-up. The problem started that some speicific
application needs as many high-order pages as possible mostly for reads. So,
I thought we can turn on large folio on the specific files per hints. One way
for the hints was using immutable bit, but it turned out it's very hard to
manage disabling the bit whenever deleting the files. Along with limited
ioctl() and requiring inode eviction to manage large folio activation, I had
to implement this path.

[1] https://lore.kernel.org/lkml/aeA5C8byIpXWla7f@google.com/

> 
> Perhaps we need to add an explanation the Documentation directory
> explaining what the intended use of the extended attribute case, and
> perhaps referencing past cases were people tried to use this to bypass
> the linux-api review process (f2fs's user.fadvise is not the first
> time someone has tried to do this) thing), so that automated review
> bots like Sashiko can explain why it's in such terrible taste to patch
> authors, perhaps we need to do this.  Up until now, I think the
> assumption is that file system maintainers would know something this
> self-evident, and if not, if it was pointed out, they wouldn't try to
> force such an ill-advised interface to Linus.

I believe this helps a lot to all newbies like me.

I really appreciate your feedback.

> 
> 						- Ted
> 
> P.S.  As an exmaple of how I hanlded a somewhat similar scenario in
> the past, my employer's cluster file system needed
> FALLOC_FL_NO_HIDE_STALE to save $$$$ in TCO storage costs.  But the
> concern was this would be an attractive nuisance for enterprise distro
> users, who would see the massive performance increase, not realize
> that this would leak stale data, which could result in user PII being
> exposed, thus making life hard for Enterprise Linux's reputation.
> (This wasn't an issue at $WORK because we enrypt all data at rest, and
> the cluster file system daemon was a privileged server who (a) knew
> what it was doing, and (b) only it would have access to set
> FALLOC_FL_NO_HIDE_STALE.)
> 
> I disclosed *why* $WORK needed such a thing (it made a huge difference
> to storage TCO costss for Google's Cluster Filesystem), and after
> discussion and negotiation, we came to a compromise which involved my
> keeping the (very small) patch out of tree, but reserving the code
> point upstream to avoid future bitfield collisions.  They key here was
> that I *knew* it was controversial, and I understood what problems it
> might cause in the rest of the ecosystem.  That's part of the job of a
> maintainer, and it's also why a company might want to hire a
> maintainer.  They can represent the needs of multiple stakeholders ---
> the upstream community, upstream users and the greater Linux
> ecosystem, as well as their employer.
> 
> 
> _______________________________________________
> Linux-f2fs-devel mailing list
> Linux-f2fs-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel