Re: ChunkFS - measuring cross-chunk references

[Valerie Henson <val_henson@linux.intel.com>]

On Mon, Apr 23, 2007 at 08:13:06PM -0400, Theodore Tso wrote:
> 
> There may also be special things we will need to do to handle
> scenarios such as BackupPC, where if it looks like a directory
> contains a huge number of hard links to a particular chunk, we'll need
> to make sure that directory is either created in the right chunk
> (possibly with hints from the application) or migrated to the right
> chunk (but this might cause the inode number of the directory to
> change --- maybe we allow this as long as the directory has never been
> stat'ed, so that the inode number has never been observed).

Yeah, this is an oddball but real case.  What are the consequences of
inode number changing - increased backup bandwidth?  It seems like it
would have the same effect as "cp -a dir tmp; rm -rf dir; mv tmp dir",
which is certainly legal (and a good way to defragment subtrees).

> The other thing which we should consider is that chunkfs really
> requires a 64-bit inode number space, which means either we only allow
> it on 64-bit systems, or we need to consider a migration so that even
> on 32-bit platforms, stat() functions like stat64(), insofar that it
> uses a stat structure which returns a 64-bit ino_t.

A 32-bit inode space probably won't be that hard to do for chunkfs,
although it would limit total file system size.  This problem needs to
be solved in general, I'm afraid - 4 billion inodes is just not that
many now.

-VAL