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 all, then wait for them a
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 multi-block reservation
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, provided they're all on
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 o
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 th
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 to
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 processed in a sub-opt
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 callouts, nor why
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 helper
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
> asynch
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 c
11 matches
Mail list logo