[lkml]   [1997]   [Nov]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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


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

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,


 \ /
  Last update: 2005-03-22 13:40    [W:0.087 / U:1.844 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site