From mboxrd@z Thu Jan 1 00:00:00 1970 From: Valerie Henson Subject: Re: ChunkFS - measuring cross-chunk references Date: Sun, 6 May 2007 22:18:04 -0700 Message-ID: <20070507051803.GG12859@nifty> References: <2e4afe1e0704221335y6d4c84d8id65e71826ce60acb@mail.gmail.com> <462B8D0C.7020509@ksu.edu> <2e4afe1e0704230019h3853bc82uae6c9b5cdc325ab9@mail.gmail.com> <1177320876.23226.7.camel@garfield> <20070423205333.GZ5967@schatzie.adilger.int> <20070424001306.GB1663@thunk.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii To: Theodore Tso , Kalpak Shah , Karuna sagar K , Amit Gud , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.orgG Return-path: Received: from mga06.intel.com ([134.134.136.21]:28481 "EHLO orsmga101.jf.intel.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754003AbXEGFSA (ORCPT ); Mon, 7 May 2007 01:18:00 -0400 Content-Disposition: inline In-Reply-To: <20070424001306.GB1663@thunk.org> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org 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