[Sammelthread] ZFS Stammtisch

[H_M_Murdock]

@gea Die Proxmox Hosts und TrueNAS laufen dankenswerterweise auf jeweils dedizierter Hardware, insfoern hat TrueNAS die komplette Maschine für sich allein.

Aktuell läuft der SMART Test noch, ich denke dass wenigstens 2 Platten gleich rausfliegen. Von den übrigen werde ich mir denke ich eine Hotspare übrig lassen und dann ein Raid Z2 aufspannen.

Meine beiden Proxmox Hosts haben jeweils nochmal 6x 265 GB SATA SSDs drin, einer davon nochmal eine 256 GB NVMe zusätzlich und noch ein paar HDDs die noch rumlagen.
Außerdem habe ich noch eine Fujitsu Eternus DX60 die ich per iSCSI an den Proxmox Cluster anbinden will.

Mal schauen was draus wird, nachdem ich beruflich fast nur Windowsclients mit AD und oberflächlich ein paar Windowsserver + VMWare, Aruba WLAN und HPE / Aruba Switches und nach und nach mehr Cisco Switches administriere will ich die Umgebung dazu nutzen mein Wissen in Sachen Linux, Proxmox und Docker auszubauen.

 

[pwnbert]

Ach, 32gb RAM sich doch erstmal genug... klar ist mehr immer besser, aber realistisch tut das schon gut.

 

[BobbyD]

Proxmox nutzt bei mir für LXC ZFS-Subvolumes.
Kann ich diese nachträglich verkleinern?

Seltsamerweise werden keine Werte ausgegeben...

root@pve:~# zfs get volsize crucial/subvol-410-disk-0
NAME                       PROPERTY  VALUE    SOURCE
crucial/subvol-410-disk-0  volsize   -        -

Und wenn es ginge, was wären die Folgen, z.B. für Fragmentation etc.

 

[H_M_Murdock]

Ach, 32gb RAM sich doch erstmal genug... klar ist mehr immer besser, aber realistisch tut das schon gut.

Wie gesagt, das NAS wird in dem Sinne vermutlich nie viel Last sehen.
Die Maschine könnte ich im Prinzip noch ordentlich aufrüsten. Mit einer zweiten CPU wären theoretisch bis zu 768 GB möglich. Eigentlich ist das Teil als NAS ziemlich cool.
Vor allem hat der Server frontseitig 12x 3,5 Zoll Einschübe und rückseitig nochmal 2x 2,5 Zoll Einschübe, das nenne ich mal ein interessantes Layout.

Meine Proxmox Hosts haben jeweils 512 GB RAM, wobei bei einem der beiden leider ein 32 GB Modul defekt ist. Davon könnte ich evtl sogar was fürs NAS abzweigen, aber solang es nicht Not tut lasse ich es so wie es ist.

Der SMART Test läuft immer noch, ich bin mal gespannt wie viele Platten unbrauchbar sind. Ich vermute mal dass 2 von den 10x 4 TB nicht mehr zu verwenden sind.

EDIT:
So ich bin jetzt erstmal zufrieden:

Tatsächlich sind 2 Platten nicht mehr in Ordnung, die habe ich ausgespart, eine habe ich als Hotspare verwendet und 7 sind aktiv im Pool.
Extra Platten für Log etc habe ich mir jetzt nicht geleistet, ich denke das ist bei meiner Nutzung auch ziemlich egal.

Der RAM war als ich meine Daten drauf kopiert habe mal ziemlich voll, danach aber auch schnell wieder leer. ZFS nimmt sich halt was es kriegen kann wenn es benötigt wird, ist ja auch gut so.
Allzu tief eingestiegen bin ich jetzt noch nicht aber so auf den ersten Blick ist mir das System schonmal recht sympatisch.

 

[BobbyD]

Kann ich diese nachträglich verkleinern?

Niemand?

 

[Kavendish]

Niemand?

Bisher nicht, aber da ich selbst den ein oder anderen Container verkleinern wollen würde, habe ich mal gesucht und bin auf https://www.reddit.com/r/Proxmox/comments/jvsyl3/is_there_a_quicker_way_than_backup_and_restore_to/ gestoßen.

does this work for ZFS?

edit: for ZFS:

