Zfs: Dateiattribute

Ich denke, es lohnt sich, die Standard-Linux-Attribute wie unveränderlich, nur anhängen usw. im FS_*_FL-Bereich zu unterstützen, auch wenn Sie sich später entscheiden, das Solaris-Tool dafür zu importieren. Viele verschiedene Dateisysteme unter Linux unterstützen die Schnittstelle lsattr/chattr ioctl() zum Setzen dieser Flags, obwohl einige Dateisysteme die Flags für ihren eigenen Gebrauch in (fast) äquivalente Werte auf der Festplatte übersetzen.

Es ist nicht unmöglich, neue Attribute zu FS_*_FL hinzuzufügen, wenn sie im Allgemeinen nützlich sind (ich weiß nicht, welche Attribute Solaris hat, die Linux nicht hat), obwohl der Speicherplatz knapp wird, so dass sie nicht ohne weiteres hinzugefügt werden können .

Ich stimme zu, vor einigen Monaten habe ich einen ersten Versuch unternommen, die Standard-Linux-Attribute zu unterstützen. Ich stellte damals fest, dass unveränderlich, nur anhängen und nodump die einzigen gemeinsamen Attribute zwischen Solaris und Linux waren. Leider habe ich nicht die Zeit gefunden, diese Arbeit abzuschließen, aber der Entwicklungszweig ist verfügbar. Nachfolgend finden Sie die vollständige Liste der zfs-Attribute nur als Referenz.

 /*
 * Zusätzliche Attribute auf Dateiebene, die gespeichert werden
 * in der oberen Hälfte von zp_flags
 */
 #define ZFS_READONLY 0x0000000100000000ull
 #define ZFS_HIDDEN 0x0000000200000000ull
 #define ZFS_SYSTEM 0x0000000400000000ull
 #define ZFS_ARCHIVE 0x0000000800000000ull
 #define ZFS_IMMUTABLE 0x0000001000000000ull
 #define ZFS_NOUNLINK 0x0000002000000000ull
 #define ZFS_APPENDONLY 0x0000004000000000ull
 #define ZFS_NODUMP 0x0000008000000000ull
 #define ZFS_OPAQUE 0x0000010000000000ull
 #define ZFS_AV_QUARANTINED 0x00000020000000000ull
 #define ZFS_AV_MODIFIED 0x0000040000000000ull
 #define ZFS_REPARSE 0x0000080000000000ull
 #define ZFS_OFFLINE 0x0000100000000000ull
 #define ZFS_SPARSE 0x0000200000000000ull

Wie ich auf der Mailingliste erwähnt habe, habe ich mir das angeschaut und über die Zuordnungen nachgedacht. Hier sind meine Gedanken, die andere so viel oder so wenig berücksichtigen sollten, wie sie es für richtig halten:

Offensichtliche Zuordnungen:
ZFS_IMMUTABLE <-> FS_IMMUTABLE_FL
ZFS_APPENDONLY <-> FS_APPEND_FL
ZFS_NODUMP <-> FS_NODUMP_FL

Möglicherweise eine gute Idee aus Kompatibilitätsgründen:
Wenn ZFS_IMMUTABLE jemals gesetzt ist, löschen Sie ZFS_NOUNLINK. Dies würde es einem Benutzer ermöglichen, ZFS_NOUNLINK zu löschen mit: chattr +i FILE ; chattr -i FILE

Verrückte Idee 1:
Ordnen Sie ZFS_READONLY, ZFS_HIDDEN, ZFS_SYSTEM und ZFS_ARCHIVE und die crtime einem Samba-kompatiblen Benutzer zu.DOSATTRIB xattr.

Verrückte Idee 2:
Das Festlegen von FS_TOPDIR_FL für ein Verzeichnis legt eine Eigenschaft fest, sodass mkdir()-Operationen in diesem Verzeichnis neue ZFS-Datensätze erstellen. Dies wäre zum Beispiel für /home nützlich. Dann müssen Sie unter Linux keine ZFS-Änderungen in useradd einbinden. Und es ist eine vernünftige Idee, bereits chattr +T /home auf ext[234] zu setzen. Selbst wenn Sie FS_TOPDIR_FL nicht daran hängen, wäre die Idee einer ZFS-Eigenschaft in diesem Sinne immer noch für /home nützlich.

