Linus Torvalds 및 OS X 파일 시스템


28

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

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


2
그는 git @ google에 관한 이야기를 할 때와 같이 어떤 것에 대해 정말 강한 의견을 가진 것으로 유명합니다. 그래서 그는 아마도 그가 생각하는 것을 믿을만한 이유가 있다고 말하지만 천재이지만 과장된 사람이기도합니다. youtube.com/watch?v=4XpnKHJAok8
El Developer

3
이 질문에 대한 응답을 얻지 못하면 Unix & Linux 또는 Super User 에서 검색 (및 요청)을 고려할 수도 있습니다 . (현재 사용 가능한 사이트가 너무 많아서 질문 곳 이 무엇인지 알기가 어렵습니다 . 적어도 IMHO. :)
비합리적인 John

나는 일반적으로 발생하는 다른 파일 시스템보다 HFS +로 머리를 맞대는 경향이 있습니다. 요즘 대부분의 시스템에서는 일반적으로 사용중인 파일 시스템에 대해 알거나 신경 쓰지 않는 것처럼 느껴지지만 HFS +에는 항상 무언가가 있습니다. 오늘처럼 모드 시간에 대한 초 미만의 해상도 부족으로 인해 망 가지고 있음을 알았습니다. 파일 시스템에서 교착 상태를 유발할 수있는 두 줄의 C 코드를 발견했을 때도 전체 시스템을 거의 중단시킵니다. 10.5부터는 수정되지 않았습니다. 최신 버전이 확실하지 않습니다.
Iguananaut

답변:


21

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에서는 그렇지 않습니다.


1
훌륭한 링크; 많은 중요한 것들을 다루고 있습니다. 드문 드문 파일 지원 부족은 매우 불쾌합니다. Linux ext2는 HFS + 사용과 같은 간단한 블록 비트 맵 기반 할당으로도 스파 스 파일을 만들었습니다. 그래도 그는 빅 엔디안으로 메타 데이터를 저장하는 것에 대해 너무 많은 거래를한다고 생각합니다. x86 bswap명령어는 매우 빠릅니다. 코드를 더 크고 추악하게 만들지 만 디스크 호환성을 유지하는 것이 중요합니다. Linux XFS는 MIPS CPU의 SGI에서 시작된 모든 메타 데이터 빅 엔디안 (저널의 네이티브 엔디안 제외)을 계속 저장합니다. 이상적인 상황은 아니지만 XFS는이를지지하지 않습니다.
Peter Cordes

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 스틱을 사용하는 등)을 이해하지만 파일을 만들 때 "알고있다"고 결정하고 파일 이름을 바꿉니다. ..

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


1
이것은 한 가지 점에 불과하며, 실제 문제는 다른 OS가 단순히 문자열을 다른 방식으로 정규화하고 크로스 플랫폼 앱이이를 처리하지 못한다는 것입니다. 이름을 정규화 하지 않으면 아마도 더 나쁠 것입니다 (OS X에서 동일한 문자열로 정규화되는 이름을 가진 두 개의 다른 파일이있을 수 있음).
Blaisorblade

4

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

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


9
답변에 대한 토론 요약을 제공 할 수있는 방법이 있습니까? 오디오 스트림은 현재 기술에서 검색 할 수없고 매우 길다. 다른 사이트에 있다는 것은 말할 것도없고 썩음에 연결되기 쉽습니다. 토론에 대한 세부 정보가 포함되어 있으면 훨씬 더 나은 답변이 될 것입니다.
Ian C.

1
파일 시스템 대화는 23 분 후에 시작됩니다.
neoneye

1
Podcast에있는 대부분의 정보 는 John Siracusa (Podcast의 두 사람 중 하나)의 Ars Technica 기사 에서도 찾을 수 있습니다 .
TML
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.