1. shut down LXC
2. zfs set refquota=<size> <pool>/<dataset>/subvol-<lxc ID>-disk-0
3. (for example, zfs set refquota=1G fastpool/ct-store/subvol-109-disk-0)
4. pct rescan

based on: Shrinking ZFS filesystem for LXC CT | Proxmox Support Forum and it worked for m

Erfolgreich einen LXC mit Kavita Installation von 8G auf 3G verkleinert

 

[BobbyD]

@Kavendish Deswegen sehe ich auch Werte nur bei einer VM und nicht bei den LXC, weil das dann wohl über Quotas läuft. Danke, werd ich mal riskieren zu probieren. Aber wieder mal schade, dass das nicht leicht zu finden ist.

Beitrag automatisch zusammengeführt: 18.06.2025

@Kavendish Danke Dir, kann jetzt auch Vollzug melden.

root@pve:~# zfs list crucial/subvol-405-disk-0
NAME                        USED  AVAIL  REFER  MOUNTPOINT
crucial/subvol-405-disk-0  3.31G  20.7G  3.31G  /crucial/subvol-405-disk-0
root@pve:~# zfs get refquota crucial/subvol-405-disk-0
NAME                       PROPERTY  VALUE     SOURCE
crucial/subvol-405-disk-0  refquota  24G       local
root@pve:~# zfs set refquota=8G crucial/subvol-405-disk-0
root@pve:~# pct rescan
rescan volumes...
CT 405: updated volume size of 'crucial:subvol-405-disk-0' in config.
root@pve:~# zfs get refquota crucial/subvol-405-disk-0
NAME                       PROPERTY  VALUE     SOURCE
crucial/subvol-405-disk-0  refquota  8G        local
root@pve:~#

 

[gea]

werden zwar immer weniger...

After an update to Solaris 11.4 cbe > sru81 (pkg update, current CBE with sru 81 supports ZFS v53)
add the following links (Putty as root, copy/paste with a mouse right click, or minihttpd cannot start)
ln -s /lib/libssl.so /usr/lib/libssl.so.1.0.0
ln -s /lib/libcrypto.so /usr/lib/libcrypto.so.1.0.0

user napp-it requires a password (or PAM error)
passwd napp-it

napp-it web-gui (or tty error)
you need to update napp-it to newest v.25+

 

[Fischje]

.... ZFS gibt sicher Bescheid, wenn es Probleme gibt. Alle 2-4 Wochen einen scrub machen um rechtzeitig Probleme zu finden. (Backup wichtiger Daten nicht vergessen)

Wo denn? Hatte ich noch nicht, aber wo sähe ich dass denn außer mit zpool status ?

 

[gea]

Wo denn? Hatte ich noch nicht, aber wo sähe ich dass denn außer mit zpool status ?

Einzelne Fehler würde man an an checksum errors in zpool status sehen. Massive Fehler dann in einem degraded pool bei dem ZFS die Platte wegen "too many errors" aus dem Pool nimmt.

Mit zpool iostat kann man frühzeitig prüfen ob sich die Last gleichmäßig auf alle Platten verteilt. Deutlich schlechtere %wait und %busy Werte einzelner Platten sind ein Indiz für "schlechte" Platten

 

[CommanderBond]

Ich stelle meine Frage mal hier weil es eigentlich mehr ein ZFS Thema ist. Ich habe folgendes Problem:

Ich habe einen Proxmox Server mit 2 M.2 welche als Mirror laufen. Auf diesem läuft auch das OS. Die Bootreihenfolge ist so dass die beiden M.2s ganz vorne sind.

Jetzt habe ich die erste M.2 mal ausgebaut um zu sehen was passiert. Ergebnis die Kiste fährt gar nicht mehr hoch.

Das verstehe ich nicht und ist nicht das Verhalten was ich erwarten würde. Damit kann ich mir den Mirror ja faktisch gleich sparen.

Grund? Lösung? Ist ein ZFS Mirror fürs OS wirklich komplett sinnlos?

edit: Okay da scheint noch etwas anderes reinzuspielen. Glaube der Rechner mag generell nicht ohne Bildschirm booten.

 

[ludwinator]

zfs kümmert sich hier NICHT um den Bootloader etc,
zpool status -v sollte dir zeigen, das die m.2 partitioniert sind und erst Partion p3 zum pool gehört.

cu

 

[besterino]

