[Sammelthread] ZFS Stammtisch

[kandamir]

So, nochmal eine Rückmeldung. Da zfs das Umbenennen von Snapshots ja offensichtlich nicht vorsieht, habe ich auf dem Quellsystem einen den Namenskonventionen entsprechenden Snapshot angelegt, diesen einmalig von Hand auf‘s Zielsystem repliziert und anschließend den unter Napp-It erstellten Replikations-Job einmal manuell ausgeführt. Das hat sehr gut geklappt.

Hilfreich war hier noch das entsprechende Kapitel der Napp-It Dokumentation (napp-it.pdf), wo die Bestandteile des Snapshot-Namen aufgeschlüsselt sind - da hatte ich nämlich noch offene Fragen, die mit Hilfe der Doku aber beantwortet wurden. Hier vielleicht aber noch der Hinweis, dass man da im Handbuch ganz schön suchen muss, um die gesuchte Info zu finden. Im Kapitel 17 Data replikation/availabilty ist dazu nix zu finden, erst im Kapitel, 24.5 findet man diese Infos. Leider über‘s Inhaltsverzeichnis nicht zu finden, weil dort nur die erste Kapitelebene dargestellt ist und zumindest ich nicht darauf gekommen wäre, unter „napp-it Free vs. Pro & Extensions nach der Namenskonvention von Replikations-Jobs zu suchen. ;-)

@gea, vielleicht könntet Ihr da mal etwas Zeit investieren, um das Handbuch etwas besser zu strukturieren - oder einfach nur die Unterkapitel im Inhaltsverzeichnis aufzuführen und auf jeder Seite im Seitenkopf darstellen, welches Kapitel hier behandelt wird. Das würde die Navigation durch‘s Handbuch deutlich verbessern. ;-) Das soll aber nicht als Meckern gemeint sein, eher als gut gemeinte Anregung. Denn Im Handbuch stehen doch eine ganze Menge Informationen, die sehr nützlich sein können (Lob!) und es wäre schön, wenn man die auch leicht finden könnte.

So, mit einem Filesystem hat das geklappt, nun ist der Rest dran. Da vielleicht noch eine Frage: Den Offsite-Backup-Server möchte ich i.d.R. nur für ein wöchentliches Offsite-Backup verwenden. Dazu möchte ich ihn ungerne 7x24 laufen haben, sondern eigentlich nur einmal wöchentlich, wenn das Backup ansteht. Das Einschalten bekomme ich den Backup-Server mittels IPMI / ipmitool. Frage: gibt‘s eine Möglichkeit, dass der Backup-Server, der sich das Backup ja vom Quellserver zieht, nach Abschluss aller anstehenden Replikationen selbst geordnet herunterfährt? Da im Backup-Server keine NAS- oder Serverplattem hängen, sollte das wöchentlichen Hoch- und Herunterfahren kein Problem sein.

Danke und einen schönen Sonntagabend noch!

 

[gea]

snap umbenennen ist kein Problem z.B.
zfs rename tank/data@1 tank/data@2

remote up/down per ipmi
siehe script /var/web-gui/_log/jobs/other_job_examples/remote_up_down_ipmi.pl

dazu kann man in /var/web-gui/_log/jobs/
Dateien jobid.pre oder jobid.post anlegen. Das sind Shellscripte die vor/nach einer Replikation ausgeführt werden um sowas zu automatisieren.

Handbuch napp-it se
genau wie bei napp-it cs auf der todo list

 

[BobbyD]

Erzeugt ZFS eine deutlich höhere Schreiblast als NTFS oder Ext4 (z.B. auf SSDs)? Hab das neulich aufgeschnappt, aber verstanden habe ich es nicht.

 

[gea]

Ja, aus zwei Gründen
- zusätzliche Prüfsummen auf Daten und Metadaten
- Copy on Write (Write Amplification)
Mit Copy on Write wird beim Ändern von Haus in Maus in einer größeren Datei nicht nur das eine Byte geändert sondern ein ganzer Datenblock in recsize neu geschrieben (mit recsize=1M also 1M für ein Byte)

Ersteres will man nicht missen wegen der Echtzeitvalidierung, zweiteres nicht weil nur damit können atomare Writes garantiert werden um ein defektes Dateisystem oder Raid durch Absturz beim Schreiben zu vermeiden. Snaps gibts kostenlos dazu.

 

