Btrfs: Cache free inode numbers in memory
commit581bb050941b4f220f84d3e5ed6dace3d42dd382
authorLi Zefan <lizf@cn.fujitsu.com>
Wed, 20 Apr 2011 02:06:11 +0000 (20 10:06 +0800)
committerLi Zefan <lizf@cn.fujitsu.com>
Mon, 25 Apr 2011 08:46:04 +0000 (25 16:46 +0800)
tree5ebd56af5eb3612f508419b188dfc18e959e7c94
parent34d52cb6c50b5a43901709998f59fb1c5a43dc4a
Btrfs: Cache free inode numbers in memory

Currently btrfs stores the highest objectid of the fs tree, and it always
returns (highest+1) inode number when we create a file, so inode numbers
won't be reclaimed when we delete files, so we'll run out of inode numbers
as we keep create/delete files in 32bits machines.

This fixes it, and it works similarly to how we cache free space in block
cgroups.

We start a kernel thread to read the file tree. By scanning inode items,
we know which chunks of inode numbers are free, and we cache them in
an rb-tree.

Because we are searching the commit root, we have to carefully handle the
cross-transaction case.

The rb-tree is a hybrid extent+bitmap tree, so if we have too many small
chunks of inode numbers, we'll use bitmaps. Initially we allow 16K ram
of extents, and a bitmap will be used if we exceed this threshold. The
extents threshold is adjusted in runtime.

Signed-off-by: Li Zefan <lizf@cn.fujitsu.com>
fs/btrfs/ctree.h
fs/btrfs/disk-io.c
fs/btrfs/free-space-cache.c
fs/btrfs/free-space-cache.h
fs/btrfs/inode-map.c
fs/btrfs/inode-map.h [new file with mode: 0644]
fs/btrfs/inode.c
fs/btrfs/ioctl.c
fs/btrfs/relocation.c
fs/btrfs/transaction.c