Zfs: 파일 속성

나중에 Solaris 도구를 가져오기로 결정하더라도 FS__*_FL 공간에서 변경 불가능, 추가 전용 등과 같은 표준 Linux 속성을 지원하는 것은 가치가 있다고 생각합니다. 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를 지웁니다. 이렇게 하면 사용자가 chattr +i FILE ; chattr -i FILE ZFS_NOUNLINK를 지울 수 있습니다.

미친 아이디어 1:
ZFS_READONLY, ZFS_HIDDEN, ZFS_SYSTEM 및 ZFS_ARCHIVE와 crtime을 Samba 호환 사용자에 매핑합니다.DOSATTRIB xattr.

미친 아이디어 2:
디렉토리에서 FS_TOPDIR_FL을 설정하면 해당 디렉토리의 mkdir() 작업이 새 ZFS 데이터 세트를 생성하도록 속성이 설정됩니다. 이것은 예를 들어 /home에 유용합니다. 그러면 Linux에서 ZFS 변경 사항을 useradd에 연결할 필요가 없습니다. 그리고 이미 ext[234]에서 chattr +T /home 설정하는 것이 합리적입니다. FS_TOPDIR_FL을 연결하지 않더라도 이 효과에 대한 ZFS 속성의 아이디어는 /home에서 여전히 유용할 것입니다.

안녕하십니까,

이 주제에 진전이 있습니까? 최근에 미디어 서버를 ZFS로 전환했지만 변경할 수 없는 플래그를 설정할 가능성이 없습니다. 일부 파일을 "보호"하고 싶습니다. 플래그를 설정하는 해결 방법이 있습니까? 아마도 외부 프로그램을 통해? 이게 효과가 있을까요?

감사합니다!

@cyberius0 현재 아무도 이 작업을 하고 있지 않습니다. 그러나 누군가가 원한다면 나는 그것을 위해 모든 것입니다.

누군가가 나를 올바른 방향으로 안내해 준다면 시도해 보고 싶습니다. 이 기능이 필요합니다.

+1

@rlaager 의 Crazy Idea 2는 매우 유용하게 들립니다. 그것이 일이 되기를 간청하고 싶습니다.

+1

Linux 파일 속성 인터페이스는 Solaris에서 발생하지 않는 TOCTOU 경쟁을 겪는다는 점에 유의해야 합니다. Solaris 및 Linux의 userland 도구는 파일 속성을 인수로 수정하고 파일 속성은 코어 및 디스크에 비트 마스크로 저장되지만 유사점은 거기서 끝입니다.

Solaris에서는 값이 무엇인지와 함께 변경될 값 목록이 커널로 전송됩니다. 현재 비트마스크를 가져와 수정하고 저장하는 작업은 zp->z_lock 아래에서 처리됩니다. 이렇게 하면 모든 변경 사항이 원자적이며 이것이 올바른 작업 방식임을 보장합니다. Linux에서 수정에 대한 책임은 사용자 영역에 아웃소싱됩니다. userland 유틸리티는 현재 비트마스크를 가져와 변경하고 이전 비트마스크를 대체하는 새 비트마스크를 보냅니다. userland는 수정에 대해 파일을 잠글 수 없기 때문에 동일한 파일에서 서로 다른 비트를 접촉하는 두 개의 동시 스레드는 둘 다 변경되거나 한 번만 변경될 수 있습니다.

zfsonlinux/zfs#1693은 Linux 인터페이스와 Solaris의 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 시스템에서 수행하는 작업을 나열하는 설명서나 설명서가 있습니까?