[BobbyD]

@gea Nun schreiben ja SSDs eh immer "Pages", keine Ahnung wie groß die im Schnitt sind. Und wenn ich die Block-Size oder wie auch immer das heißt bei NTFS recht groß habe, habe ich dann nicht einen ähnlichen Effekt auf die Schreiblast?

 

[pwnbert]

Naja, ist halt die Frage, was man machen will.

Imho isses nicht verkehrt EXT4, XFS oder sowas zu verwenden, wenns der Zweck "zulässt"... also wenn man keine Snapshots braucht, wenn COW egal ist usw...
Also angenommen du hast ein Programm, das viel rumrechnet und rumschreibt, welches aber nicht kritisch ist beim Verlust (keine Snaps erfordert), dann kann man das imho schon auf EXT4 oder XFS machen...?
Alles was halt so unter die Kategorie "Testlauf" fällt... und kein "stabiler Betrieb mit gesicherter Uptime" sein muss.

@gea Nun schreiben ja SSDs eh immer "Pages", keine Ahnung wie groß die im Schnitt sind. Und wenn ich die Block-Size oder wie auch immer das heißt bei NTFS recht groß habe, habe ich dann nicht einen ähnlichen Effekt auf die Schreiblast?

Google nach "Write Amplification", gibt dafür einen ganzen Haufen abhandlungen... in einem 3-Zeiler ist das schwer erklärt. Im Grund hats gea eh schon zusammengefasst.

 

[gea]

Die Organisation der SSD in Pages die zu Blocks zusammengefasst sind hat seine eigene Write Amplifikation zur Folge da beim Ändern einer Page zuvor der ganze Block gelöscht und neu beschrieben werden muss. Das sind auch gerne 512K per Block.

Die Allocation Unit Size unter ntfs hat ähnliche Auswirkung wie recsize bei ZFS. Eine kleine AUS wie 4K schreibt kleine Files platzeffizienter mit weniger "Verschnitt", ist dafür langsamer als eine AUS von 64K.

 

[BobbyD]

Die Allocation Unit Size unter ntfs hat ähnliche Auswirkung wie recsize bei ZFS.

Dann wäre es aber kein nennenswerter Unterschied mehr. Und checksum dürften jetzt auch nicht so wesentlich sein, vermutlich Promille. So wie ich das lese, ist der Unterschied also eher marginal? Wo ist mein Denkfehler...

Beitrag automatisch zusammengeführt: Montag um 17:31

Die Organisation der SSD in Pages die zu Blocks zusammengefasst sind hat seine eigene Write Amplifikation zur Folge

Ja und nein, wenn das Dateisystem das eh auch macht, dann würde sich das zumindest nicht summieren sondern eher keine Roll spielen, solange das quasi "alignt" ist.

 

[gea]

Write Amplifikation ist kein Entscheidungskriterium sondern Folge einer Systementscheidung oder einer Tuningoptimierung. ZFS wählt man ja deshalb weil es die Option mit den meisten Features ist die gleichzeitig jede denkbare Ursache für Datenverlust adressiert (bis auf Hard/Softwareprobleme und human error). Ältere Dateisysteme bieten diese Sicherheit nicht. Auch muss man zunächst die Defaults berücksichtigen wie recsize=128K vs AUS=4K. Hinzukommt dass recsize bei kleinen Files dynamisch schrumpft, AUS nicht. ZFS ist also so schlecht auch nicht wenn man nur Amplifikation betrachtet.

Bei SSD muss man Amplifikation vs Performanance sehen. Für Performance gibts Trim und Garbage Collection. Amplifikation ist unvermeidbare Folge der Flash Technik.

 

[BobbyD]

die Defaults berücksichtigen wie recsize=128K vs AUS=4K.

Sprich, dies macht noch den größten Unterschied zu Ungunsten von ZFS gegenüber NTFS aus? Dann könnte man den Parameter ggf. im Vorfeld anpassen. Kann ich die Writes (z.B. eines Logfiles) auch nur im RAM cachen, bis eine ordentliche Größe bei rauskommt oder würde das der "Daten-Sicherheit von ZFS" widersprechen, vermutlich letzteres. Das wäre bei NTFS allerdings wohl auch nicht anders.

