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
