[lkml]   [2004]   [Nov]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Designing Another File System
    On Mon, 29 Nov 2004 23:32:05 -0500, John Richard Moser
    <> wrote:

    > - - localization of Inodes and related meta-data to prevent disk thrashing

    All filesystems place their filesystem metadata inside the inodes. If
    you mean file metadata then please be more precise. This isn't
    terribly new, recent posts have discussed how moving eas/acls inside
    the inode for ext3 has sped up performance.

    > - - a scheme which allows Inodes to be dynamically allocated and
    > deallocated out of order

    Um, all filesystems do that, I think you're missing words to the
    effect "without any performance loss or block fragmentation" !

    > - - 64 bit indices indicating the exact physical location on disk of
    > Inodes, giving a O(1) seek to the Inode itself

    > 1) Can Unix utilities in general deal with 64 bit Inodes? (Most
    > programs I assume won't care; ls -i and df -i might have trouble)

    There seems to be some confusion here. The filesystem can use 64 bit
    inode numbers internally but hide these 64 bits and instead present
    munged 32 bit numbers to Linux.

    The 64 bit resolution is only necessary within the filesystem dentry
    lookup function to go from a directory name entry to the physical
    inode location on disk. The inode number can then be reduced to 32
    bits for 'presentation' to the VFS. AFAIK as all file access is
    through the dentry cache this is sufficient. The only problems are
    that VFS iget() needs to be replaced with a filesystem specific iget.
    A number of filesystems do this. Squashfs internally uses 37 bit
    inode numbers and presents them as 32 bit inode numbers in this way.

    > 3) What basic information do I absolutely *need* in my super block?
    > 4) What basic information do I absolutely *need* in my Inodes? (I'm
    > thinking {type,atime,dtime,ctime,mtime,posix_dac,meta_data_offset,size,\
    > links}

    Very much depends on your filesystem. Cramfs is a good example of the
    minimum you need to store to satisfy the Linux VFS. If you don't care
    what they are almost anything can be invented (uid, gid, mode, atime,
    dtime etc) and set to a useful default. The *absolute* minimum is
    probably type, file/dir size, and file/dir data location on disk.

    > I guess the second would be better? I can't locate any directories on
    > my drive with >2000 entries *shrug*. The end key is just the entry
    > {name,inode} pair.

    I've had people trying to store 500,000 + files in a Squashfs
    directory. Needless to say with the original directory implementation
    this didn't work terribly well...

    Phillip Lougher
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:08    [W:0.023 / U:86.312 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site