Li Zefan 581bb05094 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>
2011-04-25 16:46:04 +08:00
..
2011-01-12 20:03:43 -05:00
2011-01-12 20:02:45 -05:00
2011-01-12 20:03:42 -05:00
2011-02-25 11:12:37 -08:00
2011-01-07 17:50:26 +11:00
2011-02-21 22:31:47 +00:00
2010-10-29 04:16:28 -04:00
2010-10-29 04:16:28 -04:00
2011-02-11 16:50:47 -06:00
2011-01-07 17:50:26 +11:00
2011-03-03 01:28:17 -05:00
2011-01-07 17:50:26 +11:00
2011-01-14 09:23:36 -08:00
2011-01-12 20:03:42 -05:00
2011-01-07 17:50:26 +11:00
2011-01-07 17:50:26 +11:00
2011-01-12 20:02:43 -05:00
2011-03-03 01:28:16 -05:00
2011-03-08 19:46:10 -05:00
2010-10-29 04:16:13 -04:00
2011-01-07 17:50:26 +11:00
2011-01-07 17:50:26 +11:00
2010-10-29 04:16:31 -04:00
2011-01-07 17:50:26 +11:00
2011-03-03 01:28:16 -05:00
2011-01-07 17:50:26 +11:00
2011-03-03 01:28:40 -05:00
2011-03-03 01:28:16 -05:00
2011-01-13 08:03:12 -08:00
2010-10-29 04:16:28 -04:00
2011-02-02 16:03:19 -08:00
2011-02-02 16:03:19 -08:00
2010-10-15 15:53:27 +02:00
2011-01-07 17:50:27 +11:00
2010-10-28 09:44:56 -07:00
2011-01-13 17:32:32 -08:00
2011-02-24 02:10:57 -05:00
2011-01-07 17:50:33 +11:00