Re: [RFC] mount flag "direct"

["Peter T. Breuer" <ptb@it.uc3m.es>]

"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