Re: Block layer question - indicating EOF on block devices

[Andrew Morton <akpm@osdl.org>]

Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>
> How is a block device meant to indicate to the block layer that the read
> issued is beyond EOF. For the case where the true EOF is known the
> capacity information is propogated into the inode and that is used. For
> the case where a read exceeds the known EOF the block layer sets BIO_EOF
> which appears nowhere else I can find.
> 
> I'm trying to sort out the case where the block device has only an
> approximate length known in advance. At the low level I've got sense
> data so I know precisely when I hit the real EOF on read. I can pull
> that out, I can partially complete the request neatly up to the EOF but
> I can't find any code anywhere dealing with passing back an EOF.

If the driver simply returns an I/O error, userspace should see a short
read and be happy?

> Nor it turns out is it handleable in user space because a read to the
> true EOF causes readahead into the fuzzy zone between the actual EOF and
> the end of media.

Yup.  You can turn the readahead off with posix_fadvise(POSIX_FADV_RANDOM),
or just read the disk with direct-io.  The latter has the advantage that
you can freely pluck out single 512-byte sectors without pagecache causing
any additional reads.

> Currently I see the error, pull the sense data, extract the block number
> and complete the request to the point it succeeded then fail the rest,
> but this doesn't end the I/O if someone is using something like cp,

hm.  Either cp is being silly or we're not propagating the error back
correctly.  `cp' should see the short read and just handle it.

> and
> it also fills the log with "I/O error on" spew from the block layer
> innards even if REQ_QUIET is magically set.

We'd need to propagate that quietness back up to the buffer_head layer, at
least.