Messages in this thread | | | Date | Sun, 16 Nov 1997 10:41:22 -0500 (EST) | From | "Steven N. Hirsch" <> | Subject | Re: knfsd and system crashes |
| |
On Sun, 16 Nov 1997, Alan Cox wrote:
> > 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
| |