파일 작업(복사, 이동, 삭제) 속도는 파일 권한에 따라 달라지나요?

파일 작업(복사, 이동, 삭제) 속도는 파일 권한에 따라 달라지나요? 그렇다면, 그래서 무엇입니까?

권한이 이를 방해하는 경우에만 작업이 거부됩니다(따라서 무한한 시간이 걸리는 것으로 간주될 수 있음).

극단적인 경우를 제외하고 권한은 복사/이동/삭제 작업 속도에 영향을 미치지 않습니다.

나는 내 진술을 확인하라는 요청을 받았는데, 이는 누군가가 할 수 있는 완벽하게 허용되는 일입니다. 이것이 내 대답의 이유입니다. (이 문제를 잘못 인용/설명했다면 사과드립니다. 이를 피하려는 의도는 아니었습니다.)

수백만 개의 작은 파일 각각에 대규모 ACL이 있으면 어떻게 될까요? 이 경우 권한을 확인하는 데 실제로 디스크(예: PCI-E gen4 SSD)에서 해당 파일을 읽는 것보다 시간이 더 걸릴 수 있습니다. 일반적으로 읽기 속도가 최대 10GB/초인 PCI-E Gen 4 NVMe 드라이브를 사용할 수 있습니까?

파일당 최대 ACL 수를 찾을 수 없습니다. 그러나일부 연구를 완료했습니다.이에 대한 다운로드 가능한 스크립트가 있습니다. 연구원의 테스트에는 파일당 약 500개의 ACL이 있었습니다. 테스트에서 Raspbian의 ext4 파일 시스템에 대한 252 ACL 제한에 도달했습니다. (속도는 고려하지 않고 제한만 고려합니다.)

이 크기에서는 inode 블록으로 포장되거나 최대 한 블록 외부에 포장됩니다. 이는 읽고 구문 분석해야 하는 추가 블록입니다. 매우 작은 파일은 ext4 inode에 저장할 수 있으므로 추가 데이터 블록을 읽을 필요가 없습니다. NVMe 드라이브를 사용하면 파일당 추가 ACL 블록에 대한 읽기 시간이 매우 짧고 250개 정도의 ACL 항목을 구문 분석하는 것이 계산상 그리 어렵지 않습니다. 이는 파일이 매우 작고 추가 청크가 필요하지 않다고 가정합니다.

경험? 틀림없이. 현실적인? 나는 그렇다고 믿는다.

파일 작업(복사, 이동, 삭제) 속도는 파일 권한에 따라 달라지나요? 그렇다면, 그래서 무엇입니까?

속도예를 들어, 동일한 파일 시스템 내에서 이동하면 파일 시스템 데이터 구조의 항목만 변경되므로 실제 파일 내용은 건드리지 않습니다. 따라서 소요되는 시간은 시스템이 프로그램에서 커널로 전환하는 데 걸리는 시간과 이러한 데이터 구조에 대한 작업의 복잡성에 따라 달라집니다.

권한에 관계없이 복잡성은 동일해야 합니다. 그러나 권한은 소유자, 그룹, 기타에 대한 읽기/쓰기/실행뿐만 아니라 ACL 및 xattrs도 있으므로 특별한 경우에는 더 복잡해질 수 있습니다. 그러나 이 중 어느 것도 당신에게 전혀 중요하지 않을 가능성이 있습니다.

권한이 중요할 수 있는 유일한 경우는 파일에 대한 동시 액세스를 조정해야 하는 경우(예: NFS를 통해 마운트된 네트워크 파일 시스템에서)이지만 그런 경우에도 그러한 차이를 본 적이 없습니다.

따라서 이제 일반적으로 상황은 "빠르게" 진행되고 완전히 정지됩니다. 당신은 질문을 하지만 사용하고 있는 실제 파일 시스템에 대해서는 언급조차 하지 않습니다. 이는 아마도 당신이 잘못된 것에 대해 걱정하고 있다는 의미일 것입니다. 파일 시스템 간의 차이점을 발견할 가능성이 높습니다. 예를 들어 파일을 자주 복사하는 경우 여러 참조 범위를 인식하는 파일 시스템을 사용하면매우속도를 높이세요. 현재 Linux에는 XFS와 btrfs라는 두 가지 옵션만 있습니다. 그러나 둘 사이에서도 많은 작업(예: 초당 10,000개 이상의 작업)을 수행할 때 측정 가능한 속도 차이를 확인할 수 있습니다. 저는 XFS 쪽으로 기울고 있지만 LVM을 사용하여 직접 벤치마킹해 보면 파일 시스템을 생성하고 파괴하는 것은 정말 간단합니다.

태그를 사용하고 있다는 사실 RM,CP, 그리고MV그러나 이는 동일한 이름의 셸 도구가 완료되는 데 걸리는 시간을 동일시한다는 의미일 수 있습니다. 이것은 매우 다른 문제입니다. /usr/bin/rm1을 호출하면 실제로 파일을 삭제하는 것보다 훨씬 오래 걸립니다. 파일 시스템을 수정하기 위해 이러한 도구를 명시적으로 호출해야 하는 쉘 스크립트나 일부 언어에서 이러한 병목 현상이 나타나면 파일 작업 자체가 아니라 프로세스 생성이 병목 현상일 가능성이 높습니다.

fork1 즉, 프로세스를 포크에서 시작 execve("/usr/bin/rm")하고 Linux는 프로그램을 RAM에 로드하고 동적 링커가 약 20개의 라이브러리를 열려고 시도하는 프로세스에 메모리를 할당한 다음 실제로 하나를 로드하고 더 많은 메모리를 할당하고 여러 파일 속성을 수행합니다. openstdout을 실행하고 ...실제로 파일을 실행하기 stderr전에 모두 다시 닫습니다 . 이는 실제 삭제 요청 수의 100배입니다(예:) .unlinkunlink