Das kümmt in der Tat darauf an, wie das konfiguriert ist. Wie Proxmos das macht, weiß ich nicht, aber mit Solaris 11.3/11.4 konnte man durchaus einen beliebigen Datenträger entfernen und das System bootete trotzdem anstandslos mit dem noch vorhandenen.

Da geht das so:

Managing ZFS File Systems in Oracle Solaris 11.4

docs.oracle.com

Das dürfte allerdings mit Proxmox so NICHT funktionieren.

 

[CommanderBond]

Okay. Mein Problem hing jetzt tatsächlich doch mit einer doppelten IP im Netzwerk zusammen. Proxmox bootet egal welche M.2 man von beiden entfernt auch ohne Bildschirm und Tastatur dran.

Bootloader scheint auf beiden Platten vorhanden zu sein

 

[sandreas]

Niemand?

Achtung, folgendes funktioniert nicht mit Datasets:

Die Gast-Partition (also in der VM) erst manuell verkleinern, dann

# hier bitte die Größe und die VM-ID / Disk anpassen
zfs set volsize=120G rpool/data/vm-999-disk-9
qm rescan

Wenn man die Partitionstabelle zerschießt, kann man ne Live-Disk mit Gparted booten, gdisk starten und v,x,e,w and y drücken:

gdisk /dev/vda

Ne schöne Diskussion gibts dazu hier (auch mit anderen Wegen):

Shrink ZFS disk

Hi. I'm running on Proxmox VE 5.1 on a single node, the filesystem is on ZFS (ZRAID1) and all the VM disks are on local zfs pools. When trying to expand the vm 100 disk from 80 to 160gb i wrote the dimension in Mb instead of Gb so now i have a 80Tb drive instead of a 160Gb ( on a 240gb...

forum.proxmox.com

 

[layerbreak]

Ich brauche eure Hilfe.
Mein EXSi Server rennt seit knapp 15 Jahren ohne Probleme. Ich hatte seinerzeit @gea AIO mit OmniOS umgesetzt - inzwischen stirbt mir aber ein Hardwareteil nach dem anderen.
Versions-Stände:
ESXi: 6.7.0.Update 3
OmniOS: r151024 Nov. 2017
napp-it home: 17.06pro Nov. 2017

Also habe ich beschlossen, die komplette Hardware zu erneuern und auch die Software auf den neusten Stand zu bringen.
Bin an günstige Hardware gekommen und so wurde es ein Supermicro Superserver mit genügend RAM, 2xSSD (Mirror) für Betriebssystem, 2xSSD (Mirror) für VM-Storage und ein paar HDDs (RaidZ2) fürs Datengrab.
Ich hab mir bewusst dieses Mal gebrauchte (gereifte und abgehangene) Hardware gekauft, damit alles kompatibel ist und auch gleich ohne Probleme rennt.
Das BS steckt direkt am MB, der VM-Storage an einer NVMe PCIe und das Datengrab an einer LSI 9305 IT. Beides kann per passthrough problemlos durchgereicht werden.
Da ESXi es nicht mehr für den Privatmann gibt, muss ich wohl auf Proxmox umsteigen. Absolutes Neuland für mich.

Da ich nur sehr gute Erfahrungen mit dem AIO-Prinzip gemacht habe, würde ich es gerne beibehalten wollen. Wenn ich OmniOS weiterhin als VM laufen habe und die Daten darüber verwaltet werden, wenn dann Proxmox abraucht oder ein Update nicht passt - einfach Proxmox neu installieren, Hardware wieder durchreichen und weiter gehts.

Ich lese aber jetzt hier, dass @gea es empfiehlt, alles direkt auf Proxmox mit zfs und napp-it cs zu machen. Ich verstehe nicht warum die "Strategie" geändert wurde - liegt aber daran, dass ich mich seit Jahren mit dem Thema nicht mehr auseinander setzen musste, da mein AIO problemlos lief.

Ist es inzwischen von Vorteil, alles direkt über Proxmox zu händeln, weil OpenZfs jetzt mit integriert ist?

 

[pwnbert]

ch verstehe nicht warum die "Strategie" geändert wurde - liegt aber daran, dass ich mich seit Jahren mit dem Thema nicht mehr auseinander setzen musste, da mein AIO problemlos lief.

