작년에 발표된 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를 사용한 다음 커널 내부를 사용하여 대소문자를 구분하지 않는 방식을 에뮬레이트했습니다.SDCardFS. 그러나 SDCardFS는 프로세스를 개집 공간†으로 이동하여 모든 것을 더 빠르게 만들었습니다. 여전히 파일 시스템을 탐색해야 했고(따라서 IO 바인딩이 필요했으며) 경쟁 조건이 발생했으며 근본적으로 건전하지 않았습니다. 따라서 Google이 F2FS에서 디렉터리별 대소문자 구분 없는 기본 개발에 자금을 지원했고 그 이후로 더 이상 사용되지 않는 이유는 무엇입니까?SDCardFS.
과거에는 VFS를 통해 대소문자를 구분하지 않는 조회를 활성화하려는 시도가 여러 번 있었습니다. 2018년의 가장 최근 시도에서는파일 시스템의 대소문자 구분 보기. Ted Tso는 이 기능을 추가하기 위해 Wrapfs의 문제를 구체적으로 언급했습니다. 적어도 더 빠르고 경쟁 조건이 없을 것이기 때문입니다. 그러나 여전히 건전하지 않았습니다(요청하면 또는 README.TXT가 반환될 수 있음 ). 이는 대소문자를 구분하지 않는 디렉토리별 지원을 추가하기 위해 거부되었으며 VFS††에 포함되지 않을 것입니다.readme.txtREADME.txt
또한 사용자는 대소문자를 구분하지 않기를 기대하므로 모든 소비자 지향 운영 체제에서 이를 제공해야 합니다. 유니코드가 존재하지 않았고 문자열이 단지 바이트 단위였기 때문에 Unix는 이를 기본적으로 지원할 수 없었습니다. 케이스 폴딩이 어떻게 처리되었는지에 대한 타당한 비판이 많이 있습니다.과거에, 그러나 유니코드는불변 케이스 접기 기능그건 모두에게 효과가 있지만단일 로케일(터키어, 심지어는 두 개의 코드 포인트일 뿐입니다). 그리고파일 시스템 B-트리이 동작을 구현하는 유일한 합리적인 장소입니다.
†AFAFICT
††나는 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를 사용하는 이유는 단 한 가지도 모르겠습니다. FS가 하는 유일한 일은 사용자를 완전히 혼란스럽게 한다는 것입니다. Microsoft 개발자는 처음부터 이를 이해했으며 깨진 개념에 신경 쓰지 않았습니다. 30년이 지난 지금 일부 Linux 개발자는 대소문자를 구분하지 않는 것이 더 안전하고 논리적이라는 것을 깨닫고 마침내 이를 구현했습니다.
최초의 Unix 파일 시스템이 대소문자를 구분한 이유는 무엇입니까? CPU에서 작업하는 것이 더 쉽기 때문일 수 있습니다. 대소문자가 다르지만 유사한 이름을 가진 파일이 이미 존재하는지 확인하기 위해 CPU 주기를 소비하는 추가 기능이 필요하지 않습니다(또한 대소문자 구분을 구현하는 것이 쉽지 않은 라틴어/영어 이외의 알파벳도 있습니다). 요즘에는 최신 초고속 CPU를 사용하면 별 문제가 되지 않습니다.