파일 시스템 API

파일 시스템 API는 유틸리티 또는 사용자 프로그램이 파일 시스템의 서비스를 요청하는 애플리케이션 프로그래밍 인터페이스입니다.운영체제는 다른 파일시스템에 투과적으로 접근하기 위한 추상화를 제공할 수 있다.

일부 파일 시스템 API에는 파일 시스템 생성 또는 초기화, 파일 시스템 무결성 확인 및 조각 모음과 같은 유지관리 작업을 위한 인터페이스가 포함될 수도 있습니다.

각 운영 체제에는 지원하는 파일 시스템에 필요한 API가 포함되어 있습니다.Microsoft Windows에는 NTFS 및 여러 FAT 파일 시스템용 파일 시스템 API가 있습니다.Linux 시스템은 ext2, ext3, ReiserFS 및 Btrfs용 API를 포함할 수 있습니다.

역사

일부 초기 운영 체제에서는 테이프 및 디스크 파일 시스템만 처리할 수 있었습니다.이것들은, 다음의 인터페이스 중 가장 기본적인 것을 제공했습니다.

쓰기, 읽기 및 위치 지정

디바이스의 할당이나 할당 해제등의 조정에는, 다음의 추가가 필요했습니다.

개폐

파일 시스템이 더 많은 서비스를 제공함에 따라 더 많은 인터페이스가 정의되었습니다.

메타데이터 관리
파일 시스템 유지보수

추가 파일 시스템 유형, 계층 구조 및 지원되는 미디어가 증가함에 따라 다음과 같은 몇 가지 특별한 기능이 필요하게 되었습니다.

디렉토리 관리
데이터 구조 관리
기록 관리
비데이터 조작

다중 사용자 시스템에서는 다음을 위한 API가 필요했습니다.

공유.
접근 제한
암호화

API의 개요

쓰기, 읽기 및 위치 지정

파일 시스템에 사용자 데이터를 쓰는 것은 사용자 프로그램 또는 런타임 라이브러리에 의해 직접 사용할 수 있도록 제공된다.일부 프로그래밍 언어의 런타임 라이브러리는 유형 변환, 형식 지정 및 차단을 제공할 수 있습니다.일부 파일 시스템에는 키로 레코드를 식별할 수 있으며 기존 레코드를 다시 쓰는 기능이 포함될 수 있습니다.이 조작은, 또는 라고 불리는PUT 경우가 있습니다.PUTX(기록이 존재하는 경우)

사용자 데이터 읽기(GET라고도 함)에는 방향(전방향 또는 역방향) 또는 키가 있는 파일 시스템의 경우 특정 키가 포함될 수 있습니다.쓰기 런타임 라이브러리는 사용자 프로그램에 대해 중재할 수 있습니다.

위치 결정에는 다음 레코드의 위치 조정이 포함됩니다.여기에는 앞으로 또는 뒤로 건너뛰기 및 파일의 처음 또는 끝에 위치하는 작업이 포함됩니다.

개폐

오픈 API는 오브젝트상의 프로세스에 의해 첫 번째 조작이 발행되었을 때 명시적으로 요구되거나 암묵적으로 호출될 수 있습니다.이로 인해 이동식 미디어가 마운트되어 다른 호스트에 대한 연결이 설정되고 개체의 위치와 액세스 가능성이 검증될 수 있습니다.시스템 구조를 업데이트하여 개체가 사용 중임을 나타냅니다.

파일 시스템 개체에 대한 액세스를 요청하기 위한 일반적인 요구 사항은 다음과 같습니다.

액세스할 개체(파일, 디렉터리, 미디어 및 위치)
오픈 후에 실행하는 작업 타입(읽기, 갱신, 삭제)

예를 들어 추가 정보가 필요할 수 있습니다.

암호
오픈 프로세스가 오브젝트(공유)를 사용하는 동안 다른 프로세스가 동일한 오브젝트에 액세스할 수 있다는 선언입니다.이는 다른 프로세스의 의도에 따라 달라질 수 있습니다.반대로 다른 프로세스는 다른 프로세스의 의도와 관계없이 오브젝트에 액세스할 수 없다는 선언(배타적 사용)입니다.

이러한 요청은 파일 시스템에 요청을 전송할 뿐만 아니라 프로세스에서 모듈 간의 조정을 제공할 수 있는 프로그래밍 언어 라이브러리를 통해 요청됩니다.

오픈 처리 중에 문제가 발생할 수 있습니다.

개체 또는 의도가 잘못 지정되었을 수 있습니다(이름에 허용되지 않는 문자가 포함되어 있거나 의도를 인식할 수 없음).
이 프로세스에서는 오브젝트에 대한 액세스가 금지될 수 있습니다(그룹 또는 특정 사용자만 접근할 수 있습니다).
파일 시스템은 사용자 간의 작업을 조정하는 데 필요한 구조를 만들거나 업데이트하지 못할 수 있습니다.
새(또는 교체) 개체의 경우 미디어 용량이 부족할 수 있습니다.

