| commit | 6346c93988caa3048bf4d81f9ba3608a7a195aa2 | |
| author | Josef Bacik <josef@redhat.com> | |
| Wed, 11 Nov 2009 02:23:47 +0000 (10 21:23 -0500) | ||
| committer | Chris Mason <chris.mason@oracle.com> | |
| Wed, 11 Nov 2009 19:20:16 +0000 (11 14:20 -0500) | ||
| tree | 78e5fbc5fa6ed8c692db24dfff475e2b95413570 | treesnapshot (tar.gz zip) |
| parent | 444528b3e614f7f2391488d9bca8e0b872db909b | commitdiff |
Btrfs: fix data allocation hint start
Sometimes our start allocation hint when we cow a file can be either
EXTENT_HOLE or some other such place holder, which is not optimal. So if we
find that our em->block_start is one of these special values, check to see
where the first block of the inode is stored, and use that as a hint. If that
block is also a special value, just fallback on a hint of 0 and let the
allocator figure out a good place to put the data.
Signed-off-by: Josef Bacik <josef@redhat.com>
Signed-off-by: Chris Mason <chris.mason@oracle.com>
Sometimes our start allocation hint when we cow a file can be either
EXTENT_HOLE or some other such place holder, which is not optimal. So if we
find that our em->block_start is one of these special values, check to see
where the first block of the inode is stored, and use that as a hint. If that
block is also a special value, just fallback on a hint of 0 and let the
allocator figure out a good place to put the data.
Signed-off-by: Josef Bacik <josef@redhat.com>
Signed-off-by: Chris Mason <chris.mason@oracle.com>
| fs/btrfs/inode.c | diffblobblamehistory |