Re: Issues with delalloc->real extent allocation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs


[Index of Archives]     [Linux XFS Devel]     [Linux Filesystem Development]     [Filesystem Testing]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux