On Sat, May 23, 2020 at 10:31:24PM -0700, Christoph Hellwig wrote: > On Sun, May 24, 2020 at 07:43:34AM +1000, Dave Chinner wrote: > > I've got to rework the error handling code anyway, so I might end up > > getting rid of ->li_error and hard coding these like I've done the > > iodone functions. That way the different objects can use different > > failure mechanisms until the dquot code is converted to the same > > "hold at dirty time" flushing mechanism... > > FYI, while reviewing your series I looked at that area a bit, and > found the (pre-existing) code structure a little weird: > > - xfs_buf_iodone_callback_errorl deals with the buffer itself and > thus should sit in xfs_buf.c, not xfs_buf_item.c > - xfs_buf_do_callbacks_fail really nees to be a buffer level > methods instead of polig into b_li_list, which nothing else in > "common" code does. My though was to either add another method > or overload the b_write_done method to pass the error back to > the buffer owner and let the owner deal with the list iteration > an exact error handling method. No. Just no. Please stop with the "we have to clean up all this irrelevant stuff before we land a feature/bug fix" idiocy already. We do not need to completely rework the way the infrastructure is laid out to fix this problem. That is not a priority for me, nor is it important in any way to solving this problem. This patchset already removes a huge amount of code so it cleans up a lot in the process of fixing the important problem. But the reality is that it also touches many very important areas in the code base and so we need to -minimise- the unnecessary changes in the patchset, not add more to it. The most important thing we need to do here is that we get the change correct. We do not need to completely rewrite how the code is laid out, nor do we need to move hundreds of lines of code form one file to another just to clean up some non-critical code. It's completely unnecessary and irrelevant to fixing the problem the patchset is trying to address. Yes, I will rework the bits needed to fix the problems that have been found, but I'm not going to go and make wholesale changes to the buffer and buffer item IO completion infrastructure because it is *not necessary* to fix the problems. This patchset has been a nightmare so far precisely because of the frequent cleanup patchsets merged in the past couple of months that have caused widespread churn in the codebase. Almost none of these cleanups have done anything other than change the code - most haven't even been necessary for bug fixes to be applied, either. They've just been "change" and that's caused me repeated problems with severe patch conflicts. Code cleanups *are not free*. They might be easy to do and review so there's no big upfront cost to them. The cost to cleanups are in the downstream effects - developer patch sets no longer apply, code is no longer recognisable at a glance to experienced developers, failure modes are different, bugs can be introduced, etc. All of these things add time and resources to the work that other developers not involved in the cleanup process are trying to do. And when the work those developers are trying to address long term problems and are full of complex, subtle interactions and changes? Cleanups that keep overlapping with that work are actively harmful to the process of fixing such problems. The problem here is all these cleanups are reactive patchsets - someone sends a patchset for review, and then immediately the list is filled with cleanup patchsets that hit the exact area of code that the original patchset modified. This is not a one-off incident - over the past few months this has happened almost every time every time someone has posted a substantial feature or bug-fix patchset. So, can we please stop with the "clean up before original patchset lands" reviews and patch postings. If anyone has cleanup patches, please send them out when you do them, not in response to someone else trying to fix a problem. If anyone wants to make significant clean ups around someone elses work as a result of reviewing that code, we need to do it -after- the current patchset has been reviewed and merged. We will still get the code cleanup done, but we need to prioritise the work we do appropriate. i.e. we need to land the important thing first, then worry about the little stuff that isn't critical to addressing the immediate issue. Code cleanups are definitely necessary, but they are most definitely are not the most important thing we need to do... /end rant -- Dave Chinner david@xxxxxxxxxxxxx
