On Tue, Feb 9, 2021 at 2:07 PM Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> 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 > involved". > > 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". > I care about it. I cannot speak to your concerns about the infrastructure changes, nor can I comment about a given maintainers involvement or lack thereof. However, I can tell you what my involvement has been. I got involved with it because some of our customers use fscache with NFS and I've supported it. I saw dhowells rewriting it to greatly simplify the code and make it easier to debug and wanted to support the effort. I have been working on the NFS conversion as dhowells has been evolving the fscache-iter API. David first posted the series I think in Dec 2019 and I started with NFS about mid-year 2020, and had my first post of NFS patches in July: https://marc.info/?l=linux-nfs&m=159482591232752&w=2 One thing that came out of the earlier iterations as a result of my testing was the need for the network filesystem to be able to 'cap' the IO size based on its parameters, hence the "clamp_length()" function. So the next iteration dhowells further evolved it into a 'netfs' API and a 'fscache' API, and my November post was based on that: https://marc.info/?l=linux-nfs&m=160596540022461&w=2 Each iteration has greatly simplified the interface to the network filesystem until today where the API is pretty simple. I have done extensive tests with each iteration with all the main NFS versions, specific unit tests, xfstests, etc. However my test matrix did not hit enough fscache + pNFS servers, and I found a problem too late to include in his pull request. This is mostly why my patches were not included to convert NFS to the new fscache API, but I intend to work out the remaining issues for the next merge window, and I'll have an opportunity to do more testing last week of Feb with the NFS "remote bakeathon". My most recent post was at the end of Jan, and Anna is taking the first 5 refactoring patches in the next merge window: https://marc.info/?l=linux-nfs&m=161184595127618&w=2 I do not have the skills of a Trond or Anna NFS developers, but I have worked in this in earnest and intend to see it through to completion and support NFS and fscache work. I have received some feedback on the NFS patches though it's not been a lot, I do know I have some things to address still. With open source, no feedback is hard to draw conclusions other than it's not "super popular" area, but we always knew that about fscache - it's an "add on" that some customers require but not everyone. I know Trond speaks up when I make a mistake and/or something will cause a problem, so I consider the silence mostly a positive sign. > 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. > > Linus >
