On Tue, Aug 23, 2005 at 09:00:14PM +0200, Ralf Müller wrote:
Actually I meant the trouble with programming. It is a difference to align all buffers to 512 bytes and read/write in 512 byte blocks instead of just reading and writing what you want. This is especially true for programs which have not been designed this way from the very beginning. I first started to do a patch based on O_DIRECT - this would have been much more intrusive.
I see, you would need to introduce a buffering layer.
Hmm, is there a reason why your WriteStream function doesn't simply do posix_fadvise(fd, 0, 0, POSIX_FADV_DONTNEED)? That would simplify the logic, and if I understood correctly, it should work equally well, except with some early 2.5 kernels. I understand that you will need to keep track on the offsets in ReadStream because of read-ahead.
It seemed to me that different streams interfere with each other. So the posix_fadvise() of a recording thread seemed to kill the read ahead buffer of a player thread for the same recording - very annyoing.
Sorry, I didn't think of that.
Another nice thing to have would be a way to tell the kernel to forget dirty buffers after they have been written to disc without the need to call fdatasync() before. The forced sync definitly is less then optimal.
In theory, this could be solved by writing a write completion callback function that would invoke posix_fadvise(), but this asynchronous I/O would be a real overkill. As far as I know, aio (asynchronous I/O) is only available in 2.6 series kernels (and perhaps some Red Hat 2.4 kernels).
Marko