Re: [Cluster-devel] [PATCH v4 06/11] iomap: Add write_{begin, end} iomap operations

On Tue, May 15, 2018 at 11:11:47AM +1000, Dave Chinner wrote: > I'm not sure adding a per-page filesystem callout abstraction is > what we want in the iomap code. The commit message does not explain > why gfs2 needs per-page callouts, nor why the per-page work cannot > be done/avoided by running

Re: [Cluster-devel] [PATCH v4 09/11] gfs2: iomap direct I/O support

On Mon, May 14, 2018 at 05:36:22PM +0200, Andreas Gruenbacher wrote: > With that, the direct_IO address space operation can be all but > eliminated: only a dummy remains which indicates that the filesystem > supports direct I/O. And that dummy can be replaced with the generic noop_direct_IO

Re: [Cluster-devel] [PATCH v4 11/11] iomap: Complete partial direct I/O writes synchronously

On Mon, May 14, 2018 at 05:36:24PM +0200, Andreas Gruenbacher wrote: > According to xfstest generic/240, applications see, to expect direct I/O > writes to either complete as a whole or to fail; short direct I/O writes > are apparently not appreciated. This means that when only part of an >

Re: [Cluster-devel] [PATCH v4 06/11] iomap: Add write_{begin, end} iomap operations

On 15 May 2018 at 09:22, Christoph Hellwig wrote: > On Tue, May 15, 2018 at 11:11:47AM +1000, Dave Chinner wrote: >> I'm not sure adding a per-page filesystem callout abstraction is >> what we want in the iomap code. The commit message does not explain >> why gfs2 needs per-page

Re: [Cluster-devel] [GFS2 PATCH] GFS2: Add to tail, not head, of transaction

On 9 May 2018 at 15:21, Bob Peterson wrote: > Hi, > > Before this patch, frunction gfs2_trans_add_meta called list_add > to add a buffer to a transaction, tr_buf. Later, in the before_commit > functions, it traversed the list in sequential order, which meant > that they were

[Cluster-devel] [GFS2 PATCH 1/2] GFS2: Introduce LM_FLAG_NODE_EX holder bit: Node Exclusive sharing

This patch is a first step in rgrp sharing. It allows for glocks locked in EX mode to be shared amongst processes on that node. Like a SH (shared) glock, multiple processes may hold the lock in EX mode at the same time, provided they're all on the same node. This is a holder flag, meaning "Even

[Cluster-devel] [GFS2 PATCH 2/2] GFS2: Introduce rgrp sharing

This patch takes advantage of the new glock holder sharing feature for rgrps. New functions rgrp_lock and rgrp_unlock use a new semaphore to gain temporary exclusive access to the rgrps. This is needed whenever a multi-block reservation is reserved, and every time a function needs to add an rgrp

Re: [Cluster-devel] [GFS2 PATCH 2/2] GFS2: Introduce rgrp sharing

Hi Bob, On 15 May 2018 at 20:29, Bob Peterson wrote: > This patch takes advantage of the new glock holder sharing > feature for rgrps. New functions rgrp_lock and rgrp_unlock > use a new semaphore to gain temporary exclusive access to the > rgrps. This is needed whenever a

Re: [Cluster-devel] [GFS2 PATCH 1/2] GFS2: Introduce LM_FLAG_NODE_EX holder bit: Node Exclusive sharing

On 15 May 2018 at 20:29, Bob Peterson wrote: > This patch is a first step in rgrp sharing. It allows for glocks > locked in EX mode to be shared amongst processes on that node. > > Like a SH (shared) glock, multiple processes may hold the lock in > EX mode at the same time,

Re: [Cluster-devel] [GFS2 PATCH 2/2] GFS2: Submit all ordered writes in bulk, wait after that

Hi Bob, On 14 May 2018 at 16:18, Bob Peterson wrote: > Before this patch, the ordered_write function would submit all > the ordered writes with filemap_fdatawrite, which waited for each > one to complete before moving on to the next. This patch allows it > to submit them

[Cluster-devel] [GFS2 PATCH 0/2] Improve throughput through rgrp sharing (v3)

Hi, This is version 3 of my patch set to allow rgrp glock sharing, based on feedback I received from Steve Whitehouse and Andreas Gruenbacher. It improves upon version 2 in the following ways: 1. Comments and descriptions are fixed to match the actual intent of the code. They were previously