Btrfs: Always use 64bit inode number
There's a potential problem in 32bit system when we exhaust 32bit inode
numbers and start to allocate big inode numbers, because btrfs uses
inode->i_ino in many places.
So here we always use BTRFS_I(inode)->location.objectid, which is an
u64 variable.
There are 2 exceptions that BTRFS_I(inode)->location.objectid !=
inode->i_ino: the btree inode (0 vs 1) and empty subvol dirs (256 vs 2),
and inode->i_ino will be used in those cases.
Another reason to make this change is I'm going to use a special inode
to save free ino cache, and the inode number must be > (u64)-256.
Signed-off-by:
Li Zefan <lizf@cn.fujitsu.com>
Showing
- fs/btrfs/btrfs_inode.h 9 additions, 0 deletionsfs/btrfs/btrfs_inode.h
- fs/btrfs/compression.c 3 additions, 2 deletionsfs/btrfs/compression.c
- fs/btrfs/export.c 14 additions, 11 deletionsfs/btrfs/export.c
- fs/btrfs/extent-tree.c 5 additions, 5 deletionsfs/btrfs/extent-tree.c
- fs/btrfs/extent_io.c 2 additions, 2 deletionsfs/btrfs/extent_io.c
- fs/btrfs/file-item.c 3 additions, 2 deletionsfs/btrfs/file-item.c
- fs/btrfs/file.c 14 additions, 13 deletionsfs/btrfs/file.c
- fs/btrfs/inode.c 103 additions, 94 deletionsfs/btrfs/inode.c
- fs/btrfs/ioctl.c 9 additions, 9 deletionsfs/btrfs/ioctl.c
- fs/btrfs/relocation.c 13 additions, 11 deletionsfs/btrfs/relocation.c
- fs/btrfs/transaction.c 2 additions, 2 deletionsfs/btrfs/transaction.c
- fs/btrfs/tree-log.c 27 additions, 27 deletionsfs/btrfs/tree-log.c
- fs/btrfs/xattr.c 4 additions, 4 deletionsfs/btrfs/xattr.c
Please register or sign in to comment