[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: fatfs virtual inodes
Re: fatfs virtual inodes
Fri, 2 May 2003 23:17:38 +0200
Internet Messaging Program (IMP) 3.1
Quoting Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>:
> IIRC, the comment of NEW is targetted at a different problem, that of
> inode numbers instead just bumping the number up every time. However,
> reusing them might not be a smart idea anyway, given that there might be
> programs that not only expect the inode numbers to be unique, but also not
> jump around the filesystem all the time. I think the only thing that is
> saving us right now is the name cache of libdiskfs (which is only 200
> elements big, so try ls -i on a directory with more than 200 files, and see
> what happens to the inode numbers - I would expect the inode numbers to go
> up by the numbers of files every time).
The biggest problem of the old code is that the old structures are not removed.
And this code works more optimal than the old one (I assume). I'm still
increasing the number, but that doesn't harm us because unused numbers are not
in the table anymore, that could happen with the old version. A huge gap could
be created by removing all files except the last for example.
> However, this is unrelated to the issue of using a hash table instead a
> table. If that is what your patch does (I only skimmed over it), and it
> works, then that's great. However, please use libihash instead your own,
> unless you have some really good reason why not to. Don't ask me why we
> don't use libihash as the node cache in our filesystems, I don't know why.
You are correct, I've implemented it using a hashtable. There was no reason for
me not to use libihash (I assumed it was non-standard and not used anymore).
> And, use a prime number for the hash table size. Also in inode.c, please (I
> copied a non-prime from ext2fs at that time - only nfs was fixed, it seems).
> 509 is a prime near 512.
> > I also have a question about diskfs translators in the Hurd. There is a
> > function called inode_init in inode.c in most diskfs translators. Is this
> > code useless because the table will be initialized with 0's and who calls
> > this function? Looks like dead code to me, but I have used this in this
> > fatfs patch too be sure...
> Seems to be useless.
Ok, I'll remove it, removing stuff is fun :)
Do you want me to improve this patch as you suggested or do you think this is