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