Re: O_NONBLOCK is NOOP on block devices

[M vd S]

> mmap(2) / madvise(2) / mincore(2) may be a way around things (although 
> non-atomic), but I haven't tested it yet. It might also solve the 
> problem that started this thread, at least for the reading part of it. 
> Writing a small read() like function that operates through mmap() 
> doesn't seem too complicated. As for writing, you could use msync() 
> with MS_ASYNC to initiate a write. I'm not sure how to find out if a 
> write has indeed taken place, but at least initiating a non-blocking 
> write is possible. munmap() might then still block.

For the record I would like to share my very positive experience with 
the approach described. Thanks to 64 bit addressing you can mmap() an 
entire block device, and madvise() and mincore() work like you would 
expect them to. I haven't tried writing.

I also briefly tried aio_* and the libaio interface. The former is not 
really asynchronous - all requests are put in one separate thread where 
they will be executed in order, i.e. blocking, so you don't get any 
advantage from NCQ or data that was cached by the disk or the kernel. 
The latter apparently ends in an io_submit() which will block until all 
queued reads are finished, but I might have missed something there.

Imagine the orderly world in which O_NONBLOCK would make syscalls 
actually non-blocking...

Cheers,
M.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/