lkml.org 
[lkml]   [2004]   [Nov]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Designing Another File System
    On Tue, 30 Nov 2004 20:42:38 -0500, John Richard Moser
    > Phil Lougher wrote:
    > | Um, all filesystems do that, I think you're missing words to the
    > | effect "without any performance loss or block fragmentation" !
    >
    > All filesystems allow you to create the FS with 1 inode total?
    >
    > Filesystem Inodes IUsed IFree IUse% Mounted on
    > /dev/hda1 7823616 272670 7550946 4% /
    >
    > No, it looks like this one allocates many inodes and uses them as it
    > goes. Reiser has 0 inodes . . .

    Yes you're right. What I said was total rubbish. I read your
    statement as meaning to dynamically allocate/deallocate inodes from a
    set configured at filesystem creation...

    > |
    > | 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.
    > |
    >
    > Ugly, but ok. What happens when i actually have >4G inodes though?

    Well this is an issue that affects all filesystems on 32-bit systems
    (as Alan said inode numbers are 64 bits on 64 bit systems). To be
    honest I've never let this worry me...

    A 32-bit system can never cache 4G inodes in memory without falling
    over, and so a simple solution would be to allocate the 32-bit inode
    number dynamically (e.g. starting at one and going up, keeping track
    of inode numbers still used for use when/if wraparound occured), this
    would guarantee inode number uniqueness for the subset of file inodes
    in memory at any one time, with the drawback that inode numbers
    allocated to files will change over filesystem mounts. Alternatively
    from reading fs/inode.c it appears that inode numbers only need to be
    unique if the fast hashed inode cache lookup functions are used, there
    are other inode cache lookup functions that can be used if inode
    numbers are not unique.

    > | 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...
    > |
    >
    > Ouch. Someone told me the directory had to be O(1) lookup . . . .

    Ideally yes, but ultimately with your filesystem you make the rules
    :-) The Squashfs directory design was fast for the original expected
    directory size (ideally <= 64K, maximum 512K) seen on embedded
    systems. The next release of Squashfs has considerably improved
    indexed directories which are O(1) for large directories. To be
    released sometime soon, if anyone's interested...

    Phillip Lougher
    -
    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 14:08    [W:2.756 / U:0.412 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site