계층적 파일 시스템

Hierarchical File System
파일 시스템 계층 표준 또는 계층 파일 시스템(IBM MVS)과 혼동하지 마십시오.
HFS
개발자애플 컴퓨터
풀네임계층적 파일 시스템
소개했다1985년 9월 17일; 36년 전(1985-09-17) 시스템 2.1
파티션 식별자Apple_HFS(Apple 파티션 맵)
0xAF(MBR) HFS 및 HFS+
구조물들
디렉토리 내용B-트리
파일 할당비트맵
불량블록B-트리
한계
최대 볼륨 크기2TB(2 × 1024바이트4)
최대 파일 크기2GB(2 × 1024바이트3)
최대 파일 수65535
최대 파일 이름 길이31자
파일 이름에 허용된 문자콜론 ":"를 제외한 모든 8비트 값무효 및 비인쇄.
특징들
기록된 날짜생성, 수정, 백업
날짜 범위1904년 1월 1일 - 2040년 2월 6일
날짜 결정1s
포크단 2개(데이터 및 리소스)
특성색상(3비트, 기타 모든 플래그 1비트), 잠금, 사용자 지정 아이콘, 번들, 보이지 않음, 별칭, 시스템, 개인양식, 입력됨, INIT 리소스 없음, 공유, 데스크톱
파일 시스템 권한애플셰어
투명 압축예(타사), 스택커
투명 암호화아니요.
기타
지원되는 운영 체제Mac OS, MacOS, Linux, Microsoft Windows(MacDrive 또는 Boot Camp 사용)IFS 드라이버)[citation needed]

계층형 파일 시스템(HFS)은 애플사가 맥 OS를 실행하는 컴퓨터 시스템에서 사용하기 위해 개발한 독점 파일 시스템이다.원래 플로피 디스크나 하드 디스크에서 사용하기 위해 고안된 것으로 CD-ROM과 같은 읽기 전용 매체에서도 찾아볼 수 있다. HFS는 맥 OS Standard(또는 HFS Standard)라고도 하며, 후임인 HFS Plus는 맥 OS Extended(또는 HFS Extended)라고도 한다.

애플은 맥 OS X 10.6의 도입으로 읽기 전용 볼륨으로 남아 있는 HFS 디스크와 이미지 포맷이나 쓰기에 대한 지원을 중단했다.[1]MacOS 10.15부터는 HFS 디스크를 더 이상 읽을 수 없다.

역사

애플은 1985년 9월 특히 매킨토시용 최초의 하드디스크 드라이브를 지원하기 위해 HFS를 도입해 1년 반 전에 도입된 파일 시스템인 매킨토시 파일 시스템(MFS)을 첫 매킨토시 컴퓨터로 대체했다.HFS는 애플 III와 애플 리사의 계층적 파일 시스템의 기초가 되기도 했던 실패한 애플 III에 대해 애플 최초의 계층적 운영체제(SOS)를 무겁게 끌어당겼다.HFS는 Patrick Dirks와 Bill Bruffey에 의해 개발되었다.당시의 다른 파일 시스템(DOS의 FAT 등)에서는 이용할 수 없었던 다수의 설계 특징을 MFS와 공유했다.파일에는 여러 개의 포크(일반적으로 데이터 및 리소스 포크)가 있을 수 있으므로 파일의 메인 데이터를 현지화해야 할 수 있는 아이콘과 같은 리소스와 별도로 저장할 수 있다.파일 이름은 파일 이름이 아닌 고유한 파일 ID로 참조되었으며 파일 이름은 255자일 수 있다(Finder는 최대 31자까지만 지원함).

그러나 MFS는 매우 작고 느린 미디어, 즉 플로피 디스크에서 사용되도록 최적화되어 있었기 때문에, HFS는 더 큰 미디어, 특히 하드 드라이브의 도입과 함께 도래한 일부 성능 문제를 극복하기 위해 도입되었다.주요 관심사는 폴더 내용을 표시하는 데 필요한 시간이었다.MFS 아래에서 모든 파일 및 디렉터리 목록 정보는 단일 파일에 저장되었고, 시스템은 이를 검색하여 특정 폴더에 저장된 파일 목록을 작성해야 했다.이는 수백 킬로바이트의 스토리지와 아마도 수백 개의 파일이 있는 시스템에서 잘 작동했지만 시스템이 메가바이트와 수천 개의 파일로 성장함에 따라 성능이 급격히 저하되었다.

해결책은 MFS의 디렉토리 구조를 더 큰 파일 시스템에 적합한 하나의 구조로 대체하는 것이었다.HFS는 평평한 테이블 구조를 크기에 상관없이 매우 빠르게 검색할 수 있는 B-트리 구조를 사용하는 카탈로그 파일로 대체했다.HFS는 또한 32비트로 대체되는 16비트 정수를 더 많이 담을 수 있도록 다양한 구조를 재설계했다.이상하게도 이 "업사이징"이 일어나지 않은 몇 안 되는 장소 중 하나는 파일 디렉토리 자체였는데, 이것은 HFS를 각 논리 디스크의 총 65,535개의 파일로 제한한다.

