hawihoney

Members
  • Posts

    2794
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by hawihoney

  1. Natürlich, im Array (ohne TRIM) und in Pools (ab 6.12 mit dem heißgeliebten TRIM). Ansonsten definiere "korrekt":
  2. Es gibt kein BTRFS-Array oder XFS-Array. Limetechs Array Implementierung erlaubt im Array gemischte Dateisysteme.
  3. Das ist falsch. Steht im Announcement:
  4. Nein. Limetech hat sich noch nie in ein zeitliches Raster pressen lassen. Wenn 6.12 fertig ist, dann ist es fertig.
  5. Wieso nicht? Das Array ist bei mir immer der erste Schritt zum kompletten Backup. Nachts wird mit einem dutzend Scripte automatisiert ins Array gesichert. Dabei werden z.B. Container kurzfristig runtergefahren und wieder hochgefahren. Tagsüber wird dann vom Array auf langsame externe Systeme gesichert - dabei muss nix mehr gestoppt werden. Dadurch ist die Downtime auf das Minimum reduziert.
  6. Excuse my stupid question, but what does that mean exactly? Is data safe during that process or does it simply mean that a XFS formatted disks can be reformatted to ZFS without preserving data?
  7. Na ja, dann hatte ich halt eine 100 % Trefferquote bei zwei Stromausfällen (der Elektriker meinte noch, da passiert nix: Peng). Beides mal musste mein BTRFS Mirror im Cache Pool komplett neu aufgebaut werden.
  8. Du scherzt, oder? Was soll denn eine SSD in einem x-disk Unraid Array bestehend aus Harddisks. Das ist die schlechteste aller Lösungen. Die meisten hier nutzen ein stromsparendes Unraid Array (RAID-4 mit P+Q Parity) bestehend aus günstigen Harddisks als Cold-Storage und nehmen dafür die reduzierte Performance in Kauf. Die Pools sind dann für die weiteren Unraid Subsysteme wie Docker, KVM, Schreib-Cache, etc. vorgesehen. In diese Hot-Storages wandern dann teurere Disks mit erheblich besserer Performance. Wenn Du allerdings immer die beste Performance benötigst oder der Strompreis kein Thema ist oder Disk Preise kein Thema sind, ja dann hält niemand Dich davon ab ein SSD Array zu betreiben. Das ist hier aber eher nicht so oft vertreten. Denn die Kernfunktion von Unraid war und ist das Array.
  9. Das genau meine ich doch. Ein Dateisystem muss mit einem Crash - egal ob durch Strom oder etwas anderes - klar kommen. Das kommt BTRFS einfach nicht. Ich hatte Ende 2021 zwei selbst verschuldete Abstürze. Beide Male hat der BTRFS Mirror Pool (2x NVMe M.2) nicht überlebt und jedes mal durfte ich manuell reparieren und sogar den Rechner aufschrauben um an die M.2 Riegel zu kommen. Zu dem Zeitpunkt habe ich alles was BTRFS im Namen hat eliminiert. Ob ich jetzt auf ZFS springe oder nicht weiß ich noch nicht. BTRFS lasse ich aber auf jeden Fall links liegen. Das ist bei mir verbrannte Erde.
  10. 1.) RAID5/6 Systeme mit BTRFS sind noch nicht ausgereift. Single Device FS z.B. im Array mag kein Thema sein. Ein Multi-Device BTRFS Pool käme mir aber nicht ins Haus - auch wenn es ein angeblich fertiges BTRFS RAID-1 ist: https://btrfs.readthedocs.io/en/latest/btrfs-man5.html#raid56-status-and-recommended-practices Als persönliche Anmerkung hierzu noch Folgendes. Wenn in einem RAID Verbund aus zwei Platten (z.B. der typische Unraid Cache) eine Platte ausfällt, dann geht das normalerweise so: (Stoppen), Platte austauschen, (Starten), Sync, fertig. Bei BTRFS kommt noch dazu, dass unter Volllast die verbliebene gesunde Platte mit den Metadaten rumspielt. Das sind bei BTRFS somit zwei Volllast Szenarien beim Ausfall einer Platte statt nur einem bei anderen RAID Systemen. Ich habe das einmal erlebt und war weg. Das mag sich vielleicht geändert haben, ich glaube das aber nicht. Jeder Sync ist IMHO eine kritische Situation. Bei BTRFS genehmigt man sich zwei davon. Ich kann nicht verstehen, dass BTRFS allen Ernstes für solche Szenarien eingesetzt wird. Wie kommst Du darauf? Im Gegenteil. Laut der oben verlinkten Status Seite vom BTRFS Team gibt es auch bei SSDs die sich zwischen 50 % und 100 % ihres Lebenszyklus befinden massive Probleme durch die Write Amplication von BTRFS und der Metadaten Duplizierung. Auch hier ist XFS unverdächtig. Als interessierter Nutzer verfolge ich die Entwicklung beider FS im Kernel und auch außerhalb. Meiner bescheidenen persönlichen Meinung nach verfolgen beide Fraktionen unterschiedliche Entwicklungsansätze. M.M.n. haut das BTRFS Team alle Features gleichzeitig raus und beginnt dann mit dem Fixen. Das XFS Team setzt einzelne kleine Schritte als Ziel und macht sie fertig. Erst dann kommen sie ans Licht und das nächste Ziel wird ausgerufen. Nur meine 0.02 Cent. Jeder kann machen was er will, aber guck Dir mal die hunderte Fehlermeldungen an. Es ist fast immer der BTRFS Cache (nach einem Crash oder Stromabriss o.ä.).
  11. Mache ich auch. Ich nutze hierzu ein Skript welches ich mal hier im Forum gefunden habe. Das habe ich in ein User Script gepackt und es sichert 1x die Woche ins Array:
  12. hawihoney

    ZFS

    Keine Ahnung, kenne ZFS nicht. Aber wenn man ZFS per Hand mounten kann, kann man das nicht per Hand unmounten?
  13. hawihoney

    ZFS

    Das würde ich nicht machen. Unraid und Unassigned Devices haben extra dafür /mnt/addons/ geschaffen. Es ist nämlich nicht garantiert das Unraid Dir das unter /mnt/ nicht mal weglöscht.
  14. Das sind keine 36 TB Parity sondern 2x 18 TB Parity. Du hast das Parity Konzept von Unraid nicht verstanden. Bitte schau Dir das in den deutschen FAQs an:
  15. Achtung: Parity 2 wird u.a. aus Parity 1 berechnet. Parity 1 und Parity 2 haben unterschiedliche Inhalte. Ich bin mir nicht sicher ob "New config" bei Parity 2 ohne Parity 1 so einfach geht. M.E. kann er mit einer einzelnen Parity 1 (18 TB) beginnen und die Parity durch "New config" neu aufbauen lassen. Der Prozess wäre allerdings ungeschützt und erfordert Backup der wichtigen Daten.
  16. Klar. Du müsstest die zweite 18 TB für Parity 1 verwenden.
  17. Du kannst keine 18 TB Daten-Platte in ein Array aufnehmen wenn eine der beiden Parity-Platten nur 8 TB groß ist. Parity-Platten müssen immer größer oder gleich der größten Daten-Platte sein. Das liegt in der Natur der Parity-Berechnung. https://wiki.unraid.net/Articles/Getting_Started#Assigning_Devices_to_the_Array_and_Pool.28s.29
  18. "Normale" User müssen sich zu 99,99% nicht mit dem "Linux-Weg" beschäftigen. (Sym)links sind nun wirklich nicht erforderlich - egal ob im Host oder im Container. Es ist besser die von Unraid oder, in diesem Fall, Docker bereitgestellten Mechanismen zu nutzen. Zu den Mechanismen gehören auch Plugins wie Unassigned Devices. Bei Nutzung dieser Mechanismen und Tools ist garantiert, dass Unraid Spezialitäten wie User, Gruppen, Rechte etc. korrekt durchgezogen werden.
  19. Also entweder bin ich blind oder verstehe Deine Anforderung nicht wirklich. Innerhalb des Containers kann man doch auf alle Verzeichnisse - auch Unterverzeichnisse - zugreifen. Das macht man doch über das Path-Mapping - also über den Docker Weg. Du kannst dem "consume" Verzeichnis in den Container Einstellungen geben was Du willst - Unterverzeichnisse inklusive. Die Links gehen Dir doch fliegen: Sollte ich Deine Anforderung nicht verstanden habe, dann bitte ich um Entschuldigung.
  20. Schau mal in die docker.cfg. Dort steht der Storage Driver für Images. Das läuft bei mir auf XFS: DOCKER_IMAGE_TYPE="folder" DOCKER_OPTS="--storage-driver=btrfs"
  21. Overlay ist Docker. Nachtrag: Overlay steht für das Overlay Filesystem. Viele Unraid Overlay Mounts betreffen das Docker System. Es gibt aber auch weitere Overlay Mounts in Unraid.
  22. In Software statt Hardware. Einfach alle Optionen bzgl. Hardware Transcoding z.B. /dev/dri, VAAPI, installierte Plugins wie Intel-GPU-TOP, etc. rückgängig machen, dann übernehmen Software und CPU den Job. Frisst erheblich mehr Ressoucen inkl. Strom, kann aber unter Umständen sogar zu einem besseren Ergebnis führen.
  23. https://de.wikipedia.org/wiki/Woman_acceptance_factor Letztens noch live im Autohaus mitbekommen. Verkäufer redet und redet und redet. Anschließend richtet sich die Frau an ihn und fragt "Haben Sie auch ein Auto in blau?".
  24. Mich stört ein wenig der Titel "/Dev/Dri/". Kontrolliere doch bitte vorsichtshalber ob das überall - außer im Titel - korrekt geschrieben ist --> "/dev/dri".
  25. Ich habe das nie benötigt. Wenn ich "filesystem_check_changes => 1" geändert hätte, dann wüsste ich das noch. Es muss früher mal irgendwo in den Einstellungen eine Checkbox gegeben haben die hieß "Aktualisieren beim Zugriff auf Ordner" oder so. Daran kann ich mich erinnern. Und das klappte auch so. Ich habe den Scan meines Wissens nur am Anfang mal ausgeführt als ich alle Externen Speicher eingebunden hatte. Vielleicht gab es die Einstellung bei den Externen Speichern? Ich muss aber auch sagen, dass ich Nextcloud am vergangenen Wochenende gelöscht habe. Ich bin ein sehr ungeduldiger Mensch und das Produkt hat mich in letzter Zeit über Gebühr gefrustet. Im Moment sind alle ausgesperrt bis ich mir etwas Neues überlegt habe Und da ich ausschließlich mit Externen Speichern gearbeitet habe, war das löschen kein Thema da die Daten nicht innerhalb einer Nextcloud Ordnerstruktur lagen.