사용자가 파일 시스템을 선택할 때 POSIX 시맨틱 호환성은 필수 지표입니다. JuiceFS는 항상 POSIX 표준과의 높은 호환성을 중시하며 기능과 성능을 지속적으로 개선하면서 POSIX 호환성을 최대한 유지하기 위해 최선을 다했습니다.
최근 POSIX 호환성 측면에서 사용자가 이러한 주류 파일의 호환성 성능을 이해할 수 있도록 Tencent Cloud CFS, Alibaba Cloud NAS, Huawei Cloud SFS, GCP Filestore, Amazon EFS, Azure File 공유 및 JuiceFS에 대한 테스트를 수행했습니다. 시스템.
POSIX는 Portable Operating System Interface(Portable Operating System Interface)의 약자로, 간단히 말해 파일 스토리지를 비롯한 파일 스토리지 분야에서 가장 널리 사용되는 운영체제 인터페이스 규격이다. POSIX 표준에 대한 자세한 내용은 Quora의 " 분산 시스템 세계에서 POSIX 준수/준수란 무엇을 의미합니까 ?"
테스트 방법
파일 시스템의 POSIX 호환성을 테스트하기 위해 널리 사용되는 테스트 케이스 세트는 FreeBSD에서 제공되고 Linux와 같은 시스템에도 적용 가능한 pjdfstest 입니다.
시험 결과
테스트 결과는 위 그림과 같습니다. JuiceFS는 실패 사례가 0건으로 최고의 호환성을 보여줍니다. GCP Filestore에 이어 Huawei Cloud SFS, Amazon EFS 및 Azure File은 다른 제품보다 몇 배 더 큰 실패한 테스트 사례를 공유합니다.비교의 편의를 위해 위 그림의 가로 좌표는 로그 좌표를 사용합니다.
실패 사례 분석
HUAWEI CLOUD SFS, Amazon EFS 및 Azure 파일 공유의 실패 사례는 총 수와 범주 측면에서 다른 파일 시스템보다 훨씬 많기 때문에 동일한 차트에서 비교할 수 없으며 나중에 별도로 분석됩니다.
GCP 파일 저장소
GCP Filestore는 unlink 및 utimesat 카테고리에 대해 각각 하나씩 총 2개의 테스트에 실패했습니다.
unlink test set 의 첫 번째 항목은 unlink/14.t 이며 해당 로그는 다음과 같습니다.
/root/pjdfstest/tests/unlink/14.t ...........
not ok 4 - tried 'open pjdfstest_b03f52249a0c653a3f382dfe1237caa1 O_RDONLY : unlink pjdfstest_b03f52249a0c653a3f382dfe1237caa1 : fstat 0 nlink', expected 0, got 1
이 테스트 도구 모음( unlink/14.t )은 열려 있는 동안 삭제되는 파일의 동작을 확인하는 데 사용됩니다.
desc="An open file will not be immediately freed by unlink"
실제로 파일을 삭제하는 작업은 시스템 수준에서 링크 해제, 즉 파일 이름에서 해당 inode로의 링크를 제거하고 해당 nlink 값을 1씩 감소시키는 작업에 해당합니다. 이 테스트 케이스는 이 점을 확인하기 위한 것입니다.
# A deleted file's link count should be 0
expect 0 open ${n0} O_RDONLY : unlink ${n0} : fstat 0 nlink
파일 내용은 링크 수(nlink)가 0으로 줄어들고 파일을 가리키는 열린 파일 설명자(fd)가 없을 때만 실제로 삭제됩니다. nlink가 제대로 업데이트되지 않으면 삭제해야 할 파일이 시스템에 남아 있을 수 있습니다.
다른 항목은 utimesat 테스트 세트의 utimesat/09.t 이며 해당 로그는 다음과 같습니다.
/root/pjdfstest/tests/utimensat/09.t ........
not ok 5 - tried 'lstat pjdfstest_909f188e5492d41a12208f02402f8df6 mtime', expected 4294967296, got 4294967295
이 테스트 케이스는 64비트 타임스탬프 지원이 필요합니다. GCP Filestore는 64비트 타임스탬프를 지원하지만 이를 기준으로 1씩 감소하므로 이 테스트 케이스에서 실패하더라도 사용에는 영향을 미치지 않아야 합니다 .
텐센트 클라우드 CFS
Tencent Cloud CFS는 utimesat, symlink 및 unlink의 세 가지 범주에서 7개 항목에 실패했습니다. 분석 및 설명을 위해 몇 가지 중요한 실패 항목을 선택했습니다.
symlink 실패 사례에 해당하는 테스트 로그는 다음과 같습니다.
/root/pjdfstest/tests/symlink/03.t ..........
not ok 1 - tried 'symlink 7ea12171c487d234bef89d9d77ac8dc2929ea8ce264150140f02a77fc6dcad7c3b2b36b5ed19666f8b57ad861861c69cb63a7b23bcc58ad68e132a94c0939d5/.../... pjdfstest_57517a47d0388e0c84fa1915bf11fe4a', expected 0, got EINVAL
not ok 2 - tried 'unlink pjdfstest_57517a47d0388e0c84fa1915bf11fe4a', expected 0, got ENOENT
Failed 2/6 subtests
이 테스트 세트( symlink/03.t )는 경로가 PATH_MAX 길이를 초과할 때 symblink의 동작을 테스트하는 데 사용됩니다.
desc="symlink returns ENAMETOOLONG if an entire length of either path name exceeded {PATH_MAX} characters"
실패한 사용 사례의 해당 코드는 다음과 같습니다.
n0=`namegen`nx=`dirgen_max`nxx="${nx}x"
mkdir -p "${nx%/*}"
expect 0 symlink ${nx} ${n0}
expect 0 unlink ${n0}
PATH_MAX이 테스트 사례 는 길이의 심볼릭 링크(후행 0 포함) PATH_MAX를 생성하는 것이지만 Tencent Cloud NAS에서 길이의 심볼릭 링크를 생성할 수 없음을 보여주지 못합니다.
알리바바 클라우드 나스
Alibaba Cloud NAS는 chmod, utimesat, unlink에서 여러 테스트 사례에 실패했습니다.
chmod chmod/12.t 테스트 세트에서 Alibaba Cloud NAS는 다음 항목에 실패했습니다.
/root/pjdfstest/tests/chmod/12.t ............
not ok 3 - tried '-u 65534 -g 65534 open pjdfstest_db85e6a66130518db172a8b6ce6d53da O_WRONLY : write 0 x : fstat 0 mode', expected 0777, got 04777
not ok 4 - tried 'stat pjdfstest_db85e6a66130518db172a8b6ce6d53da mode', expected 0777, got 04777
not ok 7 - tried '-u 65534 -g 65534 open pjdfstest_db85e6a66130518db172a8b6ce6d53da O_RDWR : write 0 x : fstat 0 mode', expected 0777, got 02777
not ok 8 - tried 'stat pjdfstest_db85e6a66130518db172a8b6ce6d53da mode', expected 0777, got 02777
not ok 11 - tried '-u 65534 -g 65534 open pjdfstest_db85e6a66130518db172a8b6ce6d53da O_RDWR : write 0 x : fstat 0 mode', expected 0777, got 06777
not ok 12 - tried 'stat pjdfstest_db85e6a66130518db172a8b6ce6d53da mode', expected 0777, got 06777
Failed 6/14 subtests
이 테스트 세트( chmod/12.t )는 SUID/SGID 비트의 동작을 테스트하는 데 사용됩니다.
desc="verify SUID/SGID bit behaviour"
11번째와 12번째 테스트 케이스를 선택하여 자세히 설명하고 이 두 가지 권한 비트를 동시에 다룹니다.
# Check whether writing to the file by non-owner clears the SUID+SGID.
expect 0 create ${n0} 06777
expect 0777 -u 65534 -g 65534 open ${n0} O_RDWR : write 0 x : fstat 0 mode
expect 0777 stat ${n0} mode
expect 0 unlink ${n0}
여기서 먼저 06777 권한으로 대상 파일을 생성한 다음 파일 내용을 수정하고 SUID 및 SGID가 올바르게 지워졌는지 확인합니다. 파일 퍼미션의 777은 누구에게나 친숙한 것으로 소유자, 그룹, 기타의 rwx에 해당하며 읽기 가능, 쓰기 가능, 실행 가능을 의미합니다. 선행 0은 8진수를 나타냅니다.
두 번째 숫자 6은 강하게 설명할 필요가 있는데 이 옥텟(octet)은 특수 권한 비트를 나타내며 처음 두 자리는 실행 파일 및 공용 디렉토리에 적용될 수 있는 setuid/setgid(또는 SUID/SGID)에 해당합니다. 이 권한 비트가 설정되면 모든 사용자가 파일을 소유자(또는 그룹)로 실행합니다. 이 특수 속성을 통해 사용자는 일반적으로 소유자만 사용할 수 있는 파일 및 디렉토리에 대한 액세스 권한을 얻을 수 있습니다. 예를 들어 passwd 명령은 setuid 권한을 설정하는데, 비밀번호를 저장한 파일은 root만 접근이 가능하고 사용자가 직접 수정할 수 없기 때문에 일반 사용자도 비밀번호를 수정할 수 있다.
setuid/setgid 설계의 시작점은 사용자가 제한된 방식(실행 파일 지정)으로 제한된 파일(현재 사용자가 소유하지 않음)에 액세스할 수 있는 방법을 제공하는 것입니다. 따라서 소유자가 아닌 사람이 파일을 수정하면 이 권한 비트가 자동으로 지워져 사용자가 이 방법을 통해 다른 권한을 얻지 못하도록 해야 합니다.
테스트 결과에서 우리는 Alibaba Cloud NAS에서 소유자가 아닌 사람이 파일을 수정하면 setuid/setgid가 지워지지 않기 때문에 실제로 사용자가 파일을 수정하여 소유자로서 모든 작업을 수행할 수 있음을 알 수 있습니다. 문제가 될 콘텐츠 안전 위험 .
추가 자료: 특수 파일 권한 (setuid, setgid 및 고정 비트)(System Administration Guide: Security Services)
화웨이 클라우드 SFS 및 아마존 EFS
HUAWEI CLOUD SFS와 Amazon EFS(Elastic File System)는 pjdfstest 테스트에서 유사하게 실패했습니다. 실패율은 약 21%이며 실패 사례는 거의 모든 범주를 포함합니다.
둘 다 NFS 마운팅을 지원하지만 NFS 기능에 대한 지원은 불완전합니다. 예를 들어 블록 장치 및 문자 장치가 지원되지 않아 pjdfstest에서 많은 테스트 사례가 실패하게 됩니다. 이 두 가지 유형의 파일을 제외하고도 여전히 수백 가지 유형의 실패가 있으므로 복잡한 시나리오에서는 주의해서 사용해야 합니다 .
Azure 파일 공유
Azure 파일 공유의 실패율은 62%에 도달했으며, 이는 일부 기본 POSIX 시나리오에 비호환성 문제가 있을 수 있음을 보여줍니다. 예를 들어 Azure 파일 공유 파일 및 폴더의 기본 권한은 0777이고 소유자는 루트이며 수정이 지원되지 않습니다. 즉, 권한 제한이 없습니다. 또한 Azure 파일 공유는 하드 링크 및 기호 링크를 지원하지 않습니다. 따라서 Azure 파일 공유를 사용하려면 시나리오가 충분히 단순한지 신중한 테스트와 신중한 고려가 필요합니다 .
요약하다
- JuiceFS는 호환성 측면에서 최고의 성능을 발휘했으며 모든 테스트 항목을 통과했습니다.
- 그 다음은 구글 파일스토어였는데 두 종류의 실패가 있었는데 그 중 하나는 실제 사용에 영향을 미치지 않았다.
- Tencent Cloud CFS는 Alibaba Cloud NAS와 유사하며 7-8개의 항목이 모두 실패합니다.
- HUAWEI CLOUD SFS, Amazon EFS 및 Azure 파일 공유는 호환성이 좋지 않으며 심각한 보안 위험이 있는 여러 테스트 사례를 포함하여 많은 호환성 테스트가 실패했습니다.사용하기 전에 보안 평가를 수행하는 것이 좋습니다.
도움이 되셨다면 저희 프로젝트 Juicedata/JuiceFS 에 주목해주세요 ! (0ᴗ0✿)