Proxmox ist Debian mit ZFS.
TrueNAS ist Debian mit ZFS.(das wäre das übliche OmniOS hab ich nie verwendet, ist aber halt auch ein Betriebssystem mit ZFS).
Er meint eben, dass du unnötig ein 2. OS emulierst und insbesondere in der VM dann nochmal nen ARC Cache hast (obwohl das das bare metal OS genau so könnte).
Proxmox selbst kann eigentlich alles, was die Filer-VM auch kann (naja, bei Omni-OS vielleicht nicht alles, bei TrueNAS schon).

Wobei diese Empfehlung speziell für "schwache" Systeme gilt (wonach deines nicht klingt).

Ist halt die Frage, was du willst, was dir lieber ist, wies praktischer für dich ist.


Am besten ist wohl das System, das man selbst versteht und bedienen/warten kann.

Daher ist für mich (noch) die Lösung mit der Fileserver-VM besser... da kann ich im Proxmox als root rummurksen ohne der TrueNAS VM bzw. dem Kram am Passthrough HBA irgendwie gefährlich zu werden, so fühl ich mich mit meinen Amateur-Unix-Skills einfach wohler.

 

[gea]

ESXi + OmniOS Storage VM ist für mich nach wie vor das resourcenschonendste AiO System mit Storage VM. Auch ist das minimalistische OmniOS extrem stabil und einfach zu warten. Dessen SMB Server ist neben Windows selber die einzige saubere Umsetzung für ntfs ACL mit Vererbung, SMB Gruppen (mit Gruppen in Gruppen), ZFS Snaps als Windows vorherige Version und Windows SID als ACL Referenz (braucht kein Mapping uid<->SID wie SAMBA).

btw ESXi 8 ist jetzt wieder free..

Proxmox + OmniOS ist eine Möglichkeit. Da aber Proxmox im Gegensatz zu ESXi selber ZFS kann, ist es naheliegend ein Proxmox AiO ohne Storage VM zu realisieren. Man muss sich halt mit SAMBA und Posix ACL Gewürge arrangieren. Einen größeren SMB Server mit detaillierten Rechten damit umzusetzen fällt deutlich schwerer, für SoHo aber mehr als ok.

Windows (Server) + HyperV + OpenZFS + Storage Spaces ist ein weiterer Kandidat für AiO vor allem wegen SMB Direct, ntfs ACL und Active Directory. OpenZFS für Windows ist fast fertig, lediglich bei zvols hakts noch etwas, da sind aber .vhdx virtual harddisks unter Windows eher besser, gehen sogar über SMB und LAN.

 

[layerbreak]

Proxmox ist Debian mit ZFS.

Ja, das ist mir schon klar.
Debian kenne ich schon etwas, aber mit den unterschiedlichen Linux-Derivaten werde ich einfach nicht so warm.
Debian mit ZFS ist kein Solarish.

Wobei diese Empfehlung speziell für "schwache" Systeme gilt (wonach deines nicht klingt).

lol, nein ist es definitiv nicht. Die Hardware war sicherlich mal in einer Serverfarm für Virtualisierung verbaut.

Daher ist für mich (noch) die Lösung mit der Fileserver-VM besser... da kann ich im Proxmox als root rummurksen ohne der TrueNAS VM bzw. dem Kram am Passthrough HBA irgendwie gefährlich zu werden, so fühl ich mich mit meinen Amateur-Unix-Skills einfach wohler.

Quasi ist deine Lösung fast dasselbe, wie @gea AIO, nur halt mit einer VM als Fileserver gebaut. OmniOS ist "nur" ein BS ohne anderen Schnick-schnack.

Beitrag automatisch zusammengeführt: Sonntag um 20:59

ESXi + OmniOS Storage VM ist für mich nach wie vor das resourcenschonendste AiO System mit Storage VM.

Bei ESXI war halt der Vorteil für mich, dass es da einen getrennten Client VMRC gab, womit ich easy auf die VMs zugreifen konnte und vorallem damit arbeiten konnte. Mit dem im Browser-Gedöns werde ich nicht richtig warm.

Dessen SMB Server ist neben Windows selber die einzige saubere Umsetzung für ntfs ACL mit Vererbung, SMB Gruppen (mit Gruppen in Gruppen), ZFS Snaps als Windows vorherige Version und Windows SID als ACL Referenz (braucht kein Mapping uid<->SID wie SAMBA).

