lkml.org 
[lkml]   [2002]   [Jul]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: BIG files & file systems
    From
    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).

    Jan

    -
    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/

    \
     
     \ /
      Last update: 2005-03-22 13:27    [W:3.071 / U:0.060 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site