> > fs operations expect to get dentries with a specific relationship, and
> > perform dcache operations on the dentries. For example, the rename
> > operation results in the dentries changing names and parents, which
> > could result in the synthetic dentries getting mixed up with the real
> > ones.
>
> Perhaps we should revert the kernel back to inodes and throw dentries
> out at this point then. If we can't fix them then we have to find an alternative
> before 2.2
Gentlemen,
I didn't want to be the first to raise this alternative, but now that Alan
has brought it up I have a simple, basic, question:
Was the d_entry concept a solution in search of a problem? Can anyone
outline exactly what it was intended to buy us? From this novice
kernel-hacker's standpoint, it seems to have triggered nothing but endless
churn and tail-chasing at the lowest levels.
If there are supposed to be enormous performance improvements, I sure
haven't seen them. Midnight Commander, which stats out an entire
directory on a chdir, takes about 3x longer to gulp up a large directory
under 2.1.63 (on a P150+ 6x86) than does 2.0.32 (on a 486/100, yet). This
is not just the first time - but _every_ time. Clearly no win on this
point...
I'm not trying to start a flame-war, but I do know that there comes a time
to objectively re-analyze a troublesome design decision. Perhaps we are
at such a point with d_entries?
With Respect,
Steve