"A month of sundays ago Helge Hafting wrote:"
> "Peter T. Breuer" wrote:
> > "A month of sundays ago David Lang wrote:"
> > > Peter, the thing that you seem to be missing is that direct mode only
> > > works for writes, it doesn't force a filesystem to go to the hardware for
> > > reads.
> >
> > Yes it does. I've checked! Well, at least I've checked that writing
> > then reading causes the reads to get to the device driver. I haven't
> > checked what reading twice does.
>
> You tried reading from a file? For how long are you going to
Yes I did. And I tried readingtwice too, and it reads twice at device
level.
> work on that data you read? The other machine may ruin it anytime,
Well, as long as I want to. What's the problem? I read file X at time
T and got data Y. That's all I need.
> even instantly after you read it.
So what?
> Now, try "ls -l" twice instead of reading from a file. Notice
> that no io happens the second time. Here we're reading
Directory data is cached.
> metadata instead of file data. This sort of stuff
> is cached in separate caches that assumes nothing
> else modifies the disk.
True, and I'm happy to change it. I don't think we always had a
directory cache.
> > > filesystem you end up only haivng this option on the one(s) that you
> > > modify.
> >
> > I intend to make the generic mechanism attractive.
>
> It won't be attractive, for the simple reason that a no-cache fs
> will be devastatingly slow. A program that read a file one byte at
A generic mechanism is not a "no cache fs". It's a generic mechanism.
> Nobody will have time to wait for this, and this alone makes your
Try arguing logically. I really don't like it when people invent their
own straw men and then procede to reason as though it were *mine*.
> The main reason I can imagine for letting two machines write to
> the *same* disk is performance. Going cacheless won't give you
Then imagine some more. I'm not responsible for your imagination ...
> that. But you *can* beat nfs and friends by going for
> a "distributed ext2" or similiar where the participating machines
> talks to each other about who writes where.
> Each machine locks down the blocks they want to cache, with
> either a shared read lock or a exclusive write lock.
That's already done.
> There is a lot of performance tricks you may use, such as
No tricks. Let's be simple.
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:20 EST