OpenPLi NFS opnames TEST workaround

[Gast MiLo]

Even een nieuw draadje gemaakt voor de NFS opname problemen in OpenPLi, die andere is zo vol nu met andere dingen.

 

Heb een workaround gevonden voor de OVERFLOW errors, vanuit een telnet sessie het volgende commando ingeven (kan alleen met telnet/ssh, niet met FTP ofzo!)

 

Code:

echo 300 > /proc/sys/vm/dirty_expire_centisecs

 

Dit wijzigt een kernel parameter en zorgt dat NFS data vaker geflusht wordt. Is nog niet grondig getest en onderzocht, maar hier kun je alvast mee experimenteren.

 

Nog een tip voor NFS mounts:

- Gebruik proto=tcp (niet UDP gebruiken dus)

- Laat de "rsize=...,wsize=..." parameters geheel weg. Het systeem heeft betere defaults!

 

(Als je geen idee hebt waar dit onderwerp over gaat, niet doen...)

[Tonskidutch]

Milo,

daar ik je andere bericht ook bekeken had, weet ik dat je op Ubuntu mount

wat is daar de standaard release versie van die distro zijn server

NFS4 of NFS3?

ciao

[Gast MiLo]

Bovenstaande fix lijkt alleen bij 1 opname te werken. Bij twee opnames gaat het dan juist vaker fout!

 

Ach, we zoeken weer verder...

[Gast MiLo]

Origineel bericht van: Tonskidutch

daar ik je andere bericht ook bekeken had, weet ik dat je op Ubuntu mount
wat is daar de standaard release versie van die distro zijn server
NFS4 of NFS3?

Ubuntu heeft NFS4, maar 3 wordt gebruikt omdat de dreambox niet hoger ondersteunt.

[Tonskidutch]

3 wordt gebruikt omdat de server weet welke client communiceert

of

omdat je die parameter opgeeft bij mounten?

 

ik weet zeker dat de client (dm nfsversie=3) niet meer kan

maar weet de server dan wel dat er een 3 versie tracht te mounten?

ciao

 

 

 

[Gast MiLo]

Een veel beter presterende settings is de volgende. Voor systemen zonder harddisk is een waarde van 1 of zelfs 0 een prima optie, dan wordt data zo snel mogelijk weggeschreven.

 

Voor systemen met een harddisk die zelden opnamen naar het netwerk raad ik, na wat experimenteren, een waarde van 5 aan.

 

Gemengde systemen, dus die opnames naar een NAS en naar een (interne) disk maken, zou ik aanraden om de waarde "1" te gebruiken zoals in onderstaand voorbeeld.

 

 

Vanuit een telnet sessie het volgende commando ingeven (kan alleen met telnet/ssh, niet met FTP ofzo!)

 

Code:

echo 1 > /proc/sys/vm/dirty_background_ratio

 

Dit wijzigt een kernel parameter en zorgt dat NFS data vaker geflusht wordt.

 

Met deze instelling lukte het mij om gelijktijdig 4 HD opnames te hebben lopen op een NFS server.

 

Na een reboot is deze instelling overigens weer gereset naar de default waarde 10.

[JkV]

Misschien een menukeuze in de instellingen hiervan maken?

Opnemen naar net werk ja/nee

[Gast MiLo]

Morgen online updaten, dan is de structurele update er.

[rlckring]

Is het een quik and dirty oplossing of is het echt opgelost?

 

Als ik deze reactie lees op : Pli Forum

 

Zou ik denken dat het echt opgelost is en dat er geen verdere aandacht meer aan besteed hoeft te worden..

[Gast MiLo]

Wat ikzelf hier tot dusver mee heb kunnen testen, is het probleem hiermee echt opgelost. Met een aantal lopende HD opnames naar NFS en de kernel parameters zo 'ongunstig' mogelijk, zodat er eens in de 20 seconden een grote brok data wordt geschreven (wat op zich een goede eigenschap kan zijn, natuurlijk), treden geen OVERFLOW fouten (zie je als 'hik' in de opname) meer op.

 

Morgen leren we denk ik of de theorie en praktijk ook overeenstemmen

[Neptunus]

Ik heb het nu ongeveer een week op CIFS staan en dat draait zo goed dat ik geen reden kan bedenken terug te gaan naar NFS, op de DM8000 en de VU+Duo meerdere HD opnames tegelijk gemaakt, geen problemen behalve wat korte hicks die er vroeger ook al inzaten en die vermoedelijk worden veroorzaakt als er een andere opname start of stopt.

[Gast MiLo]

Ik denk dat na de update ook een helehoop andere "hik" problemen zijn opgelost die helemaal niets met NFS te maken hebben. Het probleem zelf had tenslotte ook niets met NFS te maken, maar trad alleen prominent op met NFS omdat die nogal in de kernel verweven zit.

 

Goede kans dat bijvoorbeeld timeshift op een CF kaart nu wel soepel werkt, dat het starten of wissen van een opname geen hik meer veroorzaakt in een lopende opname en dat je op een 7025 nu gewoon naar een USB stick kan opnemen. Dat zijn dingen die ik nog niet geprobeerd heb...

[Neptunus]

Zijn er inmiddels al bevindingen uit te praktijk te melden?

[vGnp]

Origineel bericht van: MiLo

Ik denk dat na de update ook een helehoop andere "hik" problemen zijn opgelost die helemaal niets met NFS te maken hebben. Het probleem zelf had tenslotte ook niets met NFS te maken, maar trad alleen prominent op met NFS omdat die nogal in de kernel verweven zit.

Goede kans dat bijvoorbeeld timeshift op een CF kaart nu wel soepel werkt, dat het starten of wissen van een opname geen hik meer veroorzaakt in een lopende opname en dat je op een 7025 nu gewoon naar een USB stick kan opnemen. Dat zijn dingen die ik nog niet geprobeerd heb...

Kan dit ook een (de) oplossing zijn voor het zo nu en dan "hikken" van
het beeld tijdens normaal kijken, of staat dit daar volledig los van?

vGnp

[Gast MiLo]

NEe, de wijziging beinvloedt alleen opnames.