Btrfs: don't allocate a seperate csums array for direct reads
authorJosef Bacik <jbacik@fusionio.com>
Fri, 3 Aug 2012 20:49:19 +0000 (16:49 -0400)
committerChris Mason <chris.mason@oracle.com>
Tue, 28 Aug 2012 20:53:30 +0000 (16:53 -0400)
commitc329861da40623cd838b8c9ee31a850242fd88cf
treed395b6dae57c00c25f1b890db1f39871575a7013
parent99f5944b8477914406173b47b4f261356286730b
Btrfs: don't allocate a seperate csums array for direct reads

We've been allocating a big array for csums instead of storing them in the
io_tree like we do for buffered reads because previously we were locking the
entire range, so we didn't have an extent state for each sector of the
range.  But now that we do the range locking as we map the buffers we can
limit the mapping lenght to sectorsize and use the private part of the
io_tree for our csums.  This allows us to avoid an extra memory allocation
for direct reads which could incur latency.  Thanks,

Signed-off-by: Josef Bacik <jbacik@fusionio.com>
fs/btrfs/ctree.h
fs/btrfs/file-item.c
fs/btrfs/inode.c