Genau, das ist in meinen Augen der Hauptgrund auf OmniOS zu setzen - da funktioniert die Zusammenarbeit mit Windows sauber und super.
Mit Samba möchte ich mich eigentlich nicht auch noch rum ärgern.
Wie geschmeidig das neue KSMBD flutscht - keine Ahnung.

btw ESXi 8 ist jetzt wieder free..

Echt jetzt?
Ist die Frage nur, wie lange. Die amerikanischen Techkonzerne sind inzwischen so gierig, dass es nur ein Fingerschnipps ist und sie schalten es wieder ab und dann ...?

Proxmox + OmniOS ist eine Möglichkeit. Da aber Proxmox im Gegensatz zu ESXi selber ZFS kann, ist es naheliegend ein Proxmox AiO ohne Storage VM zu realisieren. Man muss sich halt mit SAMBA und Posix ACL Gewürge arrangieren.

Das hab ich schon verstanden.
Dann das Ganze mit deinem CS konfigurieren? Ist das gleich zu deinem napp-it home pro?
Wie sind deine Erfahrungen mit dem neuen KSMBD? Ist es da auch so aufgeblasen und ein Gewürge, wie bei Samba?

 

[you]

Ich habe aus denselben Gründen, wie Du, @layerbreak, auch bei mir proxmox als reinen Virtualisierer. Und OmniOS als NAS als VM problemlos zu laufen. Deutlich weniger Gefrickel und transparenter im Setup, finde ICH.

Details meiner VM-Einstellungen findest Du hier:

[Sammelthread] - Proxmox Stammtisch

https://www.tuxis.nl/de/wir-gehen-nach-deutschland/ Dürfte wohl für uns Home-User keinen nennenswerten Unterschied machen.

www.hardwareluxx.de

 

[gea]

- BroadCom ist schon übel, aber immerhin ist ESXi 8 wieder verfügbar und VM Workstation ist auch frei.
Damit kann man richtig gut die VMs bedienen

- napp-it cs ist auf ZFS und Servergruppen ausgerichtet. Napp-it se bietet da etwas mehr auf einem Solaris/OmniOS Einzelrechner. Ergänzt aber die Proxmox web-gui gut da dort gerade die ZFS Sachen fehlen.

- ksmbd ist deutlich schneller als SAMBA und kann SMB Direkt (theoretisch).
Das Gewürge von SAMBA liegt an der Konfiguration via (k)smb.conf und an den Posix ACL, an der prinzipiellen Inkompatibilität zu ntfs ACL, an den fehlenden SMB Gruppen und den Linux uid die man auf Windows SID mappen muss. Man kann daher ACL nicht einfach remote per Windows managen wie bei einem Windows oder Solaris SMB Server. Das ist bei ksmbd nicht anders.

 

[BobbyD]

Ergänzt aber die Proxmox web-gui gut da dort gerade die ZFS Sachen fehlen.

Gibt es da Pläne, das Ganze Noob-freundlicher zu machen? Und was mich insbesondere interessieren würde ist RAM-Caching, auch unsicheres. Es mag zwar nicht den Idealen von ZFS entsprechen, aber wenn es dennoch damit möglich ist, warum nicht den performance- statt sicherheitsorientierten Anwendern eine Möglichkeit einräumen.

 

[gea]

Gibt es da Pläne, das Ganze Noob-freundlicher zu machen?

ich bin für Anregungen offen.
Im Moment muss man
- Apache, SAMBA und ACL installieren
- Den napp-it cs Ordner csweb-gui nach /var hochladen und als Service starten

Und was mich insbesondere interessieren würde ist RAM-Caching, auch unsicheres. Es mag zwar nicht den Idealen von ZFS entsprechen, aber wenn es dennoch damit möglich ist, warum nicht den performance- statt sicherheitsorientierten Anwendern eine Möglichkeit einräumen.

Read/Write Caching im RAM macht ZFS schnell vor allem mit langsamen Platten. Den Schreibcache kann man mit sync auf Kosten der Performance schützen. Ein RAM Schreibcache bringt immer Performance da er kleine io verringert. Den Lesecache kann man mit direct-io abschalten was schnelle NVMe beschleunigt.

 

[BobbyD]

Ein RAM Schreibcache bringt immer Performance da er kleine io verringert.

