Klaus Schmidinger wrote: > Artur Skawina wrote: >> i did the minimal fix to the existing vdr code -- note it's far from >> optimal, > > Well, this is pretty much the killer argument against including it for > version 1.4, I'm afraid. I probably should have been more specific wrt the "far from optimal" part -- it's about the Read() calls only. The Write() part, which is what this thread was about, and what caused me to make the patch in the first place, is working perfectly AFAICT. IOW simply omitting all of the the USE_FADVISE Read() code (making it basically a simple safe_read() again) would be a safe fix; see below however. The problem with the read side is that the uncaching is much too aggressive, and while it works when there's no IO load, it causes large delays when replaying a file while some other disk activity is going on. This is what the comment block above cUnbufferedFile::Read was referring to. While testing yesterdays patch i accidentally found a way to reliably trigger the problem and verified that disabling fadvice in Read() makes the delays go away. Will replace the complicated read() accounting with much simpler version and post a patch later today. > gracefully by any file system, so the sole benefit from cUnbufferedFile > would be not to clutter the file system cache, but that's probably much smoother writes is another benefit, and one, once gotten used to, even more valuable. > no longer such a big problem since VDR caches the recordings data > and thus can bring up the Recordings menu immediately, even if > recordings are currently being made. in the NFS case rereading the dir tree takes quite some time (eg ~8s here) even when it's fully cached on both nfs client and server -- so caching it internally helps a lot. artur
