경쟁 파일 시스템 설계가 많은 이유는 무엇입니까? [닫은]

간단한 질문이지만 오늘날 왜 여전히 많은 파일 시스템이 경쟁하고 사용되고 있습니까? (ntfs, fat32, ext3 (ffs) 등)

파일 시스템 설계자들은 각 유형의 시스템의 최상의 측면에 동의하고 "최상의"파일 시스템을 구현할 수있을 것 같습니다. 이러한 파일 시스템이 한동안 존재 해 왔기 때문에 어떤 파일 시스템이 다른 파일 시스템보다 좋은 품질을 가지고 있는지는 어느 정도 분명해야하며, 각각의 장점을 결합하여 훨씬 더 나은 궁극적 인 시스템을 만들 수 있습니다.

인용 한 예를 사용하여 여기에 대한 구체적인 내용을 잠시 생각해 보겠습니다.

• ntfs-Microsoft 독점. Microsoft가 아닌 사람은 이것을 사용할 수 없으므로 다른 것을 사용하거나 만들어야합니다. 이제 Microsoft 인 경우 다음 글 머리 기호 문제로 인해 FAT를 통해이를 사용하려고합니다.

• fat32-충분히 현대적이지 않습니다. 최대 파일 크기는 4GB입니다. 디렉토리 항목 조회는 O (n)입니다. 할당 테이블은 할당 비트 맵 (연속적인 여유 공간을 찾는 것이 매우 빠름)과 같이보다 효율적인 것이 아니라 연결된 목록입니다. 권한을 지원하지 않습니다. 하드 링크 또는 기호 링크를 지원하지 않습니다. 저널링을 지원하지 않습니다.

• ext3-이것은 주로 저널링을 지원하기 위해 ext2의 확장이었습니다.

따라서 몇 가지 이유가 있습니다.

1. 초기 파일 시스템에는 무언가가 부족합니다. FAT의 경우 (1) 기능과 (2) 성능 측면에서 많이 부족합니다. ext2의 경우 저널링 된 업데이트가 없었으므로 충돌에서 복구하는 데 시간이 더 걸렸습니다.

2. 기존의 파일 시스템은 아마도 당신의 것이 아닙니다. (예 : Microsoft가 아닌 경우 NTFS). 이 경우 실제로 많은 선택의 여지가 없지만 자신의 것을 선택할 수 있습니다.

짧은 대답 : 하나의 크기가 모든 것에 맞지는 않습니다.

트레이드 오프가 있습니다. 예를 들어 저널링 된 FS를 원한다면 비용 (효율성, 복잡성 등)을 지불하지만 그로부터 무언가를 얻습니다. 어떤 사람들은 저널링 된 FS의 필요성을 느끼지 않고 그것을 지불하기를 원하지 않으며, 어떤 사람들은 그렇게합니다. FS의 다른 "기능"과 동일합니다.

"최고"가 무엇인지에 대한 많은 의견이 있기 때문에 아무것도 "최고"가 될 수 없습니다. 결정은 사용자의 요구와 한계에 따라 다릅니다. 디자인은 항상 구속 조건에 맞는 능력을 기반으로합니다.

기본 휴대 전화에는 수백 개의 연락처, 문자 메시지 기록 및 작은 앱이 저장되어 있어야합니다. 파일 시스템이 RAID 구성의 멀티 테라 바이트 드라이브에서 계층 적 디렉토리 구조를 지원해야합니까? 장치에 이러한 파일 시스템을 실행하기에 충분한 RAM이 있습니까? 파일 시스템에 복잡한 ACL이 필요합니까? 아마도 모든 질문에 대해 간단하지는 않을 것입니다. 따라서 간단한 리소스 확보 파일 시스템이면 충분합니다.

회사는 또한 경쟁 우위를 유지하기 위해 다른 제품을 개발할 것입니다. 예를 들어, Apple은 HFS + 파일 시스템이 백업이 빠르도록 최근에 변경된 파일을 추적 할 수있는 기능을 선전합니다. 반대로 FAT (플로피 디스크 파일 시스템) 용 드라이버는 몇 KB의 메모리에 적합 할 수 있습니다.

너무 최적화하려는 대상에 따라 다릅니다.

FAT를 잠깐 고려해보십시오. 긴 파일 이름에 대한 지원은 번거롭고 (잘 정리하기 위해) 디렉토리에서 파일을 검색하는 것은 선형이므로 디렉토리에 많은 파일이 포함 된 경우 매우 느리게 진행 됩니다. 동시에 원시 쓰기 속도에 대한 메타 데이터의 최소값은 매우 우수하며 전체적으로 매우 간단하기 때문에 구현하는 코드는 매우 작을 수 있습니다.

ext2 또는 ext3과 같은 기능은 FAT에없는 많은 기능을 추가합니다. 파일 검색도 훨씬 빠릅니다. 동시에 원시 쓰기 속도는 약간 느려질 수 있으며 파일 시스템을 구현하는 코드는 의심 할 여지없이 훨씬 더 큽니다.

간단한 질문이지만 오늘날 왜 여전히 많은 파일 시스템이 경쟁하고 사용되고 있습니까? (ntfs, fat32, ext3 (ffs) 등)

파일 시스템 설계자들은 각 유형의 시스템의 최상의 측면에 동의하고 "최상의"파일 시스템을 구현할 수있을 것 같습니다.

트레이드 오프가 없었고 파일 시스템 디자이너가 특허 걱정없이 "최고의"파일 시스템을 구현하고 MS와 데비안이 모두 수용 할 수 있도록 이중 라이센스 BSD / GPL로 릴리스했다고 가정 해 봅시다. 다른 파일 시스템이 밤새 사라질 것이라고 생각하는 이유는 무엇입니까?