Ich möchte aber auch sequentielle Writes beschleunigen, ohne Absicherung. Und mit "Noob-freundlicher" meine ich das ganze ZFS-Thema an sich, nicht so sehr die Installation.

 

[pwnbert]

... dann ist ein ZFS vielleicht nicht das richtige für dich?

 

[gea]

Ich möchte aber auch sequentielle Writes beschleunigen, ohne Absicherung. Und mit "Noob-freundlicher" meine ich das ganze ZFS-Thema an sich, nicht so sehr die Installation.

Sun entwickelte ZFS für Solaris, das war das beste Unix für die ganz großen Sachen mit Focus auf "Beherrsche alle Storage Sicherheits Probleme" und biete "Best of All" Features als Dateisystem, Share-, Raid- und Volumemanager.

Bei dem Anspruch ist ZFS erstmal überragend einfach in der Installation und dem Betrieb. Alles auf zwei Kommandos zfs und zpool zurückzuführen ist genial. Man muss sich nur anschauen was unter Linux oder Windows sonst üblich ist. Da ist alles viel komplizierter ohne auch nur ansatzweise den ZFS Möglichkeiten nahe zu kommen.

Sequentielle Writes sind übrigens unter ZFS sehr schnell wenn man sync deaktiviert. Wenn man keine Datenbanken oder VMs auf dem Pool hat auch ganz ohne Abstriche in der Sicherheit von ZFS. Einfach einen NVMe Pool oder Hybrid Pool mit NVMe special vdev anlegen. Ein Dateisystem mit small blocksize <= recsize nutzt bei einem Hybridpool komplett die NVMe, andere nur bei kleinen ansonst sehr langsamen io.

 

[BobbyD]

Ich möchte aber auch sequentielle Writes beschleunigen, ohne Absicherung.

Und zwar in den RAM, falls das nicht klar war. Wäre so was möglich und einfach einzurichten in Napp-it, ich wäre Feuer und Flamme dafür.

 

[pwnbert]

Das funktioniert so einfach nicht, Napp-it ist ja nur eine GUI und ZFS kann das in dieser Art und Weise wie du dir das vorstellst nicht.

Kannst dir ja mal bcachefs ansehen, ob das in die Richtung geht, die du dir vorstellst...?

bcachefs

 

[gea]

Und zwar in den RAM, falls das nicht klar war. Wäre so was möglich und einfach einzurichten in Napp-it, ich wäre Feuer und Flamme dafür.

Schreibcache in ZFS ist immer RAM (default 10% RAM), könnte man vergrößern. Wenn man allerdings "normal viel" RAM hat, reicht das nie für größere sequentielle Transfers, im Multiuser Betrieb zweimal nicht. Man darf ja den Cache nur zu 50% vollmachen und muss dann wegschreiben damit da nichts vollläuft. Kommen parallel neue Writes bremst concurrent io ja auch.

Ich sehe aber auch keinen Sinn. Eine gute NVMe schafft > 2GB/s, mehrere davon im Raid deutlich mehr. Das durch den Server und ins Netz zu bringen setzt sehr potente Hardware und nics 25-100G mit RDMA vorraus. RAM Writecache bringt am meisten wenn man damit kleine, langsame io vermeidet und so ist das auch konzipiert.

 

[pwnbert]

Schreibcache in ZFS ist immer RAM (default 10% RAM), könnte man vergrößern.

Spannend, wusste ich gar nicht, war noch nie irgendwo Thema...

Nachtrag: zu bcachefs:
Okay, bcachefs dürfte noch nicht "so weit" sein, dass man das verwenden wollen würde...

Dann eben Unraid? Das ist eben diese Home-User-Sache, mit dem SSD Write Cache und so...

Ich kann mir eh vorstellen auf was du hinaus möchtest, du möchtest ne "lahme" HDD mit z.B. 150mb/s verwenden, dazu viel RAM (zb. 64gb), möchtest deine 50gb erstmal in den RAM schreiben und der soll dann "gemütlich" auf die HDD schreiben... nur wenn du hier einen Ausfall irgend einer Art hast, ist das ziemlich übel.
ZFS soll ja funktionieren, egal was kommt.


Du @BobbyD könntest aber erzählen, was du vor hast... dann kann man vielleicht rausfinden, was der sinnvollste Weg ist, das zu erreichen?