[Cluster-devel] GFS2 Patches Needing Review

[Steven Whitehouse <swhiteho@redhat.com>]

Hi,


On 08/06/17 21:20, Bob Peterson wrote:
> Hi,
>
> Here is a list of recent GFS2 patches that I'd like reviewed before I push
> them to the for-next branch:
>
> Bob Peterson:
>
> (1) https://www.redhat.com/archives/cluster-devel/2017-May/msg00116.html
>      26 May 2017 [GFS2 PATCH resend/revised] GFS2: Add new debug trace point and evict code path
That one doesn't use trace points in the right way. Calling it 
gfs2_debug is far too generic a name for something that is specific to 
gfs2_evict() and we should not be using strings like that to label the 
different cases. It also doesn't seem to print out much of interest either.

What would be interesting is a generic tracepoint (or set of 
tracepoints) which can trace the inode lifecycle implemented at the VFS 
level (for race free access to i_state and i_nlink etc.).

> (2) https://www.redhat.com/archives/cluster-devel/2017-May/msg00114.html
>      26 May 2017 [GFS2 PATCH V2] GFS2: Combine func meta_prep_new with its only caller
You could do that, but what is the benefit? I doubt it makes any 
difference to the generated code, and it doesn't seem to be any cleaner 
or easier to read the code either.

> (3) https://www.redhat.com/archives/cluster-devel/2017-May/msg00115.html
>      26 May 2017 [GFS2 PATCH] GFS2: Withdraw when directory entry inconsistencies are detected
Yes, that seems like a reasonable change, for consistency of error handling.

>
> Andreas Gruenbacher:
>
> (4) https://www.redhat.com/archives/cluster-devel/2017-May/msg00117.html
>      31 May 2017 [PATCH 0/8] GFS2 shrinker deadlock
>      (series of 8, revised)
>
> Regards,
>
> Bob Peterson
> Red Hat File Systems
I sent a set of replies to those patches on 1st June, so I assume that 
there should be an updated patch set in due course? You could take the 
first patch in the series anyway though I guess, and wait for updates 
for the other patches in due course,

Steve.