Zfs: ファイル属性

後でSolarisツールをインポートすることにした場合でも、FS _ * _ FLスペースで不変、追加専用などの標準Linux属性をサポートすることは価値があると思います。 Linux上の多くの異なるファイルシステムは、これらのフラグを設定するためにlsattr / chattr ioctl（）インターフェースをサポートしていますが、一部のファイルシステムは、フラグを（ほぼ）同等のディスク上の値に変換して独自に使用します。

FS _ * _ FLに新しい属性を追加することは、それらが一般的に有用である場合（SolarisがLinuxにない属性を私は知らない）、不可能ではありませんが、そのスペースが不足しているため、それらを自由に追加することはできません。 。

私は同意します。数か月前に、標準のLinux属性をサポートすることを試みました。 当時、SolarisとLinuxに共通する属性は、不変、追加専用、およびnodumpだけであると判断しました。 残念ながら、この作業を完了する時間を見つけることができませんでしたが、開発ブランチは利用できます。 以下は、参考のためにzfs属性の完全なリストです。

 / *
 *保存される追加のファイルレベル属性
 * 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 0x0000020000000000ull
 #define ZFS_AV_MODIFIED 0x0000040000000000ull
 #define ZFS_REPARSE 0x0000080000000000ull
 #define ZFS_OFFLINE 0x0000100000000000ull
 #define ZFS_SPARSE 0x0000200000000000ull

メーリングリストで述べたように、私はこれを調べて、マッピングについて考えました。 他の人が自分に合っていると思う限り、または少しだけ検討するための私の考えは次のとおりです。

明らかなマッピング：
ZFS_IMMUTABLE <-> FS_IMMUTABLE_FL
ZFS_APPENDONLY <-> FS_APPEND_FL
ZFS_NODUMP <-> FS_NODUMP_FL

互換性の理由からおそらく良い考えです：
ZFS_IMMUTABLEが設定されている場合は、ZFS_NOUNLINKをクリアします。 これにより、ユーザーは次のコマンドでZFS_NOUNLINKをクリアできます： chattr +i FILE ; chattr -i FILE

クレイジーなアイデア1：
ZFS_READONLY、ZFS_HIDDEN、ZFS_SYSTEM、およびZFS_ARCHIVEとcrtimeをSamba互換のuser.DOSATTRIBxattrにマップします。

クレイジーなアイデア2：
ディレクトリにFS_TOPDIR_FLを設定すると、そのディレクトリでのmkdir（）操作が新しいZFSデータセットを作成するようにプロパティが設定されます。 これは、たとえば/ homeの場合に役立ちます。 そうすれば、LinuxのuseraddにZFSの変更をフックする必要はありません。 そして、ext [234]ですでにchattr +T /homeを使用するのは合理的な考えです。 FS_TOPDIR_FLをフックしなくても、この効果に対するZFSプロパティのアイデアは/ homeで役立ちます。

こんにちは、

このトピックについて何か進展はありますか？ 最近、メディアサーバーをZFSに切り替えましたが、不変フラグを設定する可能性がありません。 一部のファイルを「保護」したいのですが、フラグを設定するための回避策はありますか？ たぶん外部プログラムを介して？ これは機能しますか？

ありがとうございました！

@ cyberius0現在誰もこれに取り組んでいません。 しかし、誰かが望むなら、私はそれですべてです。

idは、誰かが私を正しい方向に向けてくれるなら、それを試してみたいと思います。 この機能が必要です。

+1

@rlaagerのクレイジーアイデア2は非常に便利に聞こえます。 それが物になることをお願いしたいと思います。

+1

Linuxファイル属性インターフェースは、Solarisでは発生しないTOCTOU競合に悩まされていることに注意してください。 SolarisとLinuxの両方のユーザーランドツールは、ファイル属性を引数として変更し、ファイル属性はコア内とディスク上にビットマスクとして保存されますが、類似点はそこで終わります。

Solarisでは、変更される値のリストとその値がカーネルに送信されます。 現在のビットマスクを取得し、それを変更して保存するという行為は、zp-> z_lockの下で処理されます。 これにより、すべての変更がアトミックであることが保証されます。これは、物事を行うための正しい方法です。 Linuxでは、変更の責任はユーザーランドにアウトソーシングされます。 ユーザーランドユーティリティは、現在のビットマスクを取得し、変更を加えて、古いビットマスクを置き換える新しいビットマスクを送信します。 ユーザーランドは変更に対してファイルをロックできないため、同じファイルの異なるビットに接触する2つの同時スレッドは、両方の変更または1つの変更のみのいずれかになります。

zfsonlinux / zfs＃1693は、SolarisのLinuxインターフェイスとZFSインターフェイスの間にいくつかの変換コードを実装することにより、ZFSOnLinuxをこの問題に対して脆弱にしました。 ありがたいことに、ファイル属性のこのような迅速な変更はまれです。これが、ファイル属性がLinuxに最初に実装されたときにこれが検出されなかった理由である可能性があります。 独自のファイル属性変更ツールを実装する場合、Solarisが行うことと同様に、Linuxインターフェイスを廃止してアトミックインターフェイスを採用する必要があります。これらは、Solarisから継承したZFSファイル属性の全範囲を公開するために必要になります。

明らかなマッピングのサポートが統合され、0.6.3の一部になります。

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

これは、Linuxには存在するが、Illumosには存在しない属性、およびその逆の属性には適用されません。 これらはケースバイケースで処理する必要があるため、この問題を解決することは理にかなっていると思います。 必要に応じて、属性ごとに新しい問題を開いて、属性の動作の詳細について話し合うことができます。

9d31779ファイル属性サポートの実装
3b4f425 inode_owner_or_capable（）autotoolsチェックのリファクタリング

@behlendorfサポートされている属性と、それらがZFSシステムで何をするかをリストしたドキュメントまたはマニュアルはありますか？