> On Thu, 11 Feb 1999, Alexander Viro wrote:
>
> >sense. For separately allocated pieces - no way. Inodes are *way* too fat
> >right now. IMHO we should have two different beasts - VFS inode (generic
>
> How much too fat? I thought it wasn't an issue.
Think of layered filesystems (unionfs, umsdos *shrieks* for that,
hfs would be much nicer, all sorts of encryption, devfs, etc.). Look at
the way symlinks work in UMSDOS. It's ugly. Size of inode includes the
size of *fattest* fs-specific part, so stacking them is not an option
now. Feather-weight inodes would be very useful.
> >called by shrink_dcache() and be invisible for VM - after all, it's VFS
> >business what to trim and what kind of balance should be kept between
> >dcache, icache and fs-specific parts.
>
> Agreed, better to do the work in shrink_dcache(). Once you shrunk the
> dcache you can free also the inodes that was attached to the freed
> dentries (if I understand right how the dcache works).
Not exactly. dcache is a primary cache. icache is the second-level
one. I.e. when you do lookup you may find out that inode you need is
already in icache. If you are in low-memory situation it makes sense to
trim icache to minimum (i.e. to the stuff referenced from dcache).
Generally you don't want to do it, at least for local filesystems having
real inodes (e.g. UNIX-like ones).
BTW, is there a decent way to create a cache from module? slabs
want permanent storage, if I've parsed the comment in mm/slab.c right. I
really need it for clean rewrite of FAT-derived stuff (cache for directory
entries in FAT sense; that would solve all problems with bogus inumbers).
-
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/