Alexander Viro wrote:

> ??? inodes are not in dcache. Dentries are, and without them lookups will
Forgive my imprecision of statement.

> kill you + you'll have a dubious pleasure to reproduce all race-preventing
> code of VFS in your replacement mechanism. Which is pretty likely to bring
> you sizeof(dentry) back, nevermind the several years of bughunting (and
> that's precisely the case when testing will not help - race scenarios in
> that area are impossible to hit unless you've found them in the code and
> are deliberately hunting for that particular race). But hey, if you want
> to do that - go ahead, it's your ass, after all.
> 
> Making inodes droppable (i.e. letting dentry get rid of in-core inode if
> we can rebuild it) actually makes sense, but that's a 2.5 project. We

Nobody on this list is crazy enough to propose starting new projects for 2.4.

In fact, I would be personally upset if you started more non-bugfix VFS work for
2.4 right now.:-)

Dropping dentries could easily be much harder to code in the general case, and
your resisting that suggestion is very reasonable, but we are pie-in-the-skying
right now, so I said what I did.  I will further pie-in-the-sky and suggest that
perhaps special individual directories could be without dentries, and perhaps
that would be easier to code since those special directories could fail to
support such things as mount points, etc.

Now is probably a good time to pie-in-the-sky for 2.5, as doing anything
imaginative for 2.4 should be strictly verbotten, and we all need something
besides debugging to get us through the day.  Agree?


> No surprise here, but if they have dedicated boxen they may want to trim
> the unneeded lines from inode->u - it's a union and it has some pretty
> large fields. If you don't use foofs - don't include its private inode
> into the thing. Not that radical, but may actually reduce the
> sizeof(struct inode) about two times (depends on the filesystem mix they
> are using, indeed).

I know ifdefs are not beloved by the penguin, but is there any other reason not
to use them on said union to exclude unconfigured filesystems?  They seem
precisely appropriate here.

Hans

Reply via email to