Hi!
On Mon 22-01-18 09:57:05, Joseph Qi wrote:
> Any comments on this case?
> Or should we definitely leave it to be handled in user space code?
Since direct IO is not defined by any standard we are free to define our
own semantics. Since the behavior has changed about 4 years ago, we'd break
userspace with about the same likelhood when going back to the old behavior
as when staying with the current one. And the new semantics makes sense as
well - unaligned direct IO reads reads are invalid even though in this
particular case we could also handle the read and return 0. So I'd prefer
to stay with the current behavior.
Honza
> On 18/1/18 09:12, Joseph Qi wrote:
> >
> >
> > On 18/1/17 22:25, Matthew Wilcox wrote:
> >> On Wed, Jan 17, 2018 at 10:09:28AM +0000, Steven Whitehouse wrote:
> >>> Hi,
> >>>
> >>>
> >>> On 17/01/18 09:28, Joseph Qi wrote:
> >>>> Hi All,
> >>>>
> >>>> commit 9fe55eea7e4b ("Fix race when checking i_size on direct i/o read")
> >>>> has removed the pos check due to the race case.
> >>>>
> >>>> Now if I want to do direct read on a file which size is not sector
> >>>> alignment, it will return EINVAL in the last round. That means I have to
> >>>> handle the case by checking file size in user space, which I think is a
> >>>> bit inconvenient.
> >>> What do you mean by "not sector alignment"? Are you intending to read files
> >>> with any arbitrary size, or those with 512 byte alignment on a filesystem
> >>> with some larger block size, or something else?
> >> I think he's saying that the file he's trying to read has a length which
> >> is not a multiple of 512.
> > Yes, suppose I am trying to read a file which size is 4000 bytes, and
> > the allocated buffer is 4096 bytes.
> > When running my test program, it returns 4000 for the first round and
> > -22 for the second.
> > While running my test program on 3.10, it returns 4000 and then 0,
> > which is my expected behavior.
> >
> > Sorry for the brought misunderstanding.
> >
--
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR
