On 01/23/2017 11:35 AM, Stefan Baur wrote:
> 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
>
Dann wäre interessant, wie die Pipeline aussieht. Wie kommen die Daten
an, wie werden sie verarbeitet, wie werden sie weitergeschickt. Wenn das
eine Kette von scp -> Shell Script -> scp ist dann wird das leichter als
wenn alles in einer kompilierten Applikation abläuft. Und gerade mit dem
.incomplete z.B. lässt sich meine erste Bash-Idee passend abwandeln:
(
cp <src> <dst>.incomplete && \
mv <dst>.incomplete <dst>
) & # Job im Hintergrund starten /
# "fork()"
bpid=$! # Background-PID speichern
( sleep 10; kill -9 ${bpid} && \
logger -p local0.error "Error copying"
) & # Wenn nach 10 Sekunden cp nicht
# fertig ist -> Abbruch m. Meldung
Damit werden die Daten im Hintergrund kopiert (auf Festplatte, Netzwerk,
whatever) und erst umbenannt wenn komplett kopiert wurde, ansonsten
bleibt ein .incomplete Datei. Nachdem das mv innerhalb eines FS atomic
ist sollte es hier auch keine Probleme geben. Der Check ob das Ziel ein
gültiger Mount ist überlasse ich dem Leser :)
Lg
/peter
Attachment:
signature.asc
Description: OpenPGP digital signature