Am 23.01.2017 um 11:02 schrieb Peter Ludikovsky: >> Ich sehe das Problem nicht in der Verarbeitungsgeschwindigkeit der >> lokalen Mascnine, sondern in >> - Netzwerkverfügbarkeit zum Mitschnitt-Host >> - Netzwerkgeschwindigkeit zum Mitschnitt-Host >> - Verarbeitungsgeschwindigkeit des Mitschnitt-Hosts > > Diese Probleme wird es aber immer geben wenn du Daten über das Netzwerk > kopieren willst, und sogar zwischen lokalen Platten. Ja, und deswegen hätte mich interessiert, ob ich den Wald vor lauter Bäumen nicht sehe und es in Wirklichkeit $GANZ_EINFACH ist. > So weit ich weiß > gibt es für deine Anforderungen keine fertige Lösung. Korrigiere mich > bitte falls ich hier etwas vergessen/falsch verstanden habe: > > * Die Daten sollen auf einen 2. Server kopiert werden, ohne > Performance-Einbußen Oder eine zweite lokale Platte (USB, Firewire, whatever) *wenn sie angeschlossen ist*. Oder sonst $IRGENDWAS taugliches, wenn hier jemand einen passenden Vorschlag hat, der noch nicht genannt wurde. > * Die Daten sollen dabei ganz oder gar nicht kopiert werden Richtig, das ist einer der zentralen Knackpunkte bei der Sache. "Gar nicht" (natürlich mit entsprechender Meldung - die könnte man aber über Syslog o.ä. als Metadaten weitergeben) ist besser als unvollständig, weil man sonst nicht weiß, ob schon der Absender unvollständig angeliefert hat, oder ob die Daten nur deswegen Schrott sind, weil beim Mitschnitt die Zeit/der Platz ausging. Wobei die Teil-Anlieferung auf dem Mitschnitt-Host akzeptabel wäre, wenn dann irgendwie klar zu erkennen wäre, dass sie nicht den vollständigen angelieferten Daten entspricht. So was simples wie als Ziel-Dateiname "Dateiname.incomplete" zu haben und anschließendes "mv" zu "Dateiname" nur, wenn die Übertragung komplett ist, würde da schon reichen, denke ich. > * Das Tool soll erkennen ob die Netzwerkgeschwindigkeit zu langsam ist > & dann nicht kopieren > * Das Tool soll erkennen ob die Verarbeitungsgeschwindigkeit zu langsam > ist & dann nicht kopieren > * Dabei soll nicht mehr als 1 Kopie der Daten lokal vorgehalten werden > damit der RAM nicht zu voll wird [...] > Gibt es irgendeine Möglichkeit, wie der Ziel-Host erkennen könnte ob die > Daten komplett sind? Z.B. ein besonderer EOF-Marker, oder eine > eingebaute Prüfsumme? Sobald die Daten da sind können sie ja ohne Hektik > geprüft werden, zeit- und resourcenkritisch ist ja (wenn ich das richtig > verstanden habe) nur die Verarbeitung am Quell-Host. Den EOF-Marker gibt es schon an den Daten, die vom Absender kommen, aber es geht ja unter anderem auch darum, zu erkennen, ob der Absender die Datei komplett an das verarbeitende System übertragen hat oder nicht. Wenn ich schon Murks zur Verarbeitung angeliefert bekomme, möchte ich nicht erst noch lang rumrätseln müssen, ob das, was ich in meinem Debuglog als Murks sehe, Murks ist, der schon als Murks vom Absender kam, oder der von meinem verarbeitenden System verbrochen wurde bzw. auf dem Weg zum Mitschnitt-Host entstand. Eine eingebaute Prüfsumme gibt es nicht. Ich könnte versuchen, das verarbeitende System bei der Entgegennahme eine errechnen zu lassen, und die dann in die Metadaten (Syslog o.ä.) zu kippen. Dazu bräuchte ich wohl irgendwas analog tee, was die Daten von STDIN schnappt und ähnlich tee dann Richtung md5sum o.ä. schiebt, während sie 1:1 an STDOUT weitergehen. Gruß Stefan
Attachment:
signature.asc
Description: OpenPGP digital signature