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
