> > in that case, every filesystem iget operation has to wade through 100K+
> > inodes to find an inode (imagine the length of the hash lists in a 256
> > bucket hash table!). every d_lookup has to do the same. each inode is as
>
> So dont use a 256 bucket hash table. Dave has some nice 2.2. patches for
> the hashes (and the socket hashes want to be bigger too)
Alan, pardon me, but WTF do we need to include the socket inodes into the
normal hash chains? Let's make a separate chain for them (out of the hash
table) and be done with that. If we are doing iget() on _socket_ inodes
anywhere we are indeed deep in it. Heck, they have NULL i_sb, just what
will you pass to iget() to look for them? NULL is not a good idea -
somehow I doubt that the the kernel will be happy with NULL->read_inode()
in case of the cache miss.
ObThingsThatSuck: AFFS layout. Up to 5 (on-disk) list surgeries upon the
rename(). In the bloody single-linked lists. Happy, happy, joy, joy... And
we can't allow the thing to break in the middle - fs corruption and
general unhappiness will follow. Damn, plain unlink may take 3 movements
_and_ reshuffling of another sort of lists (also single-linked). The
bloody thing is choke-full of metadata-corrupting races and I can't blame
the authors of the driver. Now, authors of the _design_... What was the
old UK punishment for high treason, again? Arrrgh...
Down, not across.
Al
-- Two of my imaginary friends reproduced once ... with negative results. Ben <float@interport.net> in ASR
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/