프로그래밍 언어에 따라 개방된 추가 사양에 따라 모듈이 이러한 조건을 처리할 수 있습니다.일부 라이브러리는 파일 시스템에 라이브러리 모듈을 지정하여 오류가 발생하여 오프닝 프로그램이 의미 있는 액션을 수행할 수 없는 경우 분석을 허용합니다.예를 들어, 필요한 입력 파일을 열려고 할 때 실패했을 경우, 유일한 조치는 오류를 보고하고 프로그램을 중단하는 것입니다.일부 언어에서는 오류 유형을 나타내는 코드를 반환하기만 하면 됩니다.이 코드는 프로그램이 항상 확인해야 하며 보고 대상과 계속할 수 있는지 여부를 결정합니다.

닫으면 이동식 미디어를 분리하거나 꺼내고 라이브러리와 파일 시스템 구조를 업데이트하여 개체가 더 이상 사용되지 않음을 나타낼 수 있습니다.닫힘에 대한 최소 사양은 개체를 참조합니다.또한 일부 파일 시스템은 오브젝트가 폐기되어 더 이상 파일 시스템의 일부가 아님을 나타낼 수 있는 오브젝트의 배치를 지정합니다.오픈과 마찬가지로 뭔가 잘못될 수도 있다고 예상해야 합니다.

개체 지정이 올바르지 않을 수 있습니다.
버퍼링 중인 데이터를 저장하거나 개체가 성공적으로 업데이트되었음을 나타내는 구조를 출력할 수 있는 충분한 용량이 미디어에 없을 수 있습니다.
버퍼링된 데이터, 완료 구조 또는 오브젝트와 관련된 메타데이터 갱신 중 오브젝트가 저장된 미디어에서 디바이스 오류가 발생할 수 있다(예를 들어 마지막 액세스 시간).
개체를 해제하는 사양이 개체를 사용하는 다른 프로세스와 일치하지 않을 수 있습니다.

장애 처리를 위한 고려사항은 개방적인 고려사항과 유사합니다.

메타데이터 관리

파일의 데이터에 대한 정보를 메타데이터라고 합니다.

일부 메타데이터는 파일시스템에 의해 유지됩니다.예를 들어 최종 수정일(및 파일시스템에 따라 다른 여러 날짜), 파일 시작 위치, 파일 크기, 파일시스템 백업 유틸리티가 파일의 현재 버전을 저장했는지 여부 등이 있습니다.이러한 항목은 보통 사용자 프로그램에서 변경할 수 없습니다.

일부 파일 시스템에서 지원되는 추가 메타 데이터에는 파일의 소유자, 파일이 속한 그룹, 권한 및/또는 액세스 제어(즉,다양한 사용자 또는 그룹에 액세스하여 갱신할 수 있는 것) 및 디렉토리가 나열되었을 때 파일이 정상적으로 표시되는지 여부를 지정합니다.이러한 항목은 일반적으로 소유자가 실행할 수 있는 파일 시스템 유틸리티를 통해 수정할 수 있습니다.

일부 응용 프로그램은 더 많은 메타데이터를 저장합니다.이미지의 경우 메타데이터에는 카메라 모델과 사진 촬영에 사용되는 설정이 포함될 수 있습니다.오디오 파일의 경우 메타 데이터는 앨범, 녹음을 기록한 아티스트 및 파일의 특정 복사본에 고유할 수 있는 녹음에 대한 코멘트를 포함할 수 있다(즉, 같은 녹음의 다른 복사본은 파일 소유자에 의한 갱신으로서 다른 코멘트를 가질 수 있다).문서에는 체크인 기준, 승인 기준 등의 항목이 포함될 수 있습니다.

디렉토리 관리

파일 이름 변경, 파일(또는 하위 디렉토리)의 디렉토리 이동 및 파일 삭제는 디렉토리 관리를 위해 파일시스템에 의해 제공되는 조작의 예입니다.

통상, 다양한 유저 또는 유저 그룹에 의한 디렉토리 액세스의 허가나 제한등의 메타데이터 조작이 포함됩니다.

파일 시스템 유지보수

파일 시스템을 사용하면 파일 및 레코드를 추가, 삭제 또는 변경할 수 있습니다.이로 인해 기본 데이터 구조가 비효율적으로 됩니다.미디어 전체에 걸쳐 논리적으로 순차적으로 배포되는 블록과 같은 블록은 링크된 구조에 포함된 빈 블록도 부분적으로 사용됩니다.불완전한 구조나 기타 불일치는 디바이스 또는 미디어 오류, 임박한 전원 손실과 실제 전원 손실 검출 사이의 부적절한 시간, 부적절한 시스템 셧다운 또는 미디어 제거, 매우 드문 경우 파일 시스템 코딩 오류에 의해 발생할 수 있습니다.

