Re: tar und senden via ssh schlaegt fail

Am Mon, 27 Jun 2011 14:03:26 +1000
schrieb "Peter Ross" <Peter.Ross(at)bogen.in-berlin.de>:

> > Ich würde eher von Netzwerkproblemen ausgehen (ganz ehrlich gesagt;
> > irgendwelche Paketfiltereinstellungen? Socket-Timeouts? Seltsame
> > Netzwerkkonfigurationen?).
>
> Da ist nichts wirklich Exotisches. Ich benutze derzeit nur eine
> Broadcom-Karte, habe statische Routen, keinen Paketfilter, und der
> Kernel ist GENERIC.
>
> Natuerlich, da ich VirtualBox verwende, ist dafuer ein Kernelmodul da.

Hallo Peter,

ich habe das mit dem Netz nur angemerkt, weil man oft vergisst, dass
total triviale Sachen dazu führen können, dass man Daten nicht
übertragen kann. Ich hatte eher immer Netzwerkprobleme, wenn so ein
Szenario aufgetreten ist. Und dass als Fehlermeldung "out of memory"
kommt ist ebenfalls sehr oft irreführend. Und sogar Oliver, der
ein Speicherproblem vermutet, hat gesagt, dass write() keinen "out of
memory"-Fehler erzeugen kann.

Es war also nur ein Hinweis, erstmal triviale Sachen auszuschließen.
Netzwerk kann man vielleicht bei Dir so testen, dass man 200GB an Daten
aus /dev/random rübersendet (oder /dev/zero, aber dann sicherstellen,
dass Kompression bei ssh aus ist).

Außerdem merkt man Speichermangel eher schon früher als bei solchem
Backup. Da müssen sich doch Prozesse beschweren (oder wenigstens wird da
viel geswappt) und/oder der Rechner ist grundsätzlich instabil. Ein
einzelner madvise()-Error ist mir persönlich noch nicht genug, aber
könnte schon ein Hinweis sein.

ZFS würde ich grundsätzlich erst ab 4 GB einsetzen und erstmal schauen,
wie es sich verhält. Diesen Test mache ich auch immer und deswegen habe
ich mit Speicher dann eher keine Probleme.

VirtualBox nimmt ja auch zusätzlich Speicher ein, wenn es verwendet
wird. Das muss man von den verfügbaren GB dann abziehen.

Ich habe das aber auch vorhin so verstanden, dass Du tar NICHT auf den
ZFS-Dateisystemen ausführst. Deswegen gibt es da für ZFS eher keinen
Drang Speicher zu allozieren. Ich habe Dir ja auch dump anstatt tar
vorgeschlagen. Wenn ich wüsste dass es ZFS ist, dann würde ich eher "zfs
send" vorschlagen. Aber jetzt bin ich hier auch gar nicht mehr sicher.

> > Manche Leute haben auch Probleme gemeldet beim Mischbetrieb von ZFS
> > und UFS. Ich kann das bei mir nicht nachvollziehen.
>
> Weil Du kein UFS verwendest?

Etwas klarer ausgedrückt: ich verwende UFS und habe solche Probleme
nicht, deswegen kann ich das (=diese Aussagen) bei mir nicht
nachvollziehen.

> Ich habe das Rootsystem "bequemlichkeitshalber" auf UFS gelassen und
> mit sysinstall installiert, um kein ZFS-Root-Voodoo betreiben zu
> muessen.

Ich habe alles auf ZFS. Es hängt aber noch eine Backup-Platte drin
(nachträglich angeschlossen). Jetzt bin ich aber auch nicht so ganz
sicher, ob das mit dem ZFS eine gute Idee gewesen ist, denn kurz
nachdem ich es so installiert habe, wurde ich daran erinnert, dass ZFS
fragmentiert (und kein Tool zum Defragmentieren hat!). Ich habe hier
aber RAID1 auf ZFS laufen und das verhält sich im Falle des Falles
(Absturz, Fehlersituation) wahrscheinlich besser als gmirror. Deswegen
bleibe ich noch bei ZFS.

> Natuerlich hat ein UFS-freies System keinerlei UFS-Filebuffer, das
> mag die Aufgaben fuer dass Zusammenspiel mit ARC vereinfachen..

Ja klar. FreeBSD cacht viel und das ist auch gut so.

Eigentlich haben die Dokus und die FreeBSD-Entwickler bei mir den
Eindruck hinterlassen, dass man bei ZFS nicht mehr an Parametern tunen
muss mit amd64. Aber jetzt bin ich mir gar nicht mehr sicher, wenn ich
solche Probleme hier sehe und es ist tatsächlich am Ende der Speicher
schuld. In diesem Fall überlege ich auch, ob das mit ZFS bei mir auf dem
System überhaupt eine gute Idee ist. Ich habe lieber ein stabiles
System als etwas mehr Komfort und dafür aber innerlich die Sorge, dass
jeder Zeit das System um die Ohren fliegen kann.

Deswegen interessiert mich auch was dabei bei Dir herauskommt.

--
Martin

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Mon 27 Jun 2011 - 08:25:12 CEST