HFS는 독점적인 파일 시스템 형식이지만, 잘 문서화되어 있다. 대부분의 최신 운영 체제에서 HFS 형식 디스크에 액세스할 수 있는 솔루션이 있다.

애플은 1985년 9월 매킨토시용 최초의 20MB 하드 디스크 제품으로 HFS를 필요 없이 도입했는데, HFS는 패치 파일("하드 디스크 20")을 사용하여 부팅 시 MFS 플로피 디스크에서 RAM에 로딩되었다.그러나 HFS도 HFS를 사용한 매킨토시용 800KB 플로피 디스크 드라이브와 함께 1986년 1월 매킨토시 플러스로 데뷔한 128K ROM에 포함될 때까지 널리 소개되지 않았다.HFS의 도입은 애플이 매킨토시 컴퓨터 모델을 뒤로 한 최초의 진보였다: 원래의 128K 매킨토시. HFS 코드를 로딩하기에 충분한 메모리가 부족했고 즉시 중단되었다.

1998년 애플은 HFS에서 디스크 공간의 비효율적인 할당을 해결하고 다른 개선사항을 추가하기 위해 HFS Plus를 도입했다.HFS는 현재 버전의 Mac OS에서 여전히 지원되지만, Mac OS X부터는 부팅에 HFS 볼륨을 사용할 수 없고, Mac OS X 10.6(Snow Leopard)부터는 HFS 볼륨이 읽기 전용이며, 생성하거나 업데이트할 수 없다.맥OS 시에라(10.12)에서는 애플의 릴리스 노트에 "HFS 표준 파일 시스템은 더 이상 지원되지 않는다"[2]고 명시되어 있다.그러나, 읽기 전용 HFS Standard 지원은 여전히 시에라에서 존재하며 이전 버전에서 그랬던 것처럼 작동한다.

디자인

스토리지 볼륨은 본질적으로 512바이트의 논리 블록으로 나뉜다.계층적 파일 시스템은 이러한 논리 블록을 할당 블록으로 그룹화하는데, 볼륨의 총 크기에 따라 하나 이상의 논리 블록을 포함할 수 있다.HFS는 16비트 값을 사용하여 할당 블록을 처리하여 할당 블록 수를 65,535개(2-116)로 제한한다.

5개의 구조물이 HFS 볼륨을 구성한다.

  1. 볼륨의 논리적 블록 0과 1은 시스템 시작 정보를 포함하는 부트 블록이다.예를 들어 시작할 때 로드되는 시스템 및 셸(일반적으로 Finder) 파일의 이름.
  2. 논리 블록 2는 마스터 디렉토리 블록(MDB라고 함)을 포함한다.이것은 볼륨 자체에 대한 매우 다양한 데이터를 정의하는데, 예를 들어 볼륨이 생성된 시점의 날짜 및 타임스탬프, 볼륨 비트맵과 같은 다른 볼륨 구조의 위치 또는 할당 블록과 같은 논리적 구조의 크기.또한 두 번째에서 마지막까지의 논리 블록까지 볼륨의 반대쪽 끝에 위치한 대체 마스터 디렉토리 블록(일명 대체 MDB)이라는 MDB의 복제본이 있다.이는 주로 디스크 유틸리티에서 사용하기 위한 것으로, 카탈로그 파일 또는 익스텐트 오버플로 파일 크기가 커질 때만 업데이트된다.
  3. 논리적 블록 3은 볼륨 비트맵의 시작 블록으로, 사용 중인 할당 블록과 사용 가능한 할당 블록을 추적한다.볼륨의 각 할당 블록은 맵에서 비트로 표현된다. 비트가 설정되면 블록이 사용 중이고, 클리어하면 블록을 자유롭게 사용할 수 있다.볼륨 비트맵에는 각 할당 블록을 나타내는 비트가 있어야 하므로 볼륨 자체의 크기에 따라 크기가 결정된다.
  4. 익스텐트 오버플로 파일(Extent Overflow File)은 카탈로그 파일의 초기 3개 익스텐트가 사용되면 어떤 할당 블록이 어떤 파일에 할당되는지 기록하는 추가 익스텐트를 포함하는 B 트리다.이후 버전에서는 파일 시스템이 파일에 불량 블록을 할당하려고 시도하지 않도록 하기 위해 불량 블록을 기록하는 익스텐트를 저장할 수 있는 기능도 추가되었다.
  5. 카탈로그 파일은 볼륨에 저장된 모든 파일과 디렉터리에 대한 레코드를 포함하는 또 다른 B-트리입니다.그것은 네 가지 종류의 기록을 저장한다.각 파일은 파일 스레드 레코드와 파일 레코드로 구성되며, 각 디렉토리는 디렉토리 스레드 레코드와 디렉토리 레코드로 구성된다.카탈로그 파일의 파일 및 디렉토리는 고유한 카탈로그 노드 ID(또는 CNID)에 의해 위치한다.
    • 파일 스레드 레코드는 파일 이름과 상위 디렉터리의 CNID만 저장한다.
    • 파일 레코드는 파일의 CNID, 파일 크기, 세 개의 타임스탬프(파일이 생성된 시점, 마지막으로 수정된 시점, 마지막으로 백업된 시점), 데이터의 첫 번째 파일 범위 및 익스텐트 오버플로 파일에 있는 파일의 첫 번째 데이터 및 리소스 범위 레코드에 대한 포인터를 포함하여 파일에 대한 다양한 메타데이터를 저장한다.파일 레코드는 또한 파일 작성자 코드, 유형 코드, 파일이 표시되어야 하는 창 및 창 내의 위치를 포함하여 파일에 대한 속성을 저장하는 데 Finder에 의해 사용되는 두 개의 16바이트 필드를 저장한다.
    • 디렉토리 스레드 레코드는 디렉토리 이름과 상위 디렉토리의 CNID만 저장한다.
    • 디렉터리 내에 저장된 파일 수와 같은 데이터를 저장하는 디렉터리 레코드, 디렉터리의 CNID, 세 개의 타임스탬프(디렉토리가 생성된 시점, 마지막으로 수정된 시점, 마지막으로 백업된 시점)파일 레코드처럼, 디렉토리 레코드도 파인더에 의해 사용하기 위해 두 개의 16바이트 필드를 저장한다.이들은 디렉토리의 내용, 창의 표시 모드(아이콘 보기, 목록 보기 등) 및 창 스크롤 막대 위치 표시에 사용되는 창 너비와 높이, x&y 좌표 등을 저장한다.

