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