Issues with delalloc->real extent allocation
Christoph Hellwig
hch at infradead.org
Wed Jan 19 07:55:48 CST 2011
On Thu, Jan 20, 2011 at 12:31:47AM +1100, Dave Chinner wrote:
> > If we want to completely get rid of buffers heads things are a bit
> > more complicated. It's doable as shown by the _nobh aops, but we'll
> > use quite a bit of per-block state that needs to be replaced by per-page
> > state,
>
> Sure, or use a similar method to btrfs which stores dirty state bits
> in a separate extent tree. Worst case memory usage is still much
> less than a bufferhead per block...
I'm not sure need to track sub-page dirty state. It only matters if we:
a) have a file fragmented enough that it has multiple extents allocated
inside a single page
b) have enough small writes that just dirty parts of a page
with a good enough persistant preallocation a) should happen almost
never, while b) might be an issue, specially with setups of 64k
page size and 4k blocks (e.g. ppc64 enterprise distro configs)
> > and we'll lose the way to cache the block number in the buffer
> > head. While we don't make use of that in writepage we do so in
> > the write path, although I'm not sure how important it is. If we
> > get your multi-page write work in it probably won't matter any more.
>
> The only place we use bh->b_blocknr is for ioend manipulation. Am I
> missing something else?
You're right. I thought we use it in the write path, but we only
care about the buffer_mapped flag, but never actually look at the
block number.
More information about the xfs
mailing list