Zfs: Atributos de archivo

Creo que vale la pena admitir los atributos estándar de Linux como inmutable, solo anexar, etc. en el espacio FS _ * _ FL, incluso si luego decide importar la herramienta Solaris para el mismo. Muchos sistemas de archivos diferentes en Linux admiten la interfaz lsattr / chattr ioctl () para configurar estos indicadores, aunque algunos sistemas de archivos traducen los indicadores a valores (casi) equivalentes en el disco para su propio uso.

No es imposible agregar nuevos atributos a FS _ * _ FL si en general son útiles (no sé qué atributos tiene Solaris y Linux no), aunque ese espacio se está agotando, por lo que no se pueden agregar de cualquier manera. .

Estoy de acuerdo, hace unos meses hice una incursión inicial para intentar admitir los atributos estándar de Linux. En ese momento, determiné que inmutable, de solo adición y nodump eran los únicos atributos comunes entre Solaris y Linux. Desafortunadamente, no pude encontrar el tiempo para terminar este trabajo, pero la rama de desarrollo está disponible. A continuación se muestra la lista completa de atributos de zfs solo como referencia.

 / *
 * Atributos de nivel de archivo adicionales, que se almacenan
 * en la mitad superior de 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

Como mencioné en la lista de correo, miré esto y pensé en las asignaciones. Aquí están mis pensamientos para que otros consideren tanto o tan poco como consideren conveniente:

Asignaciones obvias:
ZFS_IMMUTABLE <-> FS_IMMUTABLE_FL
ZFS_APPENDONLY <-> FS_APPEND_FL
ZFS_NODUMP <-> FS_NODUMP_FL

Posiblemente sea una buena idea por razones de compatibilidad:
Si alguna vez se establece ZFS_IMMUTABLE, borre ZFS_NOUNLINK. Esto permitiría a un usuario borrar ZFS_NOUNLINK con: chattr +i FILE ; chattr -i FILE

Idea loca 1:
Asigne ZFS_READONLY, ZFS_HIDDEN, ZFS_SYSTEM y ZFS_ARCHIVE y el crtime a un usuario compatible con Samba. DOSATTRIB xattr.

Idea loca 2:
La configuración de FS_TOPDIR_FL en un directorio establece una propiedad para que las operaciones de mkdir () en ese directorio creen nuevos conjuntos de datos ZFS. Esto sería útil para / home, por ejemplo. Entonces no es necesario que conecte los cambios de ZFS a useradd en Linux. Y ya es una idea razonable chattr +T /home en la extensión [234]. Incluso si no enlaza FS_TOPDIR_FL, la idea de una propiedad ZFS a este efecto aún sería útil en / home.

Hola,

¿Hay algún progreso en este tema? Recientemente cambié mi servidor de medios a ZFS pero pierdo la posibilidad de establecer la bandera inmutable. Me gustaría "proteger" algunos archivos, ¿hay alguna solución para establecer la bandera? ¿Quizás a través de un programa externo? ¿Funcionaría esto?

¡Gracias!

@ cyberius0 Nadie está trabajando en esto actualmente. Pero si alguien quisiera, estoy totalmente de acuerdo.

Me gustaría intentarlo si alguien me indicara la dirección correcta. Necesito esta característica.

+1

La loca idea 2 de @rlaager suena inmensamente útil. Me gustaría solicitar que eso se convierta en una cosa.

+1

Cabe señalar que la interfaz de atributos de archivos de Linux sufre una carrera TOCTOU que no ocurre en Solaris. Las herramientas del área de usuario tanto en Solaris como en Linux toman modificaciones a los atributos del archivo como argumentos y los atributos del archivo se almacenan en el núcleo y en el disco como máscaras de bits, pero las similitudes terminan ahí.

En Solaris, se envía al kernel una lista de los valores que cambiarán, junto con sus valores. El acto de tomar la máscara de bits actual, modificarla y almacenarla se procesa en zp-> z_lock. Esto asegura que todos los cambios sean atómicos, que es la forma correcta de hacer las cosas. En Linux, la responsabilidad de las modificaciones se subcontrata al área de usuario. La utilidad de espacio de usuario obtendrá la máscara de bits actual, realizará los cambios y enviará una nueva máscara de bits que reemplaza a la anterior. Dado que el área de usuario no puede bloquear el archivo contra modificaciones, dos subprocesos simultáneos que tocan diferentes bits en el mismo archivo pueden ser ambos cambios o solo 1 cambio.

zfsonlinux / zfs # 1693 hizo que ZFSOnLinux fuera vulnerable a este problema al implementar algún código de traducción entre la interfaz de Linux y la interfaz ZFS de Solaris. Afortunadamente, una modificación tan rápida de los atributos del archivo es poco común, razón por la cual probablemente no se detectó cuando los atributos del archivo se implementaron por primera vez en Linux. Deberíamos desaprobar la interfaz de Linux en favor de una interfaz atómica similar a lo que hace Solaris cuando implementamos nuestras propias herramientas de modificación de atributos de archivos. Éstas serán necesarias para exponer la gama completa de atributos de archivos ZFS que heredamos de Solaris.

El soporte para las asignaciones obvias se ha fusionado y será parte de 0.6.3.

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

Esto no cubre los atributos que existen en Linux, pero no Illumos y viceversa. Dado que vamos a tener que manejarlos caso por caso, creo que tiene sentido cerrar este tema. Podemos abrir una nueva edición para cada atributo según sea necesario para discutir los detalles de cómo debería comportarse.

9d31779 Implementar compatibilidad con atributos de archivo
3b4f425 Refactorizar inode_owner_or_capable () verificación de autotools

@behlendorf ¿Existe documentación o manual que enumere qué atributos son compatibles y qué hacen en un sistema ZFS?