파일 시스템의 진화

컴퓨터가 디스크 운영 체제에서 작동하도록 개발되기 전에 각 컴퓨터는 전체 컴퓨터를 완전하고 독점적으로 제어할 수 있는 단일 독점 애플리케이션을 실행하도록 빌드되었습니다. 애플리케이션은 디스크 컨트롤러에 직접 명령을 전송하여 영구 데이터를 디스크 또는 드럼에 직접 씁니다. 애플리케이션은 디스크에 있는 데이터의 절대 위치를 관리하여 기존 데이터를 덮어쓰지 않도록 해야 했습니다. 한 번에 하나의 응용 프로그램만 컴퓨터에서 실행 중이므로 이 작업이 너무 어렵지 않았습니다.

둘 이상의 애플리케이션을 실행할 수 있는 컴퓨터 시스템의 출현에는 애플리케이션이 서로의 데이터에 기록되지 않도록 하는 메커니즘이 필요했습니다. 애플리케이션 개발자는 사용 중인 디스크 섹터를 적절하게 표시하여 사용 중인 디스크 섹터와 구분하기 위한 단일 표준을 채택하여 이 문제를 해결했습니다. 시간이 지나면 이러한 표준이 통합되어 영구 스토리지를 관리하기 위한 파일 시스템을 포함하여 애플리케이션에 다양한 서비스를 제공하는 디스크 운영 체제가 되었습니다. 파일 시스템의 출현으로 애플리케이션은 더 이상 물리적 스토리지 매체를 직접 처리할 필요가 없었습니다. 대신 파일 시스템에 데이터 블록을 디스크에 쓰고 파일 시스템에서 이 작업을 수행하는 방법을 걱정하도록 했습니다. 또한 파일 시스템을 통해 애플리케이션은 디렉터리라고 하는 추상화로 데이터 계층을 만들 수 있습니다. 디렉터리에는 파일뿐만 아니라 다른 디렉터리도 포함될 수 있으며, 이 디렉터리에는 자체 파일 및 디렉터리 등이 포함될 수 있습니다.

파일 시스템은 애플리케이션과 디스크 간에 단일 수준의 간접 참조를 제공했으며, 그 결과 모든 애플리케이션은 파일 시스템이 실제로 파일을 불협화음 섹터에 저장하고 있었음에도 불구하고 파일을 디스크의 단일 연속 바이트 스트림으로 보았습니다. 간접 참조를 통해 애플리케이션은 스토리지 디바이스에서 데이터의 절대 위치를 추적할 필요가 없습니다.

현재 파일 입력 및 출력을 위한 거의 모든 시스템 API는 플랫 파일에 정보를 쓰기 위한 애플리케이션을 제공합니다. 애플리케이션은 이 파일을 디스크가 가득 찼을 때까지 필요한 만큼 커질 수 있는 단일 바이트 스트림으로 간주합니다. 오랫동안 이러한 API는 애플리케이션이 영구 정보를 저장하기에 충분했습니다. 애플리케이션은 증분 "빠른" 저장과 같은 기능을 제공하기 위해 단일 정보 스트림을 처리하는 방법을 크게 혁신했습니다.

그러나 구성 요소 개체의 세계에서는 단일 플랫 파일에 데이터를 저장하는 것이 더 이상 효율적이 아닙니다. 파일 시스템이 여러 애플리케이션에서 동일한 스토리지 매체를 공유할 필요가 없는 것처럼, 이제 구성 요소 개체에는 단일 파일의 개념 프레임워크 내에서 스토리지를 공유할 수 있는 시스템이 필요합니다. 기존 플랫 파일 스토리지를 사용하여 별도의 개체를 저장할 수 있지만 개체 중 하나의 크기가 증가하거나 다른 개체를 추가하기만 하면 전체 파일을 메모리에 로드하고 새 개체를 삽입한 다음 전체 파일을 저장해야 합니다. 이 프로세스는 시간이 많이 걸릴 수 있습니다.

COM에서 제공하는 솔루션은 파일 내의 파일 시스템이라는 두 번째 수준의 간접 참조를 구현하는 것입니다. 플랫 파일 스토리지를 사용하려면 단일 검색 포인터가 있는 단일 파일 핸들을 통해 디스크의 큰 연속 바이트 시퀀스를 조작해야 합니다. 반면 COM 구조적 스토리지는 단일 파일 시스템 엔터티를 디렉터리 및 파일처럼 작동하는 두 가지 유형의 개체(스토리지 및 스트림)의 구조화된 컬렉션으로 처리하는 방법을 정의합니다.