[Top] [All Lists]

Re: [PATCH 18/18] xfs: recall pNFS layouts on conflicting access

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: [PATCH 18/18] xfs: recall pNFS layouts on conflicting access
From: Christoph Hellwig <hch@xxxxxx>
Date: Wed, 7 Jan 2015 11:31:52 +0100
Cc: Christoph Hellwig <hch@xxxxxx>, "J. Bruce Fields" <bfields@xxxxxxxxxxxx>, Jeff Layton <jlayton@xxxxxxxxxxxxxxx>, linux-nfs@xxxxxxxxxxxxxxx, linux-fsdevel@xxxxxxxxxxxxxxx, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20150106231846.GE31508@dastard>
References: <1420561721-9150-1-git-send-email-hch@xxxxxx> <1420561721-9150-19-git-send-email-hch@xxxxxx> <20150106231846.GE31508@dastard>
User-agent: Mutt/1.5.17 (2007-11-01)
On Wed, Jan 07, 2015 at 10:18:46AM +1100, Dave Chinner wrote:
> On Tue, Jan 06, 2015 at 05:28:41PM +0100, Christoph Hellwig wrote:
> > Recall all outstanding pNFS layouts and truncates, writes and similar extent
> > list modifying operations.
> This is not sufficient to isolate extent manipulations. mmap writes
> can trigger allocation through ->page_mkwrite, and can also trigger
> extent conversion at IO completion without first needing allocation.
> Maybe I'm missing something - this patchset needs some comments
> documenting the locking used in XFS to co-ordinate layout coherency
> at the client side with IO that is in progress for clients with
> overlapping block maps, as well as against server side application
> IO.

Ys, the description was a little to dense.  We only care about extent list
manipulations that remove or change existing block mappings.  Newly
allocated blocks don't concern the pNFS operation.

I'll take care of better documentation.

<Prev in Thread] Current Thread [Next in Thread>