Re: [Cluster-devel] [PATCH] gfs2: time journal recovery steps accurately

- Original Message - > This patch spits out the time taken by the various steps in the > journal recover process. Previously, the journal recovery time > didn't account for finding the journal head in the log which takes > up a significant portion of time. > > Signed-off-by: Abhi Das

Re: [Cluster-devel] [PATCH v2 0/2] gfs2: Stop using rhashtable_walk_peek

On Thu, Mar 29, 2018 at 06:52:34PM +0200, Andreas Gruenbacher wrote: > > Should rhashtable_walk_peek be kept around even if there are no more > users? I have my doubts. Absolutely. All netlink dumps using rhashtable_walk_next are buggy and need to switch over to rhashtable_walk_peek. As

[Cluster-devel] [PATCH] gfs2: time journal recovery steps accurately

This patch spits out the time taken by the various steps in the journal recover process. Previously, the journal recovery time didn't account for finding the journal head in the log which takes up a significant portion of time. Signed-off-by: Abhi Das --- fs/gfs2/recovery.c |

Re: [Cluster-devel] [PATCH v2 0/2] gfs2: Stop using rhashtable_walk_peek

On 29 March 2018 at 17:41, Herbert Xu wrote: > On Thu, Mar 29, 2018 at 03:15:54PM +0200, Andreas Gruenbacher wrote: >> >> For all I know, Neil's latest plan is to get rhashtable_walk_peek >> replaced and removed because it is unfixable. This patch removes the >> one

Re: [Cluster-devel] [PATCH v2 0/2] gfs2: Stop using rhashtable_walk_peek

On Thu, Mar 29, 2018 at 03:15:54PM +0200, Andreas Gruenbacher wrote: > > For all I know, Neil's latest plan is to get rhashtable_walk_peek > replaced and removed because it is unfixable. This patch removes the > one and only user. His latest patch makes rhashtable_walk_peek stable in the face of

Re: [Cluster-devel] [PATCH] gfs2: Zero out fallocated blocks in fallocate_chunk

- Original Message - | Instead of zeroing out fallocated blocks in gfs2_iomap_alloc, zero them | out in fallocate_chunk, much higher up the call stack. This gets rid of | gfs2's abuse of the IOMAP_ZERO flag as well as the gfs2 specific zeronew | buffer flag. I can't think of a reason why

Re: [Cluster-devel] [PATCH v2 0/2] gfs2: Stop using rhashtable_walk_peek

On 29 March 2018 at 14:35, Herbert Xu wrote: > On Thu, Mar 29, 2018 at 02:06:10PM +0200, Andreas Gruenbacher wrote: >> Here's a second version of the patch (now a patch set) to eliminate >> rhashtable_walk_peek in gfs2. >> >> The first patch introduces

Re: [Cluster-devel] [PATCH v2 0/2] gfs2: Stop using rhashtable_walk_peek

On Thu, Mar 29, 2018 at 02:06:10PM +0200, Andreas Gruenbacher wrote: > Here's a second version of the patch (now a patch set) to eliminate > rhashtable_walk_peek in gfs2. > > The first patch introduces lockref_put_not_zero, the inverse of > lockref_get_not_zero. > > The second patch eliminates

Re: [Cluster-devel] [PATCH v2 0/2] gfs2: Stop using rhashtable_walk_peek

Hi, Can we solve the problem another way, by not taking refs on the glocks when we are iterating over them for the debugfs files? I assume that is the main issue here. We didn't used to take refs since the rcu locking was enough during the walk itself. We used to only keep track of the hash

[Cluster-devel] [PATCH v2 0/2] gfs2: Stop using rhashtable_walk_peek

Here's a second version of the patch (now a patch set) to eliminate rhashtable_walk_peek in gfs2. The first patch introduces lockref_put_not_zero, the inverse of lockref_get_not_zero. The second patch eliminates rhashtable_walk_peek in gfs2. In gfs2_glock_iter_next, the new lockref function

[Cluster-devel] [PATCH v2 1/2] lockref: Add lockref_put_not_zero

Put a lockref unless the lockref is dead or its count would become zero. This is the same as lockref_put_or_lock except that the lock is never left held. Signed-off-by: Andreas Gruenbacher --- include/linux/lockref.h | 1 + lib/lockref.c | 28

[Cluster-devel] [PATCH v2 2/2] gfs2: Stop using rhashtable_walk_peek

Function rhashtable_walk_peek is problematic because there is no guarantee that the glock previously returned still exists; when that key is deleted, rhashtable_walk_peek can end up returning a different key, which will cause an inconsistent glock dump. Fix this by keeping track of the current

Re: [Cluster-devel] [PATCH] gfs2: Stop using rhashtable_walk_peek

On Wed, Mar 28 2018, Andreas Gruenbacher wrote: > Function rhashtable_walk_peek is problematic because there is no > guarantee that the glock previously returned still exists; when that key > is deleted, rhashtable_walk_peek can end up returning a different key, > which would cause an

Re: [Cluster-devel] [PATCH] gfs2: Zero out fallocated blocks in fallocate_chunk

Looks good to me from the iomap POV: Acked-by: Christoph Hellwig