이러한 구조를 최적화하거나 복구하기 위해 파일 시스템에 특수 루틴이 포함되어 있습니다.일반적으로 사용자가 직접 호출하지 않고 파일 시스템 내에서 트리거됩니다.구조 수준 수, 삽입된 개체 수의 내부 카운터를 임계값과 비교할 수 있습니다.이로 인해 사용자 액세스가 특정 구조(보통 영향을 받는 사용자 또는 사용자의 불쾌감)로 일시 중단되거나 우선순위가 낮은 비동기 태스크로 시작되거나 사용자 액티비티가 낮은 시간으로 지연될 수 있습니다.이러한 루틴은 시스템 매니저에 의해 호출되거나 스케줄 되어 있는 경우가 있습니다.또, 조각 모음을 실시하는 경우도 있습니다.

커널 레벨 API

커널이 파일 시스템 개발자를 위한 인터페이스를 제공할 뿐만 아니라 파일 시스템 코드가 상주하는 공간일 때 API는 "커널 수준"입니다.

커널이 파일 시스템 레이아웃을 처리하고 파일 시스템이 하드웨어에 직접 액세스하는 것과 달리 커널 자체가 파일 시스템 드라이버와 통신하기 위해 자체 기능을 사용한다는 점에서 이전 스키마와는 다릅니다.

가장 깨끗한 스킴은 아니지만 오래된 스킴을 가진 메이저 개서의 어려움을 해결합니다.

모듈러 커널에서는 파일 시스템을 임의의 커널 모듈(서드파티 모듈도 포함)로 추가할 수 있습니다.그러나 비모듈러 커널에서는 커널을 새로운 파일 시스템 코드로 재컴파일해야 합니다(그리고 클로즈드 소스 커널에서는 이것이 서드파티 파일 시스템을 불가능하게 만듭니다).

Unix 및 Linux와 같은 Unix 유사 시스템은 이 모듈러 방식을 사용했습니다.

MS-DOS(DOS 4.0 이후) 및 호환성이 있는 CD-ROM 및 네트워크 파일 시스템을 지원하기 위해 사용되는 이 방식에는 다양한 종류가 있습니다.오래된 스킴과 같이 커널에 코드를 추가하거나 커널 기반의 스킴과 같이 커널 패실리티를 사용하는 대신 모든 콜을 파일에 트랩하여 커널의 동등한 함수로 리다이렉트해야 하는지, 특정 파일 시스템 드라이버에 의해 처리되어야 하는지, 파일 시스템 드라이버가 디스크 내용에 "직접"해야 하는지 여부를 식별합니다.낮은 수준의 BIOS 기능을 사용합니다.

드라이버 기반 API

API는 커널이 퍼실리티를 제공하지만 파일 시스템 코드가 완전히 커널 외부에 있을 때 "드라이버 기반"입니다(모듈러 커널의 모듈로서도 마찬가지입니다.

파일 시스템 코드가 완전히 독립적이기 때문에 파일 시스템을 생성하여 클로즈드 소스 커널 및 온라인 파일 시스템 추가 또는 시스템으로부터의 삭제를 수행할 수 있습니다.

이 스킴의 예로는 Windows NT 및 OS/2 각각의 IFS가 있습니다.

혼합 커널 드라이버 기반 API

이 API에서 모든 파일 시스템은 커널 기반 API와 같이 커널에 있지만 OS에 의해 드라이버 기반인 다른 API에 의해 자동으로 트랩됩니다.

이 스킴은 Windows 3.1에서 32비트^{[citation needed]} 보호 모드로 FAT 파일 시스템 드라이버를 제공하기 위해 사용되었으며 커널(MSDOS)에서 DOS FAT 드라이버를 바이패스하는 캐시(VFAT)를 실행했습니다.Windows 9x 시리즈(95, 98 및 Me for VFAT)에서는 나중에 ISO9660 파일 시스템 드라이버(Joliet와 함께), 네트워크 공유 및 서드파티 파일 시스템 드라이버를 추가하고 원래 DOS API에 LFN API(IFS 드라이버는 이미 존재하는 DOS API를 대행 수신할 수 있을 뿐만 아니라 새로운 DOS API를 추가할 수도 있음)를 추가합니다.32비트 보호 모드 실행 파일).

그러나 이 API는 완전히 문서화되어 있지 않으며, 서드파티는 커널 기반의 API보다 더 나쁜 "make-it-by-yourself" 시나리오에 처해 있음을 알게 되었습니다.

사용자 공간 API

API는 파일 시스템이 커널 기능을 직접 사용하지 않고 높은 수준의 운영 체제 기능을 사용하여 디스크에 액세스하고 일련의 유틸리티가 파일 시스템에 액세스하기 위해 사용하는 라이브러리에서 기능을 제공할 때 사용자 공간에 있습니다.

이것은 디스크 이미지를 처리하는 데 유용합니다.

ANSI C와 마찬가지로 파일 시스템을 운영 체제 간에 이식할 수 있다는 장점이 있지만, 단점은 API가 이를 구현하는 각 애플리케이션에 고유하다는 것입니다.

이 스킴의 예로는 hfsutils와 adflib가^{[permanent dead link]} 있습니다.