작년에 발표된 Linux 5.2 패치 노트를 읽으면서 패치 노트가 시작되었다는 것을 알았습니다.ext4 파일 시스템에서 대소문자를 구분하지 않는 이름에 대한 선택적 지원.
그래서... 커널에 대소문자를 구분하지 않는 옵션(대소문자 구분 및 정규화 모두)이 필요한 이유가 궁금합니다. 내가 찾을 수 있습니다다른 기사케이스 폴딩 파일 시스템을 지원하는 커널 코드를 작성한 Krisman이 작성한 글이지만, case-insensitive file system allows us to resolve important bottlenecks for applications being ported from other operating systems정규화 및 케이스 폴딩 프로세스를 통해 어떻게 디스크 스토리지를 최적화할 수 있는지 이해할 수 없다는 점이 마음에 와 닿지 않았습니다.
당신의 도움에 정말 감사드립니다!
답변1
대소문자를 구분하지 않는 파일 시스템을 사용하면 다른 운영 체제에서 애플리케이션을 이식할 때 발생하는 심각한 병목 현상을 해결할 수 있습니다.
정규화 및 케이스 폴딩 프로세스를 통해 디스크 스토리지를 최적화하는 방법을 이해할 수 있다는 사실이 마음에 들지 않습니다.
와인, 삼바 및 안드로이드가지다대소문자를 구분하지 않는 파일 시스템 의미 체계를 제공합니다. 기본 파일 시스템이 대소문자를 구분하는 경우 모든 대소문자 구분 조회가 실패합니다. Wine et al. 각 디렉터리를 스캔하여 대소문자를 구분하지 않는 일치 항목이 없음을 증명해야 합니다. 예를 들어 조회가 실패하면 의 모든 파일과 모든 디렉터리에 대해 /foo/bar/readme.txt전체 디렉터리 목록 및 대소문자 비교를 수행해야 합니다 .foo/bar/*foo/*/*
여기에는 몇 가지 문제가 있습니다.
- 깊게 중첩된 경로는 매우 느려질 수 있습니다.수백 건의 FS 호출) 또는 수만 개의 파일이 포함된 디렉터리(예:SMB 스토리지를 통한 증분 백업).
- 이러한 검사에는 경쟁 조건이 발생합니다.
- 근본적으로 건전하지 않습니다. 와 둘 다
readme.txt존재README.txt하지만 애플리케이션에서 이를 요구하는 경우README.TXT어떤 파일이 반환되는지는 정의되지 않습니다.
Android는 FUSE/wrapfs를 사용하여 대소문자 구분을 시뮬레이션한 다음 커널을 사용합니다.SD 카드 FS. 그러나 SDCardFS는 단순히 프로세스를 커널 공간으로 이동함으로써 모든 것을 더 빠르게 만듭니다 † . 여전히 파일 시스템을 통과해야 하고(따라서 IO 바인딩되어 있음) 경쟁 조건이 발생하며 근본적으로 건전하지 않습니다. 따라서 Google이 대소문자를 구분하지 않고 더 이상 사용되지 않는 F2FS의 기본 디렉터리별 F2FS 개발에 자금을 지원한 이유SD 카드 FS.
과거에는 VFS를 통해 대소문자를 구분하지 않는 조회를 활성화하려는 시도가 여러 번 있었습니다. 2018년 가장 최근 시도에서는 설치가 허용되었습니다.파일 시스템의 대소문자를 구분하지 않는 보기. Ted Tso는 이 기능을 추가할 때 적어도 더 빠르고 경쟁 조건이 없기 때문에 Wrapfs 관련 문제를 구체적으로 언급했습니다. 그러나 여전히 소리가 나지 않습니다(요청이 OR 을 README.TXT반환할 수 있음 ). 이는 대소문자를 구분하지 않는 디렉터리별 지원을 추가하기 위해 거부되었으며 VFS††에 통합될 가능성은 거의 없습니다.readme.txtREADME.txt
또한 사용자는 대소문자를 구분하지 않기를 기대하므로 모든 소비자 지향 운영 체제에서는 이를 제공해야 합니다. 유니코드가 존재하지 않고 문자열은 단지 바이트 패킷일 뿐이므로 Unix 자체에서는 이를 지원할 수 없습니다. 케이스 접기가 처리되는 방식에 대해 유효한 비판이 많이 있습니다.과거에, 그러나 유니코드는불변 케이스 폴딩 기능이것은 다음을 제외한 모든 사람에게 적용됩니다.단일 로케일(터키어는 그럼에도 불구하고 두 개의 코드 포인트에 불과합니다). 게다가파일 시스템 B-트리이 행위를 저지르는 유일한 합리적인 장소입니다.
†아시아정보통신기술협회
나는 VFS 기반 대소문자 구분 없는 조회 및 EXT4 및 F2FS에 대한 디렉터리별 대소문자 구분 지원의 작성자인 Krisman에게 이메일을 보냈습니다.
답변2
다른 운영 체제에는 대소문자를 구분하지 않는 파일 시스템이 있습니다.
예: MacOS에서는 대소문자를 구분하지 않거나(기본값) 대소문자를 구분합니다. Adobe Photoshop 및 Adobe Lightroom은 대소문자를 구분하는 파일 시스템을 잘 처리하지 않습니다. 이는 Adobe 프로그램에서 다르게 작성된 하드코딩된 경로(아마도 다른 라이브러리의 "문서" 및 "문서")가 있을 수 있거나 때로는 일부 필터가 적용된 경우(예: 소문자 및 공백 제거와 관련이 있을 수 있음)가 있을 수 있음을 의미합니다. 데이터) 그냥 작동하기 때문에 아무도 신경 쓰지 않습니다.
따라서 이제 우리 시대의 일부 일반적인 독점 운영 체제용으로 만들어진 프로그램을 이식하려면 파일 이름 대소문자 구분이 항상 일관되게 사용되도록 모든 경로를 수정해야 합니다. 그렇지 않으면 이러한 경우를 처리하는 파일 시스템을 갖는 것이 좋습니다.
Adobe는 MacOS에서 이 작업을 수행할 수 없으므로 다른 공급업체의 경우 작업이 더 어렵고 비용도 많이 듭니다. 바라보다https://helpx.adobe.com/creative-suite/kb/error-case-sensitive-drives-supported.html
답변3
대소문자를 구분하는 FS를 사용하는 유일한 이유는 모르겠습니다. 그것이 하는 유일한 일은 사용자를 완전히 혼란스럽게 한다는 것입니다. Microsoft 개발자는 처음부터 이를 이해했으며 깨진 개념에 신경 쓰지 않았습니다. 30년이 지난 지금, 일부 Linux 개발자는 대소문자를 구분하지 않는 것이 더 안전하고 논리적이라는 것을 깨닫고 마침내 이를 구현했습니다.
최초의 Unix 파일 시스템은 왜 대소문자를 구분했습니까? 이는 CPU가 사용하기 더 쉽기 때문일 수 있습니다. 비록 대소문자는 다르지만 유사한 이름을 가진 파일이 이미 존재하는지 확인하기 위해 CPU 주기를 소비하는 추가 기능이 필요하지 않습니다(대소문자를 구분하지 않는 것이 쉽지 않은 라틴어/영어 외에 다른 알파벳이 있습니다). 요즘에는 최신 초고속 CPU를 사용하면 더 이상 큰 문제가 되지 않습니다.