Diesmal geht es nicht um Extended Attributes, jedoch um eine andere Art von Dateiattributen, die auch für den Kernel von Bedeutung sind. Mit diesen kann man beispielsweise Dateien unveränderbar machen oder einstellen, dass an die Datei nur neue Daten angehangen werden können, aber nicht der bisherige Inhalt überschrieben werden kann. Das ganze ist völlig unabhängig von den eigentlichen Rechten der Datei.
Beispiel unter Linux:
# chattr +i myfile
Danach ist die Datei unveränderbar. Selbst root kann die Datei nicht verändern, solange das Attribut gesetzt ist. Natürlich könnte root es entfernen und danach die Datei verändern.
Unter Solaris verändert man diese Attribute mit chmod. Interessant ist da z.B. das nounlink-Attribut.
# chmod S+vnounlink myfile
rm: myfile not removed: Not owner
# echo newcontent > myfile
# chmod S-vnounlink myfile
# rm myfile
#
Das verhindert effektiv, dass man sich wichtige Dateien versehentlich löscht.
Applying Special Attributes to ZFS Files
chattr (ubuntuusers Wiki)
Hardware-RAID hat gegenüber ZFS so einige Nachteile. Keine Checksums, resilvern dauert lange, Inkompatiblitäten zu anderen RAID-Controllern, da ist man echt froh, wenn man das nicht hat. Ein Argument gegen ZFS ist allerdings der Ressourcen-Verbrauch, denn statt Hardware-RAID-Controllern muss jetzt Software den selben Job und noch mehr erledigen. Spüren tut man das allerdings nicht, denn die CPUs sind heutzutage so schnell, dass die das locker nebenbei erledigen.
Dieses prähistorische Dinosaurier-RAID ist vielleicht nicht so toll, doch wenn man nur die passenden Dinosaurier-CPUs dazu hat, dann hat das ganze doch ein paar Vorteile. Ich habe kürzlich auf einer Sun Ultra 25 Workstation ein raidz1 mit 3 Platten gebildet. Die Workstation stammt aus dem Jahr 2006, die darin verbaute UltraSPARC IIIi CPU gibt es allerdings seit 2003. Und damit merkt man leider schon, was ZFS so an Rechenleistung verbrennt.
Ein Ausschnitt der Ausgabe von prstat wärend mit dd auf den raidz1 pool geschrieben wurde:
PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP
107 root 0K 0K run 0 -20 0:00:25 58% zpool-storage/136
967 root 4624K 2152K run 53 0 0:00:08 12% dd/1
Und wenn parallel dazu noch auf den rpool, der nur aus einer Festplatte besteht, geschrieben wurde:
PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP
107 root 0K 0K sleep 99 -20 0:01:55 41% zpool-storage/136
980 root 4624K 2216K sleep 53 0 0:00:04 11% dd/1
5 root 0K 0K run 0 -20 0:00:23 6,1% zpool-rpool/136
981 olaf 4624K 2320K run 39 0 0:00:01 4,1% dd/1
Es ist also doch kein Mythos, dass ZFS ein paar Ressourcen braucht. Und ein zpool scrub verursacht sogar über 90% CPU-Auslastung.
Kommentare
Rudi | Artikel: Raspberry Pi1 vs Raspberry Pi4 vs Fujitsu s920 vs Sun Ultra 45
Peter | Artikel: XNEdit - Mein NEdit-Fork mit Unicode-Support
Damit wird Nedit durch XNedit ersetzt.
Danke!
Olaf | Artikel: XNEdit - Mein NEdit-Fork mit Unicode-Support
Anti-Aliasing hängt von der Schriftart ab. Mit einem bitmap font sollte die Schrift klassisch wie in nedit aussehen.
Einfach unter Preferences -> Default Settings -> Text Fonts nach einer passenden Schriftart suchen.
Peter | Artikel: XNEdit - Mein NEdit-Fork mit Unicode-Support
Mettigel | Artikel: Raspberry Pi1 vs Raspberry Pi4 vs Fujitsu s920 vs Sun Ultra 45
Ich hatte gedacht, dass der GX-415 im s920 deutlich mehr Dampf hat als der Raspi4.
Mein Thinclient verbraucht mit 16 GB RAM ~11 W idle, das ist das Dreifache vom RP4. Das muss man dem kleinen echt lassen... Sparsam ist er.
Olaf | Artikel: Raspberry Pi1 vs Raspberry Pi4 vs Fujitsu s920 vs Sun Ultra 45
Ergebnisse von der Ultra 80 wären natürlich interessant, insbesondere im Vergleich mit dem rpi1.
kosta | Artikel: Raspberry Pi1 vs Raspberry Pi4 vs Fujitsu s920 vs Sun Ultra 45
ich hätt hier zugriff auf Ultra-80 4CPU 4GB 2x Elite3D.
RO | Artikel: Benutzt bitte nur noch Unicode!
Sehe ich genauso.