Thread (18 messages) 18 messages, 3 authors, 2021-03-24

Re: [PATCH 2/7] repair: Protect bad inode list with mutex

From: Dave Chinner <david@fromorbit.com>
Date: 2021-03-19 22:21:54

On Fri, Mar 19, 2021 at 11:20:11AM -0700, Darrick J. Wong wrote:
On Fri, Mar 19, 2021 at 12:33:50PM +1100, Dave Chinner wrote:
quoted
From: Dave Chinner <redacted>

To enable phase 6 parallelisation, we need to protect the bad inode
list from concurrent modification and/or access. Wrap it with a
mutex and clean up the nasty typedefs.

Signed-off-by: Dave Chinner <redacted>
Reviewed-by: Darrick J. Wong <redacted>
FWIW, if you (Gao at this point, I surmise) want to dig deeper into the
comment that Christoph made during the last review of this patchset,
repair already /does/ have a resizing array structure in repair/slab.c.
Put it in another patchset, please.

Everyone, can we please get out of the habit of asking for extra
cleanups to be done as a condition for getting a change
merged just because the patchset makes a change to slightly crufty
but perfectly working code?

Cleaning up this code is not necessary for this patchset to achieve
it's goals or make forwards progress. Yes, the code that locking is
being added to is slightly crusty, but it is not broken nor is
showing up on profiles as being a performance, scalability or memory
usage limiting factor. Changing the algorithm of this code is
therefore unnecessary to acheive the goals of this patchset.

IOWs, put this aside this cleanup as future work on a rainy day
when we have fixed all the bigger scalability problems and have
nothing better to do.

"If it ain't broke, don't fix it."

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help