Messages in this thread | | | Date | Tue, 30 Nov 2004 18:43:45 -0800 | From | Andrew Morton <> | Subject | Re: Block layer question - indicating EOF on block devices |
| |
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. - 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/
| |