10 년 동안 새로운 하드 드라이브에 FAT32를 사용한 사람은 없지만 USB 드라이브, SD 카드 등을 포맷하기위한 사실상의 표준으로 남아 있습니다. 카메라 및 휴대폰 제조업체는이를 사용하기 위해 펌웨어를 시험하고 테스트했습니다. Arduino 애호가들은 그것을 사용하기 위해 안정적인 라이브러리를 가지고 있습니다. 그들은 모두 변화하기 위해 큰 인센티브가 필요합니다.

그리고 이전 OS (특히 사용자가 새 파일 시스템 드라이버를 설치하지 않으려는 Windows)와의 하위 호환성 문제가 있습니다.

답을 계산할 때와 마찬가지로 (a) 과거 상황과 이전 버전과의 호환성을 유지해야 할 필요성 때문에 (b) 일부 방법이 다른 작업보다 일부 작업에 더 적합하기 때문입니다.

(a) 당신은 "윈체스터 드라이브"라는 것을 기억할 필요가 있습니다-나는 그것들이 그것들이라고 불리는 것을 기억할 정도로 나이가 들었습니다. 전자 컴퓨팅의 시간과 심지어 그 비용 때문에 대부분의 사용자가 오랫동안 그렇게 할 수 없었습니다. FAT 파일 시스템은 플로피 디스크와 원래의 소형 하드 드라이브에서도 잘 작동했으며, 이는 효율적이고 낮은 오버 헤드가 필요했기 때문입니다. 일단 사용이 시작되고 사용이 간단하기 때문에 사용이 널리 확산되면 제조업체는 사용자에게 이전 데이터가 갑자기 잘못되었다고 말할 수 없었습니다.

마찬가지로 Linux 사용자의 경우 안정적인 NTFS 드라이버가 오랫동안 출시되었으므로 장치를 FAT로 포맷하면 여러 시스템에서 읽고 쓸 수있었습니다.

(b)-수십억 개의 텍스트 기반 데이터베이스 레코드를 저장하는 시스템과 DVD 길이의 미디어 파일을 저장하는 시스템의 차이점을 생각해보십시오. 데이타베이스의 경우 각 레코드는 매우 작을 수 있습니다. 아마도 30 또는 40 바이트 일 수 있으며 디스크의 전체 '세그먼트'(하지만 정의하려는)를 할당 한 파일 시스템은 디스크 공간을 낭비 할 수 있습니다. DVD에서는 그렇지 않습니다. 더 큰 '세그먼트'(이유가 분명한 이유는)는 공간적인 측면에서 매우 효율적일 것입니다.

따라서 다른 파일 시스템은 다른 목적으로 설계되었습니다.

모든 사람에게 완벽한 파일 시스템이없는 이유의 또 다른 예 : HDD와 SSD는 매우 다른 읽기 / 쓰기 액세스 특성을 갖습니다. SSD에 최적화 된 파일 시스템은 미친 것처럼 파일을 조각화하지만 모든 조각에서 SSD 자체의 페이지 크기로 가장 잘 작동합니다. 이것은 HDD에서 끔찍하게 수행됩니다. HDD에 최적화 된 파일 시스템은 파일을 가능한 한 조각화하지 않은 상태로 유지하려고하며 자주 사용하는 파일을 플래터의 가장 빠르게 회전하는 외부 부분의 "핫"영역에 넣습니다. 이러한 특성은 SSD가 속도를 읽는 데 전혀 도움이되지 않으며 SSD 쓰기 속도에 큰 영향을 미칩니다.

나는 매우 중요한 사실이 빠져 있다고 생각합니다. 대부분의 프로그래머는 자신의 작업 방식이 다른 모든 방식보다 우수하다고 생각하는 경향이 있으므로 파일 시스템 설계를 검토하고보다 일반적이고 우아하며 빠르며 옳은 것처럼 보이는 문제와 솔루션을 제시합니다. 이 느낌이 충분히 강하면 자신의 파일 시스템을 자유롭게 만들 수 있습니다.

이것은 경쟁, 파편화, 혼란에 달려 있으며 결국 더 나은 솔루션과 더 많은 옵션이 귀하에게 맞는 솔루션을 선택하기를 바랍니다.

다음은 별도의 파일 시스템이 필요하거나 기존 FS의 기능을 확장해야하는 또 다른 구체적인 예입니다.

1. 데이터베이스 공급 업체이고 IO의 향상을 위해 데이터의 스트라이핑 / 미러링 관리의 복잡성을 줄이고 싶다고 가정 해보십시오. Oracle이 Logical Volume Manager와 같은 ASM (Automated Storage Manager)을 사용하여 기본 파일 시스템의 기능을 확장해야 할 필요성을 느끼게됩니다.

목록에서 더 나은 파일 시스템을 사용할 수 없지만 빠르기 때문에 오래된 파일 시스템을 언급했습니다.

다른 파일 시스템이 있습니다. 하나의 하드 드라이브 또는 서버가 다운되면 Google 파일 시스템 이 대부분 빠른 복제 / 중복을위한 것이라고 들었 습니다. 많은 작은 파일을 위해 만들어진 다른 파일 시스템을 듣고 작은 파일에 대한 많은 요청을 위해 시스템에서 사용되는 것을 기억합니다 (축소판).

본질적으로 그들은 서로 다른 목표를 가지고 있거나 적절하거나 오픈 소스 일 수 있습니다.

ZFS (Sun 시스템 [현재 Oracle]에서 Solaris에서 사용)는 파일 시스템을위한 솔루션이라고 생각합니다.

불행히도 오라클은 발견자를 위해 OpenSolaris를 닫고 테스트합니다.

ZFS는 오픈 소스이며 일부 Linux는이를 통합하려고합니다. 자세한 정보는 Wikipedia를 참조하십시오.