Suchergebnisse

OmniOS LTS = Freeze alle 2 Jahre, neuere Sachen fehlen, nur Security und Bugfixes nach pkg update OmniOS Stable = Freeze alle 6 Monate, neuere Sachen fehlen, nur Security und Bugfixes nach pkg update OmniOS Bloody = neuestes Illumos mit leichter Verzögerung nach pkg update Im Gegensatz dazu...

Ich vermute in der Tat das Problem liegt an localisation und Datum, eventuell Umlauten. Um das einzugrenzen brauche ich die "Rohdaten" in zfs.log zfs list -o all | grep TYPE > /tmp/zfs.log zfs list -o all | grep backup_appliance >> /tmp/zfs.log

Datenumzug war Solaris -> OmniOS? mit umkopieren via robocopy? Sonst was besonderes beim Umzug? Napp-it ermittelt Werte via 'zfs list -o all' und macht dann noch eine Bearbeitung der Datumsangaben Da könnte es eventuell ein Problem geben Bitte folgende Befehle ausführen zfs list -o all | grep...

https://github.com/openzfsonosx/openzfs-fork/releases/tag/zfs-macOS-2.2.3 - ab OSX 10.9 - kein release candidate mehr - kann mit meiner web-gui napp-it cs (läuft auf Windows) remote gemanagt werden

Used, refres und dedup (logbias) sind fehlerhaft Da ich das Problem bei mir nicht sehe, welche Ausgabe hat Menü ZFS Filesystems > ZFS info ? Das zeigt die Werte die napp-it bei Aufruf des Menüs ermittelt hat (als code einfügen)

OpenZFS 2.2.3 for OSX available (up from 10.9) https://github.com/openzfsonosx/openzfs-fork/releases/tag/zfs-macOS-2.2.3

Wer mit napp-it cs ZFS on OSX managen möchte: OpenZFS 2.2.3 für OSX verfügbar (ab OSX 10.9) https://github.com/openzfsonosx/openzfs-fork/releases/tag/zfs-macOS-2.2.3

Der schnellste SMB Server unter Linux/Proxmox ist ksmbd Mit Proxmox 8.3 gibt es ein Problem mit Shares auf ZFS (Dateien unsichtbar) Bei servethehome habe ich einen Tipp erhalten um das zu beheben echo "deb http://deb.debian.org/debian/ bookworm-backports main" >...

Ein besseres Serversystem setzt gerne 100W und mehr in Wärme um. Ein kommerzielles 1HE System von der Stange z.B. SuperMicro ist darauf ausgelegt und entsprechend laut. 1 HE und leise geht nur mit Selbstbau oder wenn es ganz speziell auf low power ausgelegt ist.

Pool > Benchmark geht über cgi Pool > Benchmark > bonnie läuft im Hintergrund ansonst: lange laufende Benchmark local auf der Console starten z.B. /var/web-gui/data/tools/filebench/filebench https://docs.oracle.com/cd/E88353_01/html/E37839/filebench-1.html Die kürzer laufenden schnelleren...

Wird daran liegen dass Verschlüssellung mit kleinen Datenblöcken z.B. mit sync massiv einbricht. Der Browser der die Verbindung am längsten hält ist normalerweise Chrome aber auch da gibts irgendwann timeout der auch dafür sorgt dass der Perl cgi Prozess beendet wird. Alternativ einen Test...

Ip Päckchen ein/auspacken und Traffic Statistik bereitstellen sind unabhängig voneinander.

blöd sowas. Den 9600 sollte man dann wohl besser vermeiden wenn man kein SAS nehmen kann. (Wobei ich 12G SAS generell den Vorzug vor 6G Sata bei SSD geben würde)

1. Trim kann man auf Ebene der Einzelplatten unter Kontrolle eines Controllers oder von ZFS haben. 2. Trim im Raid geht nur auf OS/ZFS Ebene. Der BroadCom Kommentar kann sich also nur auf 1. beziehen. Hat man ein ZFS Raid, geht eh nur Fall 2. ZFS Trim geht aber auch nicht mit jeder Hardware...

nicstat -Mn 2 /var/web-gui/data/napp-it/zfsos/_lib/illumos/agents/agent_stat.pl line 895

Das Problem mit ksmbd habe ich mit 8.3 auch. Bis das gefixt ist, zurück auf SAMBA.

Die Verschlüssellung auf default (aes-256-gcm) lassen. Wichtiger ist es sich Gedanken um die Schlüsselverwaltung zu machen (Pompt, File, https, keysplit etc)

Würde ich auch so machen und den Pool selber nicht verschlüsseln sondern nur datasets bei Bedarf. Dann kann man noch unverschlüsselte datasets z.B. als VM Storage anlegen bei denen man sync möchte ohne dass die Performance unterirdisch schlecht wird.

Ich würde systematisch vorgehen, eventuell je mit Variation der globalen Settings z.B. RAM 8GB vs 24GB fest zugeordnet Verschlüsselung: kostet immer Performance vor allem bei kleinen Daten, ganz extrem bei sync, da sollte man das unbedingt vermeiden. Klassisches Dedup praktisch immer vermeiden...

hmmm...