On Sun, Feb 14, 2021 at 4:23 PM David Howells wrote:
>
> Anyway, I have posted my fscache modernisation patches multiple times for
> public review, I have tried to involve the wider community in aspects of the
> development on public mailing lists and I have been including the maintainers
> in
Linus Torvalds wrote:
> But no, it's not a replacement for actual code review after the fact.
>
> If you think email has too long latency for review, and can't use
> public mailing lists and cc the people who are maintainers, then I
> simply don't want your patches.
I think we were talking at
On Thu, Feb 11, 2021 at 3:21 PM David Howells wrote:
>
> Most of the development discussion took place on IRC and waving snippets of
> code about in pastebin rather than email - the latency of email is just too
> high. There's not a great deal I can do about that now as I haven't kept IRC
>
On Thu, Feb 11, 2021 at 6:20 PM David Howells wrote:
>
> Linus Torvalds wrote:
>
> > Also, honestly, I really *REALLY* want your commit messages to talk
> > about who has been cc'd, who has been part of development, and point
> > to the PUBLIC MAILING LISTS WHERE THAT DISCUSSION WAS TAKING
Linus Torvalds wrote:
> Also, honestly, I really *REALLY* want your commit messages to talk
> about who has been cc'd, who has been part of development, and point
> to the PUBLIC MAILING LISTS WHERE THAT DISCUSSION WAS TAKING PLACE, so
> that I can actually see that "yes, other people were
Linus Torvalds wrote:
> ...
> IOW, I'm not against "wait_on_page_fscache()" as a function, but I
> *am* against the odd _mixing_ of things without a big explanation,
> where the code itself looks very odd and questionable.
>
> And I think the "fscache" waiting functions should not be visible to
On Wed, Feb 10, 2021 at 8:33 AM David Howells wrote:
>
> Then I could follow it up with this patch here, moving towards dropping the
> PG_fscache alias for the new API.
So I don't mind the alias per se, but I did mind the odd mixing of
names for the same thing.
So I think your change to make it
Linus Torvalds wrote:
> Does the code not hold a refcount already?
The attached patch will do that. Note that it's currently based on top of the
patch that drops the PG_fscache alias, so it refers to PG_private_2.
I've run all three patches through xfstests over afs, both with and without a
> Linus Torvalds wrote:
>
> > 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
Linus Torvalds wrote:
> 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.
On Tue, Feb 9, 2021 at 2:07 PM 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
On Tue, Feb 9, 2021 at 12:21 PM Matthew Wilcox wrote:
>
> Yeah, I have trouble with the private2 vs fscache bit too. I've been
> trying to persuade David that he doesn't actually need an fscache
> bit at all; he can just increment the page's refcount to prevent it
> from being freed while he
Matthew Wilcox wrote:
> Yeah, I have trouble with the private2 vs fscache bit too. I've been
> trying to persuade David that he doesn't actually need an fscache
> bit at all; he can just increment the page's refcount to prevent it
> from being freed while he writes data to the cache.
That's
Linus Torvalds wrote:
> > Yeah, I have trouble with the private2 vs fscache bit too. I've been
> > trying to persuade David that he doesn't actually need an fscache
> > bit at all; he can just increment the page's refcount to prevent it
> > from being freed while he writes data to the cache.
>
Linus Torvalds wrote:
> The PG_fscache bit waiting functions are completely crazy. The comment
> about "this will wake up others" is actively wrong,
You mean this?
/**
* unlock_page_fscache - Unlock a page pinned with PG_fscache
* @page: The page
*
* Unlocks the page and wakes up sleepers
On Tue, Feb 09, 2021 at 11:06:41AM -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.
Thanks for looking at this early.
> The PG_fscache bit
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.
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
Hi Linus,
Can you pull this during the upcoming merge window? It provides a more
modern I/O API for fscache and moves some common pieces out of network
filesystems into a common helper library. This request only includes
modifications for afs and ceph.
Dave Wysochanski has a patch series for
19 matches
Mail list logo
