Linus Torvalds 및 OS X 파일 시스템

2008 년에 Linus Torvalds 는 인터뷰 에서 "OS X는 실제로 Windows보다 프로그램에 비해 나빠졌습니다. 파일 시스템이 완전하고 허풍스럽고 무섭습니다." OS X 파일 시스템 (HFS +)에 대해 왜 이런 식으로 느끼는지에 대한 자세한 내용을 찾았지만 아무것도 찾을 수 없었습니다.

Linus는 기본 Unix 파일 시스템 모델을 싫어하지 않으며 대소 문자를 구분하지 않는 HFS +를 싫어하는 것 같습니다. 그리고 그의 말이 얼마나 도발적으로 표현 되었음에도 불구하고, 그것이 전혀 장점이없는 것 같습니다. 의견은 OS X 프로그래밍과 관련이 있기 때문에 그의 의견은 성능, 견고성, 운영 체제 인터페이스 또는 그 라인을 따르는 무언가에 기초한 것으로 생각됩니다. 2008 년 Linus가 2008 년 HFS +에 대해 어떤 불만을 가지고 있는지 아는 사람이 있습니까?

Linus가 의견을 제시 한“Q & A”세션 의 사본 은 사용 가능하지만 정교하게 요청받지 않은 것 같습니다. HFS +에 대한 그의 의견에 대한보다 심층적 인 분석이 다른 곳에 작성되었는지는 확실하지 않습니다.

다른 사람이 문제를 분석하려면 John Siracusa의 Mac OS X 리뷰를 살펴보십시오. 특히“ HFS +의 문제점 ”섹션이있는 Mac OS X Lion 용 제품 중 가장 두드러진 부분은 다음과 같습니다.

동시성, 올바른 바이트 순서로 작성된 메타 데이터, 2 초 미만의 날짜 정밀도, 대규모 볼륨 지원 및 스파 스 파일 지원은 모두 Unix 파일 시스템의 일반적인 기능입니다. 물론 Mac OS X은 Unix 기반을 기반으로합니다. HFS +를 클래식 Mac OS에서 Mac OS X로 포팅 할 때 Unix 파일 시스템에서 예상되는 일부 최소 기능 세트를 지원하도록 확장해야했습니다 .

이러한 기능 중 일부는 쉽게 맞지 만 다른 기능은 이전 버전과의 호환성을 유지하지 않고 파일 시스템에 추가하기가 매우 어려웠습니다. 특히 무서운 예는 HFS +에서 하드 링크를 구현하는 것입니다. 하드 링크를 추적하기 위해 HFS +는 볼륨의 루트 레벨에서 숨겨진 디렉토리 내부의 각 하드 링크에 대해 별도의 파일을 만듭니다. 숨겨진 디렉토리는 처음에는 소름 끼치지만 불필요한 데이터 중복을 피하기 위해 하드 링크를 사용하여 Time Machine을 구현한다는 사실을 기억할 때 실제로 겁이납니다.

여기서 중요한 점은 Mac OS X이 Unix 시스템 용으로 설계되지 않은 파일 시스템을 사용하고 있으며, 기존 Mac OS 용으로 설계되었으며 이전 버전과의 호환성을 유지하면서 Mac OS X 10.0의 기능을 구현하도록 패치되었습니다. 애플은 이후 맥 오에스텐 10.7 (저널링, 메타 데이터, 파일 시스템 이벤트 등)에 추가 기능을 구현했다. 나는 이것을 비 기술적으로 설명하는 방법을 잘 모르겠지만, 추가 기능이 모두 지원하지 않는 고전적인 Mac OS 기반에 있다고 말할 수 있습니다. 이것은 솔루션이 가능한 한 좋지 않다는 것을 의미합니다. Siracusa가 논의하고자하는 예는 HFS +의 한계 내에서 작업하는 동안 하드웨어 장애에 너무 민감하기 때문에 Apple이 하드 링크를 위해 사용해야했던 솔루션입니다. 청렴. 물론 Mac OS X 10.0에서는 클래식 Mac OS와의 호환성을 유지하는 것이 바람직한 제한 사항 이었지만 더 이상 Mac OS X 10.7에서는 그렇지 않습니다.

나는 운영 체제 전문가가 아니며 Windows에서 온 후 OSX를 사용하기 시작했지만 Windows에서 PowerUser로 생각하고 Linux에서 상당히 유능합니다. 그 배경에서 온 OSX와 같은 상당히 현대적인 OS에서 파일 시스템은 파일 이름이 "혼합"되는 방식과 같은 단점이 있다는 사실에 놀랐습니다.

Linus의 HFS + 문제는 같은 시점에서 비롯된 것으로 이해합니다. 문제를 조사한 결과 HFS +는 유니 코드를 사용하여 파일 이름을 저장하지만 파일이 "확장 된"또는 NON-ASCII 문자를 사용하는 경우 (예 : é, í, ó, ú, ñ 스페인어 또는 ü와 같은 것 (독일어의 ü)), 유니 코드가 이름을 인코딩하는 두 가지 방법을 제공하는 OSX는 저장 시간에 인코딩을 자동으로 "정규화"합니다. 파일은 OSX에서 생성되고 소비되었지만 다른 OS 사용자와 정보를 공유 할 때 파일 이름 이 변경 된다는 사실 은 모든 종류의 이상한 행동을합니다 ...

적절한 예 : 지난 8 년 동안 Subversion에서 내 작품 "아티팩트"(파일, 문서 등)를 추적 해 왔습니다. Mac으로 이동할 때 Mac 용 SVN 클라이언트를 얻었고 관련 디렉토리를 체크 아웃 한 후 악센트가있는 모든 파일이 누락 된 것으로 나타 났으며 동일한 이름을 가진 새 파일이 버전이없는 것으로 나타납니다. 그것을 파헤 치면 문제는 파일 시스템의 파일이 사과로 인코딩되는 반면 저장소의 데이터는 다른 (완벽하고 합법적 인) 유니 코드 인코딩을 사용한다는 것입니다 ...

이것은 내 데이터의 총체적인 "관리"라고 생각합니다. Apple DOES는 파일 이름 인코딩 형식 (Windows에서 공유에 액세스하거나 Windows에서 USB 스틱을 사용하는 등)을 이해하지만 파일을 만들 때 "알고있다"고 결정하고 파일 이름을 바꿉니다. ..

다시 말하지만, 대부분의 사용자는 파일 사본을 만들거나 파일 이름을 바꾸고 원래 파일이 있던 위치로 되돌리고 분명히 동일한 두 파일로 끝나기 전까지는 알지 못합니다!)

John Siracusa와 Dan Benjamin은 Hypercritical # 56 에서 HFS +의 몇 가지 단점에 대해 설명 합니다.

HFS +의 데이터 손상을 해결하고 ZFS의 일부 기능을 고려합니다.