lkml.org 
[lkml]   [2002]   [Sep]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [RFC] mount flag "direct"
Date
"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/

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