Re: O_DIRECT read and holes in 2.5.26

Andrew Morton
2002-07-22T04:19:03Z

Anton Altaparmakov wrote:
>
> Hi Andrew,
>
> At 03:26 22/07/02, Andrew Morton wrote:
> >Stephen Lord wrote:
> > > Did you realize that the new O_DIRECT code in 2.5 cannot read over holes
> > > in a file.
> >
> >Well that was intentional, although I confess to not having
> >put a lot of thought into the decision. The user wants
> >O_DIRECT and we cannot do that. The CPU has to clear the
> >memory by hand. Bad.
> >
> >Obviously it's easy enough to put in the code to clear the
> >memory out. Do you think that should be done?
>
> I would vote for yes because whether a file is sparse or not cannot be
> trivially controlled by the file creator (unless you actually write the
> whole file with non-zero content) but is dependent on the underlying file
> system...

O_DIRECT tends to be used in specialised applications. They're
being silly if they're reading from holes.

> And on the grounds that a memset() is going to be a lot faster
> than a read from device I don't see why it shouldn't be done.

It's actually tons more expensive - wiping the page by hand
goes against the whole reason for using O_DIRECT.

But it is the expected behaviour of the read() system call
so yeah, I'll do it.

> ...
> [ get_blocks() stuff ]
>

This is going to be fairly involved. Probably the top-level
IO code gets ripped up and redone to expect a get_blocks()
interface. A default implementation of get_blocks() would
be provided for naive filesystems - it just calls get_block()
a lot. Quite possibly, we say to heck with purity and get_block()
and get_blocks() become a_ops, too.

I'd really like to see a solid reason for doing all this.
That means numbers ;) Even good old ext2 would be able to show
benefit from batching up the get_block() work, but not a lot.

You won't buy much on writes, I expect - 8k write requests
will probably remain the ideal size.

-