Zfs: Атрибуты файла

Я думаю, что в пространстве FS _ * _ FL стоит поддерживать стандартные атрибуты Linux, такие как неизменяемость, добавление только и т. Д., Даже если позже вы решите импортировать для этого инструмент Solaris. Многие файловые системы в Linux поддерживают интерфейс lsattr / chattr ioctl () для установки этих флагов, хотя некоторые файловые системы переводят флаги в (почти) эквивалентные значения на диске для собственного использования.

Невозможно добавить новые атрибуты в FS _ * _ FL, если они обычно полезны (я не знаю, какие атрибуты есть у Solaris, а у Linux нет), хотя это пространство заканчивается, поэтому их нельзя добавить волей-неволей. .

Я согласен, несколько месяцев назад я предпринял попытку поддержать стандартные атрибуты Linux. В то время я определил, что неизменяемость, добавление только и nodump были единственными атрибутами, общими для Solaris и Linux. К сожалению, мне не удалось найти время, чтобы закончить эту работу, но ветка для разработки доступна. Ниже приведен полный список атрибутов 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-совместимым пользователем. DOSATTRIB xattr.

Безумная идея 2:
Установка FS_TOPDIR_FL в каталоге устанавливает свойство, чтобы операции mkdir () в этом каталоге создавали новые наборы данных ZFS. Это было бы полезно, например, для / home. Тогда вам не нужно привязывать изменения ZFS к useradd в Linux. И это разумная идея уже chattr +T /home на ext [234]. Даже если вы не подключите к нему FS_TOPDIR_FL, идея свойства ZFS для этого эффекта все равно будет полезна для / home.

Привет,

есть ли прогресс по этой теме? Недавно я переключил свой медиа-сервер на ZFS, но я упускаю возможность установить неизменяемый флаг. Я хотел бы «защитить» некоторые файлы, есть ли способ установить флаг? Может через внешнюю программу? Это сработает?

Спасибо!

@ cyberius0 В настоящее время над этим никто не работает. Но если кому-то хочется, я за это.

Я хотел бы дать ему шанс, если кто-то укажет мне правильное направление. Мне нужна эта функция.

+1

Безумная идея 2 от @rlaager звучит очень полезно. Я хотел бы попросить, чтобы это стало реальностью.

+1

Следует отметить, что интерфейс атрибутов файлов Linux страдает от гонки TOCTOU, которая не происходит в Solaris. Инструменты пользовательского пространства как в Solaris, так и в Linux принимают модификации атрибутов файлов в качестве аргументов, а атрибуты файлов хранятся в ядре и на диске в виде битовых масок, но на этом сходство заканчивается.

В Solaris в ядро ​​отправляется список значений, которые будут изменены, а также их значения. Акт взятия текущей битовой маски, ее изменения и сохранения затем обрабатывается в zp-> z_lock. Это гарантирует, что все изменения атомарны, что является правильным способом. В Linux ответственность за модификации передается пользователю. Утилита пользовательского уровня получит текущую битовую маску, внесет изменения и отправит новую битовую маску, которая заменяет старую. Поскольку пользовательская среда не может заблокировать файл от изменений, два параллельных потока, затрагивающие разные биты одного и того же файла, могут быть либо обоими изменениями, либо только одним изменением.

zfsonlinux / zfs # 1693 сделал ZFSOnLinux уязвимым для этой проблемы, реализовав некоторый код трансляции между интерфейсом Linux и интерфейсом ZFS из Solaris. К счастью, такое быстрое изменение атрибутов файлов случается редко, и, вероятно, именно поэтому это не было обнаружено, когда атрибуты файлов были впервые реализованы в Linux. Нам следует отказаться от интерфейса Linux в пользу атомарного интерфейса, аналогичного тому, что делает Solaris, когда мы реализуем наши собственные инструменты изменения атрибутов файлов. Они потребуются для предоставления полного спектра атрибутов файлов ZFS, унаследованных от Solaris.

Поддержка очевидных сопоставлений была объединена и станет частью 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 () проверка автоинструментов

@behlendorf Есть ли документация или руководство, в которых перечислены поддерживаемые атрибуты и их действия в системе ZFS?