"Anton Altaparmakov wrote:"
> At 09:57 06/09/02, Peter T. Breuer wrote:
> >"Anton Altaparmakov wrote:"
> >I've had a look now. I concur that e2fs at least is full of assumptions
> >that it has various different sorts of metadata in memory at all times.
> >I can't rewrite that, or even add a "warning will robinson" callback to
> >vfs, as I intended. What I can do, I think, is ..
>
> Oh, you saw the light. (-: I can assure you that most file systems make
The question is if they do it in a way I can read. If I can read it, I
can fix it. There was too much noise inside e2fs to see a point or points
of intercept. So the intercept has to be higher, and ..
> direct_IO, I plan to keep all metadata caching in place, just stop caching
> the actual file data. That should give maximum performance I think.
But not correct behaviour wrt metadata in a shared disk fs. And your
calculation of "maximum performance" is off. Look, you seem to forget
this:
suppose that I make the FS twice as slow as before by meddling with
it to make it sharable
then I simply share it among 4 nodes to get a two times _speed up_
overall.
That's the basic idea. Details left to reader.
I.e. I don't care if it gets slower. We are talking thousands of nodes
here. Only the detail of the topology is affected by the real numbers.
> >.. simply do a dput of the fs root directory from time to time, from
> >vfs - whenever I think it is appropriate. As far as I can see from my
> >quick look that may cause the dcache path off that to be GC'ed. And
> >that may be enough to do a few experiments for O_DIRDIRECT.
>
> What does "GC" mean?
Garbage collection. I assume that either there is a point at which the
dcache is swept or as I free a dentry from the cache its dependents
are swept. I don't know which. Feel free to enlighten me. My question
is simply "is doing a dput of the base directory dentry on the FS
enough to clear the dcache for that FS"?
Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Sep 07 2002 - 22:00:28 EST