xfs
[Top] [All Lists]

Re: Issues with delalloc->real extent allocation

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: Issues with delalloc->real extent allocation
From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Thu, 20 Jan 2011 06:16:12 -0500
Cc: Christoph Hellwig <hch@xxxxxxxxxxxxx>, bpm@xxxxxxx, xfs@xxxxxxxxxxx
In-reply-to: <20110120013346.GO16267@dastard>
References: <20110114002900.GF16267@dastard> <20110114214334.GN28274@xxxxxxx> <20110114235549.GI16267@dastard> <20110118204752.GB28791@xxxxxxxxxxxxx> <20110118231831.GZ28803@dastard> <20110119120321.GC12941@xxxxxxxxxxxxx> <20110119133147.GN16267@dastard> <20110119135548.GA11502@xxxxxxxxxxxxx> <20110120013346.GO16267@dastard>
User-agent: Mutt/1.5.21 (2010-09-15)
On Thu, Jan 20, 2011 at 12:33:46PM +1100, Dave Chinner wrote:
> It's case b) that I'm mainly worried about, esp. w.r.t the 64k page
> size on ia64/ppc. If we only track a single dirty bit in the page,
> then every sub-page, non-appending write to an uncached region of a
> file becomes a RMW cycle to initialise the areas around the write
> correctly. The question is whether we care about this enough given
> that we return at least PAGE_SIZE in stat() to tell applications the
> optimal IO size to avoid RMW cycles.

Note that this generally is only true for the first write into the
region - after that we'll have the rest read into the cache.  But
we also have the same issue for appending writes if they aren't
page aligned.

> And if we only do IO on whole pages (i.e regardless of block size)
> .writepage suddenly becomes a lot simpler, as well as being trivial
> to implement our own .readpage/.readpages....

I don't think it simplifies writepage a lot.  All the buffer head
handling goes away, but we'll still need to do xfs_bmapi calls at
block size granularity.  Why would you want to replaced the
readpage/readpages code?  The generic mpage helpers for it do just fine.

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