Marko M?kel? wrote: >>So I read about the usage of O_DIRECT and the trouble with it. > > Is there a summary of the problems somewhere? I've heard of Linux > file system corruption in heavy database use (MySQL/InnoDB), but I'm > not sure if there have been cases that have been tracked down to > the use of O_DIRECT. I guess O_DIRECT won't work on NFS, but it > would be a very bad idea to run a database on NFS anyway. 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. > 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. I would be really happy to simplify the code if you can prove me wrong. 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. Ralf
