Messages in this thread | | | Subject | Re: BIG files & file systems | From | Stephen Lord <> | Date | 01 Aug 2002 19:09:37 -0500 |
| |
On Wed, 2002-07-31 at 22:51, Jan Harkes wrote: > On Wed, Jul 31, 2002 at 05:13:46PM -0400, Alexander Viro wrote: > > On Wed, 31 Jul 2002, Jan Harkes wrote: > > > On Wed, Jul 31, 2002 at 01:16:20PM -0600, Peter J. Braam wrote: > > > > I've just been told that some "limitations" of the following kind will > > > > remain: > > > > page index = unsigned long > > > > ino_t = unsigned long > > > > > > The number of files is not limited by ino_t, just look at the > > > iget5_locked operation in fs/inode.c. It is possible to have your own > > > n-bit file identifier, and simply provide your own comparison function. > > > The ino_t then becomes the 'hash-bucket' in which the actual inode is > > > looked up. > > > > You _do_ need unique ->st_ino from stat(2), though - otherwise tar(1) > > and friends will break in all sorts of amusing ways. And there's > > nothing kernel can do about that - applications expect 32bit st_ino > > (compare them as 32bit values, etc.) > > Which is why "tar and friends" are to different extents already broken > on various filesystems like Coda, NFS, NTFS, ReiserFS, and probably XFS. > (i.e. anything that currently uses iget5_locked instead of iget to grab > the inode).
Why are they broken? In the case of XFS at least you still get a unique and stable inode number back - and it fits in 32 bits too.
Steve
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |