[GFS2] Allow bmap to allocate extents
authorSteven Whitehouse <swhiteho@redhat.com>
Fri, 22 Feb 2008 16:09:31 +0000 (16:09 +0000)
committerSteven Whitehouse <swhiteho@redhat.com>
Mon, 31 Mar 2008 09:41:14 +0000 (10:41 +0100)
commit9b8c81d1de49943ec69d157234b8981008c30d31
treec0cbbd25fdcbf376c06c9dcfb7d25b8873caa6ff
parent7afd88d9166a752b52517648bcbe923e05d393fc
[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>
fs/gfs2/bmap.c
fs/gfs2/dir.c
fs/gfs2/rgrp.c