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 - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