Hallo,

gibt es Fortschritte zu diesem Thema? Ich habe vor kurzem meinen Medienserver auf ZFS umgestellt, aber ich vermisse die Möglichkeit, das unveränderliche Flag zu setzen. Ich möchte einige Dateien "schützen". Gibt es eine Problemumgehung, um das Flag zu setzen? Vielleicht über ein externes Programm? Würde das funktionieren?

Dankeschön!

@cyberius0 Daran arbeitet derzeit niemand. Aber wenn jemand möchte, bin ich dafür.

Ich würde es gerne versuchen, wenn mich jemand in die richtige Richtung weisen würde. Ich brauche diese Funktion.

+1

Verrückte Idee 2 von @rlaager klingt immens nützlich. Ich möchte darum bitten, dass das zu einer Sache wird.

+1

Es ist zu beachten, dass die Linux-Dateiattributschnittstelle unter einem TOCTOU-Rennen leidet, das unter Solaris nicht auftritt. Die Userland-Tools auf Solaris und Linux nehmen Änderungen an den Dateiattributen als Argumente an, und die Dateiattribute werden im Kern und auf der Festplatte als Bitmasken gespeichert, aber die Ähnlichkeiten enden dort.

Unter Solaris wird eine Liste der sich ändernden Werte zusammen mit ihren Werten an den Kernel gesendet. Der Vorgang, die aktuelle Bitmaske zu nehmen, zu modifizieren und zu speichern, wird dann unter zp->z_lock verarbeitet. Dies stellt sicher, dass alle Änderungen atomar sind, was der richtige Weg ist, Dinge zu tun. Unter Linux wird die Verantwortung für Änderungen an das Userland ausgelagert. Das Userland-Dienstprogramm ruft die aktuelle Bitmaske ab, nimmt die Änderungen vor und sendet eine neue Bitmaske, die die alte ersetzt. Da Userland die Datei nicht gegen Änderungen sperren kann, können zwei gleichzeitige Threads, die unterschiedliche Bits in derselben Datei berühren, entweder beide Änderungen oder nur eine Änderung sein.

zfsonlinux/zfs#1693 machte ZFSOnLinux anfällig für dieses Problem, indem es einen Übersetzungscode zwischen der Linux-Schnittstelle und der ZFS-Schnittstelle von Solaris implementierte. Glücklicherweise ist eine so schnelle Änderung von Dateiattributen selten, weshalb dies wahrscheinlich nicht erkannt wurde, als Dateiattribute zum ersten Mal unter Linux implementiert wurden. Wir sollten die Linux-Schnittstelle zugunsten einer atomaren Schnittstelle abschaffen, wie es Solaris tut, wenn wir unsere eigenen Tools zum Ändern von Dateiattributen implementieren. Diese werden benötigt, um die gesamte Palette der von Solaris geerbten ZFS-Dateiattribute verfügbar zu machen.

Die Unterstützung für die offensichtlichen Zuordnungen wurde zusammengeführt und wird Teil von 0.6.3 sein.

• ZFS_IMMUTABLE <-> FS_IMMUTABLE_FL
• ZFS_APPENDONLY <-> FS_APPEND_FL
• ZFS_NODUMP <-> FS_NODUMP_FL

Dies gilt nicht für Attribute, die unter Linux existieren, jedoch nicht für Illumos und umgekehrt. Da wir diese von Fall zu Fall behandeln müssen, halte ich es für sinnvoll, dieses Thema zu schließen. Wir können bei Bedarf für jedes Attribut ein neues Problem eröffnen, um die Details seines Verhaltens zu besprechen.

9d31779 Unterstützung für Dateiattribute implementieren
3b4f425 Refactor inode_owner_or_capable() Autotools-Überprüfung

@behlendorf Gibt es eine Dokumentation oder ein Handbuch, die auflistet, welche Attribute unterstützt werden und was sie auf einem ZFS-System tun?