On Monday 25 April 2011 10:57:47 Li Zefan wrote: > 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 patchset aims to fix this, and it works similar to free space caching > for block groups. > > I've run xfstests, and I also tested it with snapshot, balance etc. > > More testing is appreciated! > > Changelog v2: > > - Rebased against latest btrfs-unstable tree > - Fixed several small bugs. > > --- > fs/btrfs/btrfs_inode.h | 9 + > fs/btrfs/compression.c | 5 +- > fs/btrfs/ctree.h | 29 +- > fs/btrfs/disk-io.c | 19 + > fs/btrfs/export.c | 25 +- > fs/btrfs/extent-tree.c | 50 ++- > fs/btrfs/extent_io.c | 4 +- > fs/btrfs/file-item.c | 5 +- > fs/btrfs/file.c | 27 +- > fs/btrfs/free-space-cache.c | 968 > ++++++++++++++++++++++++++----------------- fs/btrfs/free-space-cache.h | > 48 ++- > fs/btrfs/inode-map.c | 428 +++++++++++++++++++- > fs/btrfs/inode-map.h | 13 + > fs/btrfs/inode.c | 282 +++++++------ > fs/btrfs/ioctl.c | 22 +- > fs/btrfs/relocation.c | 27 +- > fs/btrfs/transaction.c | 13 +- > fs/btrfs/tree-log.c | 54 ++-- > fs/btrfs/xattr.c | 8 +- > 19 files changed, 1402 insertions(+), 634 deletions(-)
This makes my laptop unusable here. With linux-3.0-rc1 I have the problem that booting is horrible slow with very much IO (the kernel thread that reads the file tree?). I've never tried how long it would take to boot the system. After 10-15 minutes I've canceled the boot (sysrq-u, sysrq-b) and took a working kernel. git bisect pointed me to: commit 581bb050941b4f220f84d3e5ed6dace3d42dd382 Author: Li Zefan <[email protected]> Date: Wed Apr 20 10:06:11 2011 +0800 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 <[email protected]> I have three subvolumes here, the default one, one for / and one for /home. Don't know if this matters. If you need more infos, please tell me. regards, Johannes -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
