aboutsummaryrefslogtreecommitdiff
path: root/include
diff options
context:
space:
mode:
authorSteven Whitehouse <swhiteho@redhat.com>2008-02-22 16:09:31 +0000
committerSteven Whitehouse <swhiteho@redhat.com>2008-03-31 10:41:14 +0100
commit9b8c81d1de49943ec69d157234b8981008c30d31 (patch)
treec0cbbd25fdcbf376c06c9dcfb7d25b8873caa6ff /include
parent7afd88d9166a752b52517648bcbe923e05d393fc (diff)
[GFS2] Allow bmap to allocate extents
We've supported mapping of extents when no block allocation is required for some time. This patch extends that to mapping of extents when an allocation has been requested. In that case we try to allocate as many blocks as are requested, but we might return fewer in case there is something preventing us from returning the complete amount (e.g. an already allocated block is in the way). Currently the only code path which can actually request multiple data blocks in a single bmap call is the page_mkwrite path and even then it only happens if there are multiple blocks per page. What this patch does do however, is merge the allocation requests for metadata (growing the metadata tree in either height or depth) with the allocation of the data blocks in the case that both are needed. This results in lower overheads even in the single block allocation case. The one thing which we can't handle here at the moment is unstuffing. I would like to be able to do that, but the problem which arises is that in order to unstuff one has to get a locked page from the page cache which results in locking problems in the (usual) case that the caller is holding the page lock on the page it wishes to map. So that case will have to be addressed in future patches. Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
Diffstat (limited to 'include')
0 files changed, 0 insertions, 0 deletions