제한 사항

모든 파일 및 디렉터리 레코드를 단일 데이터 구조로 저장하는 카탈로그 파일은 한 번에 하나의 프로그램만 이 구조에 쓸 수 있기 때문에 시스템이 멀티태스킹을 허용할 때 성능 문제가 발생하는데, 이는 하나의 프로그램 "호깅"으로 인해 많은 프로그램이 대기하고 있을 수 있다는 것을 의미한다.[3]이 파일이 손상되면 전체 파일 시스템이 파괴될 수 있기 때문에 또한 심각한 신뢰성 우려 사항이다.이는 별도의 구조(DOS의 FAT 파일 시스템 또는 Unix File 시스템 등)에 파일 및 디렉토리 레코드를 저장하는 다른 파일 시스템과 대비된다. 디스크 전체에 분산된 구조는 단일 디렉토리의 손상이 일반적으로 치명적이지 않으며 데이터가 손상되지 않은 파일에 보관된 데이터로 재구축될 수 있음을 의미한다.분량

또한 할당 블록이 65,535개로 제한되어 "최소" 크기인 파일이 디스크 크기의 1/65,535에 해당된다.따라서 어떤 볼륨이든 크기에 상관없이 최대 65,535개의 파일만 저장할 수 있었다.더욱이, 어떤 파일도 실제로 필요한 것보다 더 많은 공간을 할당받을 수 있을 것이다.디스크가 작을 때는, 개별 할당 블록 크기가 사소한 것이었기 때문에, 이것은 별로 중요하지 않은 일이었지만, 디스크가 1 GB 마크에 근접하기 시작하면서, 어떤 파일이라도 차지할 수 있는 최소의 공간(단일 할당 블록)이 과도하게 커져서, 상당한 양의 디스크 공간을 낭비하게 되었다.예를 들어 1GB 디스크의 경우 HFS의 할당 블록 크기가 16KB이므로 1바이트 파일이라도 16KB의 디스크 공간을 차지하게 된다.이러한 큰 파일은 파일 크기의 백분율로 공간을 적게 낭비하기 때문에 이러한 상황은 큰 파일(예: 사진, 데이터베이스 또는 오디오)을 가진 사용자에게는 문제가 되지 않았다.반면 작은 파일이 많은 사용자는 큰 할당 블록 크기로 인해 많은 공간을 잃을 수 있다.이것은 작은 볼륨에 저장된 작은 문서들이 큰 파티션에 상주하는 것보다 훨씬 적은 공간을 차지하기 때문에, 디스크 분할을 작은 논리 볼륨으로 만드는 것을 Mac 사용자들에게 매우 매력적으로 만들었다.FAT16 파일 시스템에도 같은 문제가 있었다.

HFS는 생성되거나 이름이 변경되지만 작동 시 대/소문자를 구분하지 않는 파일의 사례를 저장한다.

bombich.com에 따르면, HFS는 더 이상 카탈리나 및 향후의 MacOS 릴리즈에서 지원되지 않는다.

참고 항목

참조

  1. ^ Gagne, Ken (2009-08-31). "Losing legacy data to Snow Leopard". Computerworld. Retrieved 2009-09-07.
  2. ^ "What's New in macOS: macOS Sierra 10.12". Apple. Retrieved 25 January 2017.
  3. ^ Giampaolo, Dominic (1999). Practical File System Design with the Be File System (PDF). Morgan Kaufmann. p. 37. ISBN 1-55860-497-9. Archived from the original (PDF) on 2017-02-13. Retrieved 2006-07-13.

외부 링크