Ich überlege halt, Proxmox mal komplett mit ZFS aufzusetzen, habe aber keine Lust, dass mir das die SSD kaputt schreibt. Snapshots gibt es ja auch mit LVM-Thin und EXT4 und um meine Daten mache ich mir eher keine großen Sorgen. Heißt vermutlich, ich sollte besser bei EXT4 bleiben. Ich will auch keinen Tired Storage oder andere zusätzliche Hardware verbauen. Nur gegen unsicheres RAM-Caching von Writes hätte ich tatsächlich nichts.

 

[gea]

Die Auswahl-Kriterien für recsize und AUS sind nicht Amplifikation sondern Performance und use case.

ZFS sammelt immer alle writes im RAM Schreibcache um kleine writes zu vermeiden.
Will man nicht dass der Cache beim Crash verloren geht, muss man ZFS sync aktivieren.
(Für VM Storage sehr empfehlenswert)

Ext4 und ntfs haben auch RAM Schreibcache aber keine zu ZFS sync vergleichbare Sicherung.
Da gäbe es nur hardwareraid +BBU als halbwegs vergleichbare Option

Sorgt die relativ geringe Extra Amplifikation von ZFS dafür dass die SSD kaputtgeschrieben wird,
so ist sie mit ext4 oder ntfs kurze Zeit später kaputt und definitiv untauglich, da eventuell ein paar Euro mehr ausgeben.

 

[BobbyD]

muss man ZFS sync aktivieren.

Ich habe da für mich eher keine Angst und würde das also in Proxmox nicht aktivieren, wobei ich auf die Schnelle nicht sehe, wie der Aktivierungsstatus davon default ist. Wenn ich jetzt noch eine kleinere recsize nehmen würde, dann dürfte es also eher keine Unterschiede zu NTFS (oder EXT4?) geben, was das "übermäßige" Schreiben betrifft.

 

[gea]

Der defaultstatus von sync ist "default" und bedeutet dass das schreibende Programm entscheidet ob sync genutzt wird oder nicht. Recsize wirde ich mit SSD auf default=128K lassen, bei kleinen Files wird das automatisch auf Dateigröße reduziert,

btw

OmniOS 151054 long term stable (OpenSource Solaris fork/ Unix)​

OmniOS is a Unix OS based on Illumos, the parent of OpenZFS. It is a very conservative ZFS distribution with a strong focus on stability without very newest critical features like raid-z expansion or fast dedup. Main selling point beside stabilty is the kernelbased multithreaded SMB server due its unique integration in ZFS with Windows SID as security reference for ntfs alike ACL instead simple uid/gid numbers what avoids complicated mappings, lokal Windows compatible SMB groups. Setup is ultra easy, just set smbshare of a ZFS filesystem to on and set ACL via Windows.

To update to a newer release, you must switch the publisher setting to the newer release.
A 'pkg update' initiates then a release update. Without a publisher switch, a pkg updates initiates an update to the newest state of the same release.

Note that r151050 is now end-of-life. You should switch to r151054lts or r151052 to stay on a supported track. r151054 is an LTS release with support until May 2028, and r151052 is a stable release with support until Nov 2025.

Update older releases in steps over last lts editions.

​

 

[kandamir]

Danke noch für Deine Antwort, @gea, insbesondere zu jobid.pre bzw. Jobid.post. Da werde ich was basteln können!

Ich hatte bei einem Pool übersehen, dass ich bei ihm schon eine ziemliche Menge zu übertragen habe, also eigentlich das, was ich über‘s VPN/Internet vermeiden wollte. Aber geht ja nun nicht anders, da sind dreistellige GB zu übertragen…

Also losgelegt… und das wurde und wurde nicht fertig (und ist es immer noch nicht. Nachdem ich zwischendurch mal die KI befragt habe, übertrage ich die snaps gerade mit mbuffer auf Sende- und Empfangsseite, vermeide dabei die übermittlung der Snaps über eine ssh Pipe, aber das macht ehrlich gesagt gar nicht den Unterschied. Die Internetleitung wird auf beiden Seiten gerade mal kit 35 Mbit/s ausgelastet. Upload auf Sendeseite wäre 250 Mbit möglich, Download auf Empfangsseite wäre 1 Gbit/s möglich. Auf die Platte im Backupserver wird mit ca. 3,5 MB/s geschrieben, die könnte sicher 100MB/s und mehr. Im Zielsystem hat der Pool auch nur die eine Platte (Seagate Iron Wolf 10TB). L2ARC/ZIL/SLOG sind nicht vorhanden.

Ich habe schon einiges ausprobiert, iperf3 auf sender und empfänger laufen lassen, auch da kommen nur 30-35 MBit/s über die Leitung (in dem Fall sogar parallel zum noch laufenden zfs send/recv, das ich nach über 100 GB übertragenen Snaps nicht mehr abbrechen mag, auch wenn‘s erst morgen fertig wird…).

In meinen Augen ist die Übertragungsrate viel zu dünn. Sowohl die Internetanbindungen geben mehr her also auch die Olatte auf dem Zielsystem. Und das Quellsystem ist laut iostat auch nicht gestresst. Auch die WireGuard VPN Verbindung scheint die beiden beteiligten Fritz-Boxen nicht zu stressen…

Ich weiß, vermutlich kein originäres ZFS Problem, aber vielleicht habt Ihr noch Ideen, wo und wie ich den Flaschenhals finden kann?

Ich werd auch mal ein Ticket bei meinem Internet-Provider aufmachen, nicht dass da noch irgendwo „versehentlich“ ein Limit rein gerutscht ist. Aber die 250 MBit Upload sind ja wohl hoffentlich nicht nur ein sehr geschönter Prospekt-Wert und die sind hoffentlich mit den anderen Netzen ausreichend dimensioniert gekoppelt…

Also wie gesagt, wäre schön, wenn Ihr noch Hinweise oder Erfahrungswerte hättet. Vielleicht ist ja auch doch noch was am ZFS nicht gut konfiguriert…

Danke vorab!

Edit: Da schien doch ein Flaschenhals im Netzwerkmauf Empfängerseite gefunden zu sein, da sich doch tatsächlich ein alter 100MBit Switch im die LAN Infrastruktur „geschlichen“ hatte. Aber auch nach Austausch dieser alten Schnecke durch einen GBit Switch hat sich an der genutzten Bandbreite immer noch nix geändert…

Und nochmal Edit: Napp-It auf der Sendeseite liegt auf einer ESXi VM, der SATA Controller, an dem die Platten des Data-Pools hängen ist an die VM durchgereicht (Passthrough).
Napp-it auf der Empfängerseite liegt auf einer Proxmox VM. Auch hier ist der SATA-Controller an die VM durchgereicht (passthrough). Könnten die VMs noch einen limitierenden Faktor darstellen? Wie könnte ich dem auf die Schliche kommen?

 

[Senator Wurstbein]

Nicht das ich Ahnung hätte, aber sind eventuell die virtuellen nic der vm auf 100mbit/s eingestellt? Falls sowas geht?

Nächste Idee wäre unpassende mtu oder tatsächlich wireguard unter Fritz - da lese ich was von "bis zu" 90 mbit/s in senderichtung.

 

[kandamir]

Danke, mtu habe ich auch schon getestet - bzw. die Paketgröße ausgelotet, die über‘s VPN ohne Fragmentierung passt 7nd dann in mbuffer die Paketgrößen angepasst. Hat aber leider keinen Einfluss gehabt. Das nic ist 1GBit, hab ich auch lokal mittels iperf3 getestet, da gehen 950 Mbit durch, was ja GBit LAN entspricht. Ich versuche jetzt, das VPN mal,zu umgehen, indem ich an der empfangenden Fritzbox eine Portweiterleitung zum Backupserver einrichte. Leider scheitere ich aktuell daran, dass es sich dort um einen Vodafone Kabelinternetanschluss handelt, der keine öffentliche IPv4 bereitstellt. Also muss ich versuchen, das über IPv6 zum Laufen zu bekommen. Da hänge ich gerade dran, weil ich mich bislang noch nie genauer mit IPv6 beschäftigt habe…

In Napp-It habe ich Dank Home-Lizenz in den Erweiterungen noch den Kurzzeitmonitor entdeckt. Da ist mir aufgefallen, dass es doch auf der Zielplatte recht hohe busy Werte gibt. Interessanterweise sind da aber nicht die write iops hoch, sondern die read iops. Das hätte ich bei einem Schreibjob wie dem empfangen von Snaps nun nicht unbedingt erwartet.

Wo hast Du das mit den bis zu 90MBit in Senderichtung gelesen? Das wäre ja ein blödes Limit…
Hm… hab da gerade einen Heise-Artikel aus 2023 zu FritzOS 7.50 gefunden, da wurden wohl 90 Mbit in Senderichtung gemessen. Habe da aber auch folgenden Satz gefunden: „Die Betaversion von FritzOS 7.50 verdreifachte auf der Glasfaser-Fritzbox 5530 im c’t-Labor den Durchsatz durch IPsec-Tunnel auf 32 Mbit/s. Ihre Schwester 5590 schaffte mit dem neuen WireGuard-VPN sogar bis zu 1,2 Gbit“. Bei mir kommt eine 7590 (nicht AX) zum Einsatz, nun weiß ich nicht, das die so packt. Beim Überfliegen von Foren zum Thema WireGuard kamen eine Menge Probleme mit schwacher Übertragungsrate über WG vor… Da kommt ja fast die Überlegung auf, das VPN auf ne anderen Box zu machen - was mich schon etwas nerven würde, da auf beiden Seiten ein extra Gerät laufen zu haben…

Aber das mit den oben beschrieben hohen busy Werten finde ich noch eigenartig - ist da nicht noch was zu machen?

 

[Senator Wurstbein]

Unter anderem den von dir erwähnten heise-Beitrag hatte ich gefunden. Da ich nicht wusste, welche box(en) du nutzt, fand ich das relevant. Eventuell hätte ja eine der beiden ein altes Modell sein können, das unter wg nicht sonderlich performt.

Welche Boxen mit einem aktuellen fOS lahm sind, kann ich dir auch nicht sagen.

Gibt's für proxmox nen wireguard lxc? Könnte die separate Box sparen und wäre vielleicht einen Versuch wert. Andererseits... Wenn dieselbe Kiste auch noch die Entschlüsselung auf der CPU hat, wird die Performance auch nicht unbedingt besser.

 

[Bzzz]

Will man auf dem Ziel auch mit einem Schlüssel alles öffnen so geht das auf jeden Fall wenn das Ziel Dateisystem verschlüsselt ist und man nicht raw überträgt (unverschlüsselte Daten werden gesendet). Alternativ alle Quell Dateisysteme recursiv und raw übertragen, sollte auch gehen.

Jup, wenn man es richtig und eben ohne raw macht, dann klappt das auch:

zpool create -o ashift=12 -O compression=lz4 -O encryption=aes-256-gcm -O keylocation=prompt -O keyformat=passphrase pool raidz2 disks
zfs create pool/abc
zfs get encryptionroot,keystatus -r
ssh bzzz@oldsys "sudo zfs send -v oldpool/abc@2013first" | pv | sudo zfs receive -F pool/abc
ssh bzzz@oldsys "sudo zfs send -v -I oldpool/abc@2013first oldpool/abc@2025latest" | pv | sudo zfs receive -Fdv pool

(das zfs send via ssh braucht die korrekten Berechtigungen auf dem Quellsystem, sonst wird das geblockt. Gibt wohl keine schöne Lösung dafür)

 

[kandamir]

Unter anderem den von dir erwähnten heise-Beitrag hatte ich gefunden. Da ich nicht wusste, welche box(en) du nutzt, fand ich das relevant. Eventuell hätte ja eine der beiden ein altes Modell sein können, das unter wg nicht sonderlich performt.

Welche Boxen mit einem aktuellen fOS lahm sind, kann ich dir auch nicht sagen.

Gibt's für proxmox nen wireguard lxc? Könnte die separate Box sparen und wäre vielleicht einen Versuch wert. Andererseits... Wenn dieselbe Kiste auch noch die Entschlüsselung auf der CPU hat, wird die Performance auch nicht unbedingt besser.

Naja, da ich mit meinem Backup-Server quasi anderswo zu Gast bin, möchte ich die Maschine ungern rund um die Uhr laufen lassen, kostet ja auch Strom. Daher scheidet das für mich eigentlich aus. Andere Box eigentlich ebenfalls aus gleichen Gründen. Ich habe noch einmal nach WireGuard Performance Tests mit Fritzboxen Ausschau gehalten und bin auf das Video hier gestoßen:

Datenschutzhinweis für Youtube

An dieser Stelle möchten wir Ihnen ein Youtube-Video zeigen. Ihre Daten zu schützen, liegt uns aber am Herzen: Youtube setzt durch das Einbinden und Abspielen Cookies auf ihrem Rechner, mit welchen sie eventuell getracked werden können. Wenn Sie dies zulassen möchten, klicken Sie einfach auf den Play-Button. Das Video wird anschließend geladen und danach abgespielt.

Youtube Videos ab jetzt direkt anzeigen

Video anzeigen

Demnach kann ich mit meiner Fritzbox zwar die 250MBit/s Upload nicht ausreizen, aber ~180MBit/s sind halt doch deutlich mehr als die 35MBit/s, mit denen meine Snapshot aktuell übertragen werden. Mit den 180 MBit/s wäre ich vollauf zufrieden. Die Kabel-Fritzbox auf Empfängerseite ist sogar noch stärker als meine FB hier und ist somit auch kein limitierender Faktor.

Dass meine FB 180MBit/s Upload über WireGuire schafft, konnte ich übrigens auch gerade noch einmal nachvollziehen, indem ich iperf3 mal mit mehreren parallelen Verbindungen habe laufen lassen. Interessant: bis zu einer bestimmten Anzahl paralleler Verbindungen lag pro Verbindung die Übertragungsrate bei 35 MBit/s. Aha! Sobald die summierte Übertragungsrate aller Verbindungen 180 MBit/s erreicht hat, sind die Einzelübertragungsraten gesunken. Ich schließe daraus: Die VPN Verbindung an sich ist kein limitierender Faktor. Allerdings liegt das Limit pro TCP connection offenbar bei 35 MBit/s. Damit definitiv kein originäres ZFS Thema mehr.

@gea: Du verwendest netcat für die Replikation. Ich habe das statt mbuffer auch mal probiert, sehe da aber auch nur 35MBit/s Upload. Also vermutlich wird da auch nur eine parallele Verbindung aufgebaut. Gibt es eine Möglichkeit, für die Übertragung von Snapshots mehr als eine parallele Verbindung zu nutzen?

 

[gea]

@gea: Du verwendest netcat für die Replikation. Ich habe das statt mbuffer auch mal probiert, sehe da aber auch nur 35MBit/s Upload. Also vermutlich wird da auch nur eine parallele Verbindung aufgebaut. Gibt es eine Möglichkeit, für die Übertragung von Snapshots mehr als eine parallele Verbindung zu nutzen?

ZFS Replikation macht einen Datenstrom. Mehrere parallele Datenströme sind nicht möglich, wäre auch für ZFS sehr aufwendig das zu koordinieren. Selbst SMB Multichannel wird vermutlich nicht helfen bei einer nic. Iperf macht einfach mehrere Sessions, da ist das einfacher. Ansonst ist netcat und mbuffer ähnlich schnell und effizient.

Ich würde einfach häufiger replizieren. Dann fallen jeweils weniger Daten an.

 

[kandamir]

Ja, häufiger replizieren wäre eine Strategie, solange eher kleinere gleichzeitige Änderungen anstehen. Sobald Du aber mal auf einen Schlag größere Datenmengen hinzu bekommst, klappt das nicht mehr. Beispiel: Backup vom Tablet machen, Videos vom Handy speichern etc. Da kommen schnell mal ein paar GB auf einen Schlag zusammen - und schon war‘s das mit kurzen Übertragungsdauern. Und die verfügbare Bandbreite wird nicht ansatzweise ausgenutzt…

Ich habe übrigens gerade noch einmal einen öffentlichen iperf3 Server gefunden, gegen den ich messen konnte - der hat klaglos die 250 MBit/s mitgemacht, die mir im Upload zur Verfügung stehen. Ergo: Die Limitierung auf 35 MBit/s in meiner Übertragungsstrecke kommen irgendwo zwischen meinem Provider und dem der Gegenstelle zustande. Mein Provider schafft die 250 MBit/s auch in einer Verbindung und wohl auch über seine Netzgrenzen hinweg…

Ich überlege nun tatsächlich, ob es nicht sinnvoll wäre, den ZFS Stream in eine Datei umzuleiten und die über ein anderes Übertragungsprotokoll zu übermitteln, das mehr als eine gleichzeitige Verbindung kann. Die KI hat mir gerade bbcp vorgeschlagen… Gib‘s da Alternativen?