]> git.baikalelectronics.ru Git - kernel.git/commit
[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)
commitc114a9de1fed650e17f74379fe4822efacd14bf4
treec0cbbd25fdcbf376c06c9dcfb7d25b8873caa6ff
parent8c5234ea34fc3844a24d3b440d364f7e6d47e29f
[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