tux3: Inode number extrapolation heuristics
The idea is to make directory order similar to inode tree order,
so traversing a directory in physical order accesses the inode
table roughly in linear order.
On create, the inode number goal is chosen by extrapolating from
directory entry position in the directory file. This will tend to
preserve linear order even when a directory entry for a new inode
is created in a position previously emptied by a delete. The
exact correspondence is affected by name length, so that longer
names will create bigger gaps in the inode table. We want to
leave some gaps in the inode table anyway, so this is unlikely to
be a serious problem. Name length will not affect the relative
order of inodes.
There is some attempt to cluster non-directory inodes tightly
together, using a global next inode variable, set to one more
than the last chosen inode number. This is used as the inode
number goal, unless it is far away from the extrapolated goal,
in which case the latter is preferred
These heuristics do not include sensitivity to congestion and do
not attempt to spread directories out in a young volume. Actual
file size and directory population may be far different from the
assumptions used in the extrapolation. This may cause excessive
searching, more fragmentation and less temporal correlation of
block updates. These deficiencies will be addressed later.
The base for extrapolation is the parent inode. This may turn
out to be a bad choice due to congestion in an aged volume. It
is planned to be able to override that initial choice by a goal
attribute.
The usage sb->nextinum variable is racy and should be addressed
but is unlikely to cause problems because of the distance check
above.
Signed-off-by: Daniel Phillips <d.phillips@partner.samsung.com>
Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
1 file changed
