[vdr] cUnbufferedFile and NFS mounted video dir

[Klaus Schmidinger]

Artur Skawina wrote:
> Klaus Schmidinger wrote:
> 
>> Artur Skawina wrote:
>>
>>> However i consider the whole patch a bugfix :) Now that the fsyncs 
>>> are disabled it probably isn't that critical though.
>>
>>
>> So does this mean that without the fdatasync() calls it works ok as
>> it is in plain vanilla VDR (without any patch)?
> 
> 
> As I haven't run vdr w/o this patch for a long time, i'm not sure. 
> Apparently
> things are not ok, as this thread shows, but other vdr-1.3.38+ users 
> with a 2.6
> kernel could answer the above question better...
> For me it was the sync calls that made me look at this code; w/o them 
> things
> weren't as bad, IIRC. I ended up disabling the fdatasyncs completely 
> even when
> using fadvise.
> 
>> What is the exact meaning of the "WriteStrategy" option?
>> Does it simply turn the fadvise stuff on/off, or is there more
>> magic behind it? I would prefer a version that works without this
>> option, because this is nothing a normal user would easily know
>> how to set.
> 
> 
> it started as a debugging knob, so i could test the impact of the sync 
> calls,
> compare cutting speed w/ fadvise on/off etc.
> (Setup.WriteStrategy==1) meant no POSIX_FADV_DONTNEED calls while 
> accessing a
> file (the calls were always made when closing a file).
> 
>> So, if you can provide a patch against the latest VDR version that
>> still uses "#ifdef USE_FADVISE" to completely turn the fadvise
>> stuff off, and does _not_ introduce another setup option, I might
>> consider including it for the final version 1.4.
> 
> 
> 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 guess I'll leave everything as it is right now, until there is
a common consensus about the optimum solution (which will no require
any setup options - it might automatically adapt to different
situations, like local file, NFS etc.). All file access is
hidden inside cUnbufferedFile, so people can test whatever patches
they like. Basically plain simple write()/read() calls should be handled
gracefully by any file system, so the sole benefit from cUnbufferedFile
would be not to clutter the file system cache, but that's probably
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.

Klaus

> and i suspect there are cases where the fadvise-enabled version
> isn't necessarily an improvement. An option which basically turns 
> USE_FADVISE into a runtime switch would be useful.
> As i haven't needed the option myself lately, in fact didn't even 
> remember what
> exactly it did and had to check the code, i just killed it, patch attached.
> It's vs 1.3.39 because the UI/channel-switch posts scared me away from 
> upgrading
> vdr, still remembering the broken menu key experience... ;)
> cutter.c part is entirely optional (affects only cutting speed).
> 
> artur