From: Jeff Layton <firstname.lastname@example.org>
To: Linus Torvalds <email@example.com>,
David Howells <firstname.lastname@example.org>
Cc: Matthew Wilcox <email@example.com>,
David Wysochanski <firstname.lastname@example.org>,
Anna Schumaker <email@example.com>,
Trond Myklebust <firstname.lastname@example.org>,
Steve French <email@example.com>,
Dominique Martinet <firstname.lastname@example.org>,
Alexander Viro <email@example.com>,
firstname.lastname@example.org, CIFS <email@example.com>,
"open list:NFS, SUNRPC, AND..." <firstname.lastname@example.org>,
Linux Kernel Mailing List <email@example.com>
Subject: Re: [GIT PULL] fscache: I/O API modernisation and netfs helper library
Date: Tue, 09 Feb 2021 14:45:51 -0500 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
On Tue, 2021-02-09 at 11:06 -0800, Linus Torvalds wrote:
> So I'm looking at this early, because I have more time now than I will
> have during the merge window, and honestly, your pull requests have
> been problematic in the past.
> The PG_fscache bit waiting functions are completely crazy. The comment
> about "this will wake up others" is actively wrong, and the waiting
> function looks insane, because you're mixing the two names for
> "fscache" which makes the code look totally incomprehensible. Why
> would we wait for PF_fscache, when PG_private_2 was set? Yes, I know
> why, but the code looks entirely nonsensical.
> So just looking at the support infrastructure changes, I get a big "Hmm".
> But the thing that makes me go "No, I won't pull this", is that it has
> all the same hallmark signs of trouble that I've complained about
> before: I see absolutely zero sign of "this has more developers
> There's not a single ack from a VM person for the VM changes. There's
> no sign that this isn't yet another "David Howells went off alone and
> did something that absolutely nobody else cared about".
> See my problem? I need to be convinced that this makes sense outside
> of your world, and it's not yet another thing that will cause problems
> down the line because nobody else really ever used it or cared about
> it until we hit a snag.
I (and several other developers) have been working with David on this
for the last year or so. Would it help if I gave this on the netfs lib
work and the fscache patches?
Reviewed-and-tested-by: Jeff Layton <email@example.com>
My testing has mainly been with ceph. My main interest is that this
allows us to drop a fairly significant chunk of rather nasty code from
fs/ceph. The netfs read helper infrastructure makes a _lot_ more sense
for a networked filesystem, IMO.
The legacy fscache code has some significant bugs too, and this gives it
a path to making better use of more modern kernel features. It should
also be set up so that filesystems can be converted piecemeal.
I'd really like to see this go in.
next prev parent reply other threads:[~2021-02-09 19:57 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-09 16:09 [GIT PULL] fscache: I/O API modernisation and netfs helper library David Howells
2021-02-09 19:06 ` Linus Torvalds
2021-02-09 19:45 ` Jeff Layton [this message]
2021-02-09 20:21 ` Matthew Wilcox
2021-02-09 21:19 ` Linus Torvalds
2021-02-09 21:55 ` David Howells
2021-02-10 16:36 ` David Howells
2021-02-09 21:25 ` David Howells
2021-02-09 22:42 ` David Wysochanski
2021-02-09 21:10 ` David Howells
2021-02-10 16:29 ` David Howells
2021-02-10 16:33 ` David Howells
2021-02-10 20:43 ` Linus Torvalds
2021-02-11 22:38 ` David Howells
2021-02-11 23:20 ` David Howells
2021-02-12 16:40 ` David Wysochanski
2021-02-13 1:05 ` Linus Torvalds
2021-02-15 0:22 ` David Howells
2021-02-15 1:01 ` Linus Torvalds
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.