Messages in this thread | | | From | "Peter T. Breuer" <> | Subject | Re: [RFC] mount flag "direct" | Date | Wed, 4 Sep 2002 08:21:29 +0200 (MET DST) |
| |
"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/
| |