vor Aufnahme Festplatte "aufwecken"

[Tommy]

Hi All,

gibt es eine möglichkeit +-30sek vor der Aufnahme einen Lesezugriff o.ä. auf das NFS Share auszuführen? Die HD in meinem NFS Server schafft es meist nicht schnell genug "aufzuwachen"
Vieleicht könnte man dies ja auch parallel mit dem WOL machen und die Fehlermeldung (bei nicht vorhandenem Share) irgendwie abfangen.

Gruß,
Tommy

[starbright]

Bemüh mich auch diese Sache auf die tagesordnung zu bekommen.
Schadet doch nichts vor Zugriffen (sei es durch Aufnahme, Wiedergabe, Bildbetrachter) "vorsichtshalber" ein WOL zu senden und es bei Mißerfolg, weil Rechner noch down oder Platte im Tiefschlaf, nach einer gewissen (optimalerweise einstellbaren) Zeit noch mal zu versuchen und erst dann wirklich aufzugeben.
Puhh - langer Satz, hoffe trotzdem verständlich.
Steff

[chkbox]

Hi All,

gibt es eine möglichkeit +-30sek vor der Aufnahme einen Lesezugriff o.ä. auf das NFS Share auszuführen? Die HD in meinem NFS Server schafft es meist nicht schnell genug "aufzuwachen"
Vieleicht könnte man dies ja auch parallel mit dem WOL machen und die Fehlermeldung (bei nicht vorhandenem Share) irgendwie abfangen.

Gruß,
Tommy

Was genau passiert denn? Du willst aufnehmen und die Platte ist noch nicht hochgefahren und dann?

[Tommy]

...dann klappt es manchmal und manchmal habe ich zwei files (momentan noch mit 4min Pause - habe das 4sek image noch nicht aufgespielt ) Scheinbar ist die Gesamtpuffergröße Ringbuffer? und der meines Servers nicht groß genug um den Datenstrom solange aufzunehmen?!

ein einfaches "ls" 30sek vorher würde ja vieleicht schon reichen oder ein kleines file schreiben und gleich wieder löschen ?!

[Rudi Ratlos 4711]

Also soweit das von IDE-Entwicklerseite bekannt ist (von denen die "Urversion" vom Datei-Streaming stammt), legen wir generell ein Dummyfile an vor der eigentlichen Aufnahme mit dem FSYNC Flag, was sicherstellt, daß dieses File auch tatsächlich geschrieben worden ist (= Platte wird auf jeden Fall aufgeweckt).

Das File entspricht IIRC von der Größe der Ringbuffersize.

Dieses wird danach wieder gelöscht und die Aufnahme beginnt.

Wenn dein NFS Server das FSYNC Flag ignoriert, und die Daten vom Dummyfile cached, geht das in die Hose.

Aber mit der internen HDD ging das Problemlos.

Evtl. mal nen anderen NFS Server testen.

RR4711

[gagga]

Wird das zweite File denn geschrieben? Oder schlägt das auch fehl?

[Tommy]

Wird das zweite File denn geschrieben? Oder schlägt das auch fehl?

Ja, es läuft dann auch super durch. Das erste File ist meist 1-10MB groß und enthält einen "Filmfetzen" . Das 2. File wird dann bis Timerende super aufgenommen. Es ist durchaus möglich das File wegge"swaped" wird. Wie kann man Linux bzw dem NFSServer (fsync Flag) sowas abgewöhnen?

Übrigens, der Movieplayer kommt auch ins stocken wenn die HD aufwacht - es hilft dann nur <gelb><gelb> (stop/start) dann kriegt er sich wieder ein

@Rudi Ratlos 4711:
Anderer NFSServer ist nicht so leicht bei Eisfair ;-) - da gibbets nur einen

[gmo18t]

Hi,

hier ein Auszug aus dem linux nfs howto, der weiterhelfen könnte:

...

5.9. Synchronous vs. Asynchronous Behavior in NFS

The default export behavior for both NFS Version 2 and Version 3 protocols, used by exportfs in nfs-utils versions prior to Version 1.11 (the latter is in the CVS tree, but not yet released in a package, as of January, 2002) is "asynchronous". This default permits the server to reply to client requests as soon as it has processed the request and handed it off to the local file system, without waiting for the data to be written to stable storage. This is indicated by the async option denoted in the server's export list. It yields better performance at the cost of possible data corruption if the server reboots while still holding unwritten data and/or metadata in its caches. This possible data corruption is not detectable at the time of occurrence, since the async option instructs the server to lie to the client, telling the client that all data has indeed been written to the stable storage, regardless of the protocol used.

In order to conform with "synchronous" behavior, used as the default for most proprietary systems supporting NFS (Solaris, HP-UX, RS/6000, etc.), and now used as the default in the latest version of exportfs, the Linux Server's file system must be exported with the sync option. Note that specifying synchronous exports will result in no option being seen in the server's export list:


Export a couple file systems to everyone, using slightly different options:

# /usr/sbin/exportfs -o rw,sync *:/usr/local
# /usr/sbin/exportfs -o rw *:/tmp



Now we can see what the exported file system parameters look like:

# /usr/sbin/exportfs -v
/usr/local *(rw)
/tmp *(rw,async)



If your kernel is compiled with the /proc filesystem, then the file /proc/fs/nfs/exports will also show the full list of export options.

When synchronous behavior is specified, the server will not complete (that is, reply to the client) an NFS version 2 protocol request until the local file system has written all data/metadata to the disk. The server will complete a synchronous NFS version 3 request without this delay, and will return the status of the data in order to inform the client as to what data should be maintained in its caches, and what data is safe to discard. There are 3 possible status values, defined an enumerated type, nfs3_stable_how, in include/linux/nfs.h. The values, along with the subsequent actions taken due to these results, are as follows:


NFS_UNSTABLE - Data/Metadata was not committed to stable storage on the server, and must be cached on the client until a subsequent client commit request assures that the server does send data to stable storage.

NFS_DATA_SYNC - Metadata was not sent to stable storage, and must be cached on the client. A subsequent commit is necessary, as is required above.

NFS_FILE_SYNC - No data/metadata need be cached, and a subsequent commit need not be sent for the range covered by this request.

In addition to the above definition of synchronous behavior, the client may explicitly insist on total synchronous behavior, regardless of the protocol, by opening all files with the O_SYNC option. In this case, all replies to client requests will wait until the data has hit the server's disk, regardless of the protocol used (meaning that, in NFS version 3, all requests will be NFS_FILE_SYNC requests, and will require that the Server returns this status). In that case, the performance of NFS Version 2 and NFS Version 3 will be virtually identical.

If, however, the old default async behavior is used, the O_SYNC option has no effect at all in either version of NFS, since the server will reply to the client without waiting for the write to complete. In that case the performance differences between versions will also disappear.

Finally, note that, for NFS version 3 protocol requests, a subsequent commit request from the NFS client at file close time, or at fsync() time, will force the server to write any previously unwritten data/metadata to the disk, and the server will not reply to the client until this has been completed, as long as sync behavior is followed. If async is used, the commit is essentially a no-op, since the server once again lies to the client, telling the client that the data has been sent to stable storage. This again exposes the client and server to data corruption, since cached data may be discarded on the client due to its belief that the server now has the data maintained in stable storage.
...

- GMo -

[chkbox]

Wird das zweite File denn geschrieben? Oder schlägt das auch fehl?

Ja, es läuft dann auch super durch. Das erste File ist meist 1-10MB groß und enthält einen "Filmfetzen" . Das 2. File wird dann bis Timerende super aufgenommen. Es ist durchaus möglich das File wegge"swaped" wird. Wie kann man Linux bzw dem NFSServer (fsync Flag) sowas abgewöhnen?

Übrigens, der Movieplayer kommt auch ins stocken wenn die HD aufwacht - es hilft dann nur <gelb><gelb> (stop/start) dann kriegt er sich wieder ein

@Rudi Ratlos 4711:
Anderer NFSServer ist nicht so leicht bei Eisfair ;-) - da gibbets nur einen

Hast du mal einfach eine längere Vorlaufzeit ausprobiert? Wenn die 2. Datei OK ist, dann probier doch einfach mal 5 min vorher starten zu lassen. Dann sollte die eigentliche Aufnahme in der 2. landen und somit OK sein.

[Tommy]

@gmo:

das würde also heißen wenn ich das share in der "exports" mit sync statt async bereitstelle wird das temporäre file (Beitrag Rudi Ratlos) deffinitiv auf die Platte geschrieben?
Momentan habe ich in der "exports" nämlich async (wurde für TS streaming an sich empfohlen).

Ich teste das heute abend mal - werde ja sehen ob die Platte eher anspringt

@chkbox:
wäre zwar ein workaround trägt aber nicht zur übersichtlichkeit im Filebrowser bei

[Frockert]

Hi,

ich habe, glaube ich, das gleiche Problem.

Ebenfalls schlafende Festplatte.

http://forum.tuxbox-cvs.sourceforge.net ... highlight=

Ich bin wieder auf Image 21.05.04 zurück, nun funktionieren die Aufnahmen wieder.



Gruß Frockert

[Tommy]

hast Du in der "exports" Deines NFS servers sync oder async? - kann's leider nicht testen @work

[Treito]

hast Du in der "exports" Deines NFS servers sync oder async? - kann's leider nicht testen @work

Ich kanns bei mir leider nicht testen, da meine Server-Platte ne kleine Macke hat, die fährt ab und an nicht von alleine hoch.
@Tommy Musst Du denn zwingend die Festplatte schlafen schicken?

[Tommy]

yepp - der server ist immer an wird aber nur für Aufnahme (30-180min/d) genutzt. Deshalb wird sie nach 2min ohne aktivität einfach abgeschaltet. Spart massen strom und ist glaub ich schonender als dauerlauf?!

WOL ist nicht möglich da AT

[Frockert]

hast Du in der "exports" Deines NFS servers sync oder async? - kann's leider nicht testen @work

Wenn Du mich meinst:

/daten (rw,all_squash,anongid=100,anonuid=500)

Gruß Frockert

[Tommy]

@Frockert:

also weder sync noch async - grübel - however ich habe bei mir async mit drin und das werde ich heute abend man auf sync ändern.

[Treito]

hast Du in der "exports" Deines NFS servers sync oder async? - kann's leider nicht testen @work

Wenn Du mich meinst:

/daten (rw,all_squash,anongid=100,anonuid=500)

Gruß Frockert

Das ist aber eine nicht ganz saubere exports (laut man)
Ab Kernel 2.4 war async dann default, wenn ich mich jetzt nicht irre
Wie sehen Deine Box-Optionen aus?

[Frockert]

network_nfs_mount_options_1=rw,soft,tcp
network_nfs_mount_options_2=nolock,rsize=8192,wsize=8192

Gruß Frockert

[Treito]

network_nfs_mount_options_1=rw,soft,tcp
network_nfs_mount_options_2=nolock,rsize=8192,wsize=8192

Gruß Frockert

könntest bei exports und bei der d-box noch sync/async (musst du mal testen) probieren.

[Tommy]

@ Treito:

habe die Box defaults nur auf "rw" geändert

[Frockert]

network_nfs_mount_options_1=rw,soft,tcp
network_nfs_mount_options_2=nolock,rsize=8192,wsize=8192

Gruß Frockert

könntest bei exports und bei der d-box noch sync/async (musst du mal testen) probieren.

Mit dem Image vom 21.05.04 (wie oben beschrieben) habe ich bei gleichen Einstellungen keine Probleme.


Heute habe ich im Laufe des Tages 5 Sendungen per Timer erfolgreich aufgenommen.

Bei neueren Images gab es Stress bei mir.



Gruß Frockert

[Treito]

network_nfs_mount_options_1=rw,soft,tcp
network_nfs_mount_options_2=nolock,rsize=8192,wsize=8192

Gruß Frockert

könntest bei exports und bei der d-box noch sync/async (musst du mal testen) probieren.

Mit dem Image vom 21.05.04 (wie oben beschrieben) habe ich bei gleichen Einstellungen keine Probleme.


Heute habe ich im Laufe des Tages 5 Sendungen per Timer erfolgreich aufgenommen.

Bei neueren Images gab es Stress bei mir.



Gruß Frockert

Habe das Yadi-Image vom 27. drauf, davor JtG vom 19.06. keine Probleme bei mir, allerdings kann ich wie gesagt meine Platte auch nicht schlafen schicken...

[Tommy]

Moin,

also ich habe den sync modus mit der exports aktiviert. bei Aufnahme geht die CPU last auf 50-80% (async 8%) und die HD ist nur am rödeln. Aller 30 sek bekomme ich ein Streamabbruch (Daten können nicht schnell genug geschrieben werden)

Es ist möglich das dafür mein Server echt zu schwach auf der Brust ist. Da es aber bei "async" wenigstens keinen Abbruch gibt ist dies die einzige Lösung für mich

Also soweit das von IDE-Entwicklerseite bekannt ist (von denen die "Urversion" vom Datei-Streaming stammt), legen wir generell ein Dummyfile an vor der eigentlichen Aufnahme mit dem FSYNC Flag, was sicherstellt, daß dieses File auch tatsächlich geschrieben worden ist (= Platte wird auf jeden Fall aufgeweckt).

Das File entspricht IIRC von der Größe der Ringbuffersize.

Ist es möglich dieses File zu vergrößern, damit es unabhängig vom Fsync Flag die Platte anwirft? (wenn einfach der Cache des Servers überläuft)

Gruß,
Tommy

[Treito]

Moin,

also ich habe den sync modus mit der exports aktiviert. bei Aufnahme geht die CPU last auf 50-80% (async 8%) und die HD ist nur am rödeln. Aller 30 sek bekomme ich ein Streamabbruch (Daten können nicht schnell genug geschrieben werden)

Es ist möglich das dafür mein Server echt zu schwach auf der Brust ist. Da es aber bei "async" wenigstens keinen Abbruch gibt ist dies die einzige Lösung für mich

Also soweit das von IDE-Entwicklerseite bekannt ist (von denen die "Urversion" vom Datei-Streaming stammt), legen wir generell ein Dummyfile an vor der eigentlichen Aufnahme mit dem FSYNC Flag, was sicherstellt, daß dieses File auch tatsächlich geschrieben worden ist (= Platte wird auf jeden Fall aufgeweckt).

Das File entspricht IIRC von der Größe der Ringbuffersize.

Ist es möglich dieses File zu vergrößern, damit es unabhängig vom Fsync Flag die Platte anwirft? (wenn einfach der Cache des Servers überläuft)

Gruß,
Tommy

bei mir laufen 2 Prozesse mit insgeasmt 2,3 - 2,7 % CPU-Last (async). Was für einen Rechner hast Du denn?

[Tommy]

bei mir laufen 2 Prozesse mit insgeasmt 2,3 - 2,7 % CPU-Last (async). Was für einen Rechner hast Du denn?

...als NFS Server einen P200@120MHZ unter Eisfair Linux ...