파일-11

Files-11

Files-11은 Digital Equipment Corporation OpenVMS 운영 체제에서 사용되는 파일 시스템이며, 구식 RSX-11에서 사용되는 파일 시스템이기도 합니다.액세스 제어 목록, 레코드 지향 I/O, 원격 네트워크 액세스 및 파일 버전 관리를 지원하는 계층형 파일 시스템입니다.

파일-11은 TOPS-20 및 RSTS/E 등의 이전 Digital Equipment Corporation 운영 체제에서 사용된 파일 시스템과 유사하지만 훨씬 더 고급입니다.

역사

네이티브 OpenVMS 파일 시스템은 오래된 DEC 운영 체제의 후예로, 여러 면에서 유사하지만 둘 다 Dave Cutler에 의해 설계되었습니다.큰 차이는 디렉토리의 레이아웃입니다.이러한 파일 시스템은 일반적으로 사용자 계정당 하나의 디렉토리를 할당하는 것을 기반으로 하는 기본적인 비계층 디렉토리 구조를 제공합니다.RSTS/E에서 각 사용자 계정은 2개의 숫자로 표시되었습니다.[project,programmer]1개의 디렉토리가 관련지어져 있습니다.프로그램 실행 파일 및 OS 자체와 같은 특수 시스템 파일이 예약된 시스템 계정의 디렉토리에 저장되었습니다.

이는 제한된 영구 스토리지 용량을 보유한 PDP-11 시스템에 적합했지만, 훨씬 더 큰 하드 드라이브를 갖춘 VAX 시스템에서는 파일 스토리지의 보다 유연한 방법, 특히 계층형 디렉토리 레이아웃이 필요했습니다. 이는 ODS-2의 가장 주목할 만한 개선입니다.

개요

"Files-11"은 5개의 개별 파일 시스템을 총칭하는 말로, ODS(On-Disk Structure) 레벨 1~5로 알려져 있습니다.

ODS-1은 RSX-11 OS에서 사용되는 플랫 파일 시스템입니다.RSX 호환성을 위해 오래된 VMS 시스템에서 지원되지만 VMS 자체를 지원하는 데는 사용되지 않습니다.대부분 ODS-2 및 ODS-5로 대체되었습니다.

ODS-2는 표준 VMS 파일 시스템이며 시스템 디스크(운영 체제가 설치된 디스크)에서 가장 일반적인 파일 시스템입니다.

ODS 레벨의 명칭에서는 거의 언급되지 않지만, ODS-3 및 ODS-4는 각각 CD-ROM ISO 9660 및 High Sierra Format 파일시스템에서 Files-11을 지원합니다.

ODS-5는 Alpha 및 IA-64 플랫폼에서 사용할 수 있는 ODS-2의 확장 버전으로 ASC 이외의 파일명에 대한 지원을 추가합니다.II 문자 및 계층형 디렉토리 지원 기능 향상.원래는 NT 어피니티 프로젝트의 일부로서 Microsoft Windows 또는 기타 비 VMS 시스템에 파일을 제공하는 것을 목적으로 하고 있었지만, 사용자 디스크 및 인터넷 서버에서도 사용됩니다.

디렉토리 레이아웃

일반적인 Files-11 디렉토리 계층: 모든 파일은 마스터 파일 디렉토리에 루트되며 File2는 2개의 디렉토리에 있습니다.

Files-11 파일시스템내의 모든 파일과 디렉토리는, 1개 이상의 부모 디렉토리내에 격납되어 최종적으로 루트 디렉토리아래에 마스터 파일 디렉토리(아래를 참조)가 됩니다.따라서 파일 시스템은 DAG(Directed Acyclic Graph) 구조로 구성됩니다.

이 예(오른쪽 참조)에서는, 및 양쪽 모두의 디렉토리 아래에 디렉토리 엔트리가 있습니다.두 개의 디렉토리는 동시에 「내」가 됩니다.1 개의 디렉토리에서 삭제되어도, 그 디렉토리에서도 삭제될 때까지 다른 디렉토리에 남아 있습니다.이는 UNIX의 하드링크 개념과 비슷하지만 하드링크용으로 설정되어 있지 않은 디스크에서는 파일이 실제로 삭제되지 않도록 주의해야 합니다(ODS-5 디스크에서만 사용 가능하며 디스크에 하드링크가 활성화되어 있는 경우에만 사용 가능).

디스크 구성 및 명명

운영 중인 VMS 시스템은 하나 이상의 온라인 디스크에 액세스할 수 있으며, 각 디스크에는 완전한 독립 파일 시스템이 포함되어 있습니다.로컬 스토리지 또는 클러스터의 경우 원격 시스템과 공유되는 스토리지 중 하나입니다.

그림 1: OpenVMS 클러스터 디스크 구성 예시

OpenVMS 클러스터 구성에서는 프라이빗 디스크가 아닌 디스크는 클러스터의 모든 노드 간에 공유됩니다(그림 1 참조).이 구성에서는 네트워크를 통해 두 개의 시스템 디스크에 모두 액세스할 수 있지만 개인 디스크는 공유되지 않습니다. 이 디스크는 특정 사용자 또는 프로세스에서만 사용할 수 있도록 마운트됩니다.클러스터 전체의 파일에 대한 액세스는 파일 시스템의 필수적인 부분인 OpenVMS Distributed Lock Manager에 의해 관리됩니다.

여러 개의 디스크를 결합하여 하나의 큰 논리 디스크 또는 볼륨 세트를 구성할 수 있습니다.또한 데이터 보안 또는 빠른 읽기 성능을 위해 Disk를 섀도 세트로 자동 복제할 수 있습니다.

디스크는 물리명 또는 사용자 정의 논리명으로 식별됩니다.예를 들어, 부트 디바이스(시스템디스크)에는 물리명이 붙어 있을 수 있지만, 일반적으로는 논리명으로 불립니다.

각 디스크의 파일시스템(ODS-1 제외)은 계층적입니다.완전히 지정된 파일명은 노드 이름, 사용자 이름과 비밀번호, 디바이스 이름, 디렉토리, 파일 이름, 파일 형식 및 버전 번호로 구성됩니다.

NODE "accountname password" : : device : [ directory . subdirectory ]파일명.타입;버전

예를 들어,는 디렉토리의 현재 기본 디스크에 있는 최신 버전을 참조합니다.

DIR1 는 마스터 파일 디렉토리(MFD) 또는 루트 디렉토리의 서브 디렉토리이며,의 서브 디렉토리입니다.디스크의 MFD는 에 의해 식별됩니다.

파일명의 대부분은 생략할 수 있습니다.이 경우 현재 기본 파일 지정에서 가져옵니다.기본 파일 사양은 노드, 디바이스 이름 및 디렉토리에 대한 기본 세트를 제공함으로써 다른 운영 체제의 "현재 디렉토리" 개념을 대체합니다.모든 프로세스에는 디스크 이름과 디렉토리를 포함하는 기본 파일 지정이 있으며 대부분의 VMS 파일시스템 루틴에서는 파일 형식도 포함할 수 있는 기본 파일 지정이 허용됩니다. 예를 들어 명령어는 파일 형식으로서 " .LIS로 기본값이므로 확장자를 지정하지 않고 명령어는 파일을 열려고 시도합니다.

모든 파일에는 버전 번호가 있습니다.같은 파일명의 다른 버전이 존재하지 않으면 디폴트는 1이 됩니다(그렇지 않으면 가장 큰 버전보다 높은 버전이 1이 됩니다).파일이 저장될 때마다 기존 버전을 덮어쓰지 않고 이름이 같지만 버전 번호가 증분된 새 파일이 생성됩니다.이전 버전은 또는 명령어를 사용하여 명시적으로 삭제할 수 있습니다.또는 옵션으로 파일의 버전 제한에 도달하면 오래된 버전을 자동으로 삭제할 수 있습니다(에 따라 설정).따라서 이전 버전은 덮어쓰지 않고 디스크에 보관되며 언제든지 검색할 수 있습니다.버전 번호의 아키텍처 제한은 32767입니다.불필요한 경우 버전 관리 동작은 쉽게 덮어씁니다.특히 데이터베이스와 같이 직접 업데이트되는 파일은 명시적으로 프로그래밍되지 않는 한 새 버전을 만들지 않습니다.

ODS-2는 최대 39.39 문자(파일명은 39 문자, 내선번호는 39 문자)의 대문자 영숫자 이름(및 밑줄, 대시 및 달러 기호)으로 제한됩니다.ODS-5는 ISO Latin-1 및 Unicode 문자뿐만 아니라 소문자 및 기타 인쇄 가능한 ASCII 문자로 문자 세트를 확장하여 파일 이름의 최대 길이를 늘리고 하위 디렉토리를 무제한으로 허용합니다.ODS-2에서 허용되지 않는 문자를 사용하는 ODS-5 파일의 경로 이름을 구성할 때 하위 호환성을 유지하기 위해 특별한 "^" 구문이 사용됩니다. 예를 들어 ODS-5 디스크 상의 파일 file.tar.gz;1""은 file^.tar.gz"- 파일 이름"file.tar이고 확장자는 .gz""입니다.

파일 보안: 보호 및 ACL

VMS 파일보안은 UIC 기반 접근컨트롤과 ACL 기반 접근컨트롤의 2가지 메커니즘으로 정의됩니다.UIC 액세스컨트롤은 파일 소유자와 UIC 또는 사용자가 파일에 액세스하는 것을 기반으로 합니다.액세스는 다음 4가지 권한 그룹에 의해 결정됩니다.

파일 보호 표시 형식. 권한이 부여되지 않음
  • 시스템.
  • 주인
  • 그룹.
  • 세계

그리고 4개의 허가 비트:

  • 읽어주세요
  • 기입하다
  • 실행
  • 삭제

"시스템" 액세스는 UIC 그룹 코드가 파라미터(일반적으로 8 또는 10 옥탈) 이하인 사용자(예를 들어 사용자)에게 적용됩니다. "owner" 및 "group"은 파일 소유자와 해당 사용자의 사용자 그룹에, "world"는 기타 모든 사용자에게 적용됩니다.또한 보호와 같은 파일 메타데이터 변경에 대한 액세스를 결정하는 데 사용되는 다섯 번째 권한 비트인 "Control"이 있습니다.이 그룹은 명시적으로 설정할 수 없습니다.항상 [시스템(System)]와 [소유자(Owner)]에 대해 설정되며 [그룹(Group)]또는 [월드(World)]에는 설정되지 않습니다.

UIC 기반의 접근컨트롤은 다음 4가지 시스템 특권의 영향을 받습니다.이 특권을 가진 사용자는 액세스컨트롤을 덮어쓸 수 있습니다.

  • : 사용자는 파일 보호에 관계없이 모든 파일에 대한 RWED 액세스를 암묵적으로 가집니다BYPASS.
  • READALL: 사용자는 암묵적으로 모든 파일에 대한 R 액세스 권한을 가집니다.
  • SYSPRV: 사용자는 시스템 보호를 기반으로 파일에 액세스할 수 있습니다.
  • : 사용자는 UIC 그룹이 파일 그룹과 일치하는 경우 시스템 보호에 따라 파일에 액세스할 수 있습니다GRPPRV.

ACL을 사용하면 사용자별 또는 그룹별로 추가 권한을 할당할 수 있습니다.예를 들어 웹 서버의 UIC는 특정 디렉토리에 있는 모든 파일에 대한 읽기 액세스 권한을 부여할 수 있습니다.ACL은 상속된 것으로 표시될 수 있으며, 여기서 디렉토리 파일의 ACL은 그 아래의 모든 파일에 적용됩니다.ACL은 명령어를 사용하여 변경되며 ID/액세스 쌍의 형식을 취합니다.예를 들어 ACL 엔트리가

(식별자=HTTP$SERVER,ACCESS=READ+EXECUTE)

사용자가 파일을 읽고 실행할 수 있도록 합니다.

논리명

논리적 이름은 디스크, 디렉터리 또는 파일을 참조하거나 다른 프로그램별 정보를 포함할 수 있는 시스템 변수입니다.예를 들어 논리에는 시스템의 부팅 디바이스가 포함됩니다.논리명은, 통상은 단일의 디렉토리 또는 디스크를 참조합니다.예를 들어, 유저의 로그인(홈) 디렉토리(또는 디렉토리)입니다.이러한 논리명은,SYS$LOGIN:[DIR]FILE 실제의 디스크명으로 사용할 수 없습니다.는 유효한 파일 사양이 아닙니다.단, 에 의해 정의된 은닉된 논리명은 이러한 방법으로 사용할 수 있습니다.이러한 루트 디렉토리는 디렉토리 사양에서 후행 "."로 정의됩니다.

$DEFINE/TRANS=HOME DISK$USER:[사용자명]

사용할 수 있습니다.보다 일반적인 것은, 디스크 또는 임의의 디렉토리에 있는 애플리케이션 소프트웨어에 관련 붙여진 특정의 디렉토리를 가리키는 단순한 논리입니다.따라서 논리적인 ABC_EXE는 어플리케이션 ABC 및 ABC_용 실행 가능 프로그램의 디렉토리를 가리킬 수 있습니다.TEMP 는, 같은 애플리케이션의 일시 파일의 디렉토리를 가리킬 수 있습니다.이 디렉토리는 ABC_EXE 와 같은 디스크 및 같은 디렉토리 트리에 있는 경우도 있고, 다른 디스크(및 다른 디렉토리 트리)에 있는 경우도 있습니다.

Unix와 같은 방법으로 VMS는 논리명 , 및 [1]를 통해 액세스되는 몇 가지 표준 입력 및 출력 채널을 정의합니다.

POSIX operating system에서는 논리명은 거의 동일하지 않습니다.명령 셸이나 응용 프로그램 대신 파일 시스템에 의해 확장된다는 점을 제외하면 Unix 환경 변수와 유사합니다.이러한 논리명은 사용하기 전에 정의해야 합니다.따라서 시스템스타트업 명령어파일 및 사용자 로그인 명령어파일에 많은 논리명이 정의되는 것이 일반적입니다.VMS에서 논리명은 다른 논리명을 참조할 수 있습니다(사전 정의된 네스트 제한 최대 10).또, 기존의 파일명을 검색하는 이름의 리스트를 포함할 수도 있습니다.자주 참조되는 논리명은 다음과 같습니다.

논리명 의미.
SYS$INPUT 표준 입력 - 인터랙티브하게 사용되며 터미널 키보드를 나타냅니다.배치 파일에서 사용되는 이 파일은 $ 기호가 선행되지 않은 배치 파일 행을 읽거나 다음 명령어를 사용하여 입력 데크로 지정되지 않은 배치 파일 행을 읽습니다.DECK명령어를 입력합니다.
SYS$OUTPUT 표준 출력 - 프로세스가 대화형인지 여부에 따라 터미널 디스플레이 또는 배치 로그 파일로 출력됩니다.
SYS$ERROR 표준 오류 - 프로세스가 대화형인지 여부에 따라 터미널 디스플레이 또는 배치 오류 로그 파일에 출력됩니다.
SYS$COMMAND batch file 명령어 소스.프로세스가 인터랙티브한지 여부에 따라 단말기 또는 SYS$INPUT 스트림에서 읽힙니다.
TT 프로세스와 관련된 단말
SYS$PRINT 기본 프린터 또는 인쇄 대기열
SYS$LOGIN 각 사용자의 홈 디렉토리
SYS$SCRATCH 임시 폴더, 임시 파일용 디렉터리
SYS$SYSTEM 대부분의 시스템 프로그램과 시스템 인증 파일(예: 파일 및 비밀번호)과 같은 몇 가지 중요한 데이터 파일을 포함하는 디렉토리
SYS$SHARE 공유 런타임 라이브러리, 실행 파일 등
SYS$LIBRARY 시스템 및 추가 라이브러리

논리명의 개념을 지원하는 가장 가까운 비 DEC 운영체제는 AmigaOS입니다.명령어를 사용합니다.AmigaOS의 디스크 운영 체제인 AmigaTRIPOS 포트인 DOS는 DEC 운영체제와 다소 유사합니다.예를 들어 물리적 디바이스 이름은 첫 번째 플로피 디스크의 경우 DF0:, 세 번째 CD-ROM 드라이브의 경우 CDROM2:와 같은 패턴을 따릅니다.다만, 시스템은 접속되어 있는 드라이브로부터 기동할 수 있기 때문에, operating system은 자동적으로 사용되는 기동 디바이스를 참조하기 위한 SYS: 할당을 작성합니다.LIBS:, PREFS:, C:, S: 등의 다른 할당도 이루어지며, 그 자체가 SYS:에서 참조됩니다.물론 사용자는 자신의 할당도 작성 및 파기할 수 있습니다.

레코드 지향 I/O: 레코드 관리 서비스

레코드 관리 서비스는 VMS 운영 체제의 구조화된 I/O 계층입니다.RMS는 레코드 기반 및 인덱스 데이터베이스 파일과 같은 구조화된 파일을 관리하기 위한 포괄적인 프로그램을 지원합니다.VMS 파일 시스템은 RMS와 함께 단순한 바이트 스트림을 통해 파일 액세스를 확장하여 다양한 리치 파일 유형을 OS 수준에서 지원할 수 있습니다.VMS 파일시스템 내의 각 파일은 일련의 레코드를 포함하는 데이터베이스로 생각할 수 있습니다.이러한 레코드는 각각1개 이상의 개별 필드를 가집니다.예를 들어 텍스트 파일은 줄 바꿈 문자로 구분된 레코드(행) 목록입니다.RMS는 레코드 지향 파일 시스템의 예입니다.

RMS에는 다음 4가지 레코드 형식이 정의되어 있습니다.

  • 고정 길이 - 파일의 모든 레코드의 길이가 동일합니다.
  • 가변 길이 - 레코드의 길이는 다양하며, 모든 레코드 앞에는 길이를 나타내는 카운트 바이트가 붙습니다.
  • 고정 길이 컨트롤이 있는 가변 레코드 길이 - 레코드의 길이는 다르지만 고정 길이 컨트롤 블록 앞에 있습니다.
  • 스트림 - 레코드는 길이가 다르며 모든 레코드는 다음 레코드와 종료 문자로 구분됩니다.텍스트 파일은 별도의 레코드로 줄 바꿈 또는 캐리지 리턴을 사용하는 스트림 형식 파일의 예입니다.

파일로부터 기존의 레코드를 취득하는 방법에는, 다음의 4개의 레코드 액세스 방법이 있습니다.

  • 시퀀셜 액세스 - 특정 레코드부터 시작하여 파일이 끝날 때까지 후속 레코드가 순서대로 검색됩니다.
  • Relative Record Number Access - 레코드는 파일의 선두에 상대적인 레코드 번호를 통해 취득됩니다.
  • Record File Address Access - 레코드는 파일 내 위치(RFA 또는 Record File Address)에 의해 직접 검색됩니다.
  • 색인화된 액세스 - 레코드를 키와 값 매핑 형식으로 키를 통해 검색합니다.

물리 레이아웃: 온디스크 구조

디스크 레벨에서 ODS는 파일 시스템을 블록 배열로 나타냅니다.블록은 1개의 물리 디스크(볼륨)에서 512바이트 연속됩니다.디스크 블록은 클러스터로 할당됩니다(원래는 3개의 연속된 블록이었지만 나중에 디스크 크기가 커질수록 증가).디스크상의 파일은, 이상적으로는 완전하게 연속해 있습니다.즉, 파일을 포함한 블록은 차례차례가 됩니다만, 디스크 플래그멘테이션에서는, 파일을 불연속 클러스터에 배치할 필요가 있는 경우가 있습니다.이 경우, fragment를 「익텐트」라고 부릅니다.디스크는 다른 디스크와 결합하여 볼륨 세트 및 파일을 형성할 수 있지만 디스크 크기가 커지면 단일 물리 디스크 관리가 간단해지기 때문에 볼륨 세트 사용이 감소합니다.

Files-11 디스크(또는 볼륨 세트) 상의 모든 파일에는 고유 파일 식별(FID)이 있으며 파일 번호(NUM), 파일 시퀀스 번호(SEQ) 및 상대 볼륨 번호(RVN)의 3개의 숫자로 구성됩니다.NUM은 파일 내의 메타데이터가 있는 위치(아래 참조)를 나타냅니다.SEQ는 파일이 삭제되고 동일한 INDEXF를 사용하여 다른 파일이 생성될 때 증가하는 세대 번호입니다.SYS 엔트리(오래된 파일에 대한 당글링 참조가 실수로 새 파일을 가리키지 않음) 및 RVN은 볼륨 세트를 사용할 때 파일이 저장되는 볼륨 번호를 나타냅니다.

디렉토리

ODS 볼륨의 구조적 지원은 디렉토리 파일(MVS의 VSAM 카탈로그와 유사하게 파일 이름, 파일 버전 번호 및 관련 FID 목록이 들어 있는 특수 파일)에 의해 제공됩니다.디렉토리 구조의 루트에는 볼륨상의 모든 파일이 (직접 또는 간접적으로) 격납되어 있는 루트 디렉토리인 마스터 파일 디렉토리(MFD)가 있습니다.

Files 11 directory structure.png
이 다이어그램은 3개의 파일이 포함된 디렉토리 예와 각 파일명이 엔트리에 매핑되는 방법을 보여 줍니다(각 INDEXF 엔트리에 더 많은 정보가 포함되어 있습니다.여기서는 처음 몇 개의 항목만 표시됩니다).

마스터 파일 디렉토리

ODS 파일시스템의 최상위 레벨에는 마스터 파일 디렉토리(MFD)가 있습니다.Master File Directory(MFD)에는 모든 최상위 디렉토리 파일(자체 포함)과 파일시스템 정보를 저장하는 데 사용되는 여러 시스템파일이 포함됩니다.ODS-1 볼륨에서는 2레벨의 디렉토리 구조가 사용됩니다.각 사용자 식별 코드(UIC)에는 형식의 관련 사용자 파일 디렉토리(UFD)가 있습니다.ODS-2 이후의 볼륨에서는, MFD 의 디렉토리 레이아웃은 자유 형식이며, ODS 상의 네스트 디렉토리의 제한은 8레벨 및 무제한입니다.다중 볼륨 세트의 경우 MFD는 항상 첫 번째 볼륨에 저장되며 모든 볼륨의 하위 디렉토리를 포함합니다.

ODS MFD에는 다음 시스템파일이 있습니다.

  • INDEXF.SYS;1: 인덱스 파일
  • BITMAP.SYS;1: 스토리지 비트맵파일
  • BADBLK.SYS;1: 불량 블록파일
  • 000000.DIR;1: MFD 디렉토리 파일 자체
  • CORIMG.SYS;1: 코어 이미지 파일
  • : 볼륨 세트리스트 파일VOLSET.SYS;1(ODS-2/5 한정)
  • CONTIN.SYS;1: 계속 파일(ODS-2/5 한정)
  • : 백업 로그 파일BACKUP.SYS;1(ODS-2/5 한정)
  • : 부정한 블록 보류 중BADLOG.SYS;1(ODS-2/5 한정)
  • : 볼륨 보안 프로파일SECURITY.SYS;1(ODS-2/5 한정)
  • : 쿼터 파일QUOTA.SYS;1(옵션으로 ODS-2/5에서만 사용 가능)
  • : GUID Partitioning Table (GPT; GUID 파티션 테이블) (OpenVMS I64 EFI 부트 구조, OpenVMS Alpha에서는 옵션GPT.SYS;1)

파일 시스템 구현 자체는 이러한 파일을 이름으로 참조하는 것이 아니라 항상 동일한 값을 갖는 파일 ID로 참조합니다.따라서 INDEXF.SYS는 항상 NUM = 1 및 SEQ = 1인 파일입니다.

인덱스 파일: INDEXF.시스템

인덱스 파일에는 Files-11 볼륨세트에 대한 가장 기본적인 정보가 포함되어 있습니다.

INDEXF에는 두 개의 조직이 있습니다.기존 조직 및 GPT를 사용하는 디스크에서 사용되는 조직인 SYS.GUID Partition Table(GPT; GUID 파티션 테이블) 구조를 가진 SYS.

기존 조직에서는 블록1이 VMS 운영체제 로드에 사용되는 프라이머리 부트스트랩 이미지의 위치를 포함하는 부트블록입니다하드웨어 펌웨어가 읽을 수 있도록 디스크상의 논리 블록0에 항상 배치되어 있습니다.이 블록은 시스템이 아닌(부팅할 수 없는) 볼륨에도 항상 존재합니다.

부트 블록이 프라이머리 홈블록이 되면여기에는 볼륨 이름, 인덱스 파일의 나머지 부분을 구성하는 익스텐트의 위치, 볼륨 소유자의 UIC 및 볼륨 보호 정보가 포함됩니다.일반적으로 세컨더리 홈블록이라고 불리는 홈블록에는 몇 개의 추가 복사본이 있어 볼륨이 손실되거나 손상된 경우 볼륨을 복구할 수 있습니다.

GPT가 있는 디스크.SYS, GPTSYS에는 부트블록(MBR)과 동등한 것(마스터 부트 레코드(MBR))이 포함되어 있어 프라이머리 홈블록은 없습니다.GPT 기반 디스크에 존재하는 모든 홈 블록은 대체 홈 블록입니다.이러한 구조는 INDEXF에 포함되지 않는다.SYS 및 INDEXF 블록.SYS 파일은 미사용입니다.

인덱스 파일의 나머지 부분은 볼륨에 있는 파일에 할당된 익스텐트를 설명하는 파일 헤더와 소유자 UIC, ACL 및 보호 정보 등의 파일 메타데이터로 구성됩니다.각 파일은 1개 이상의 파일헤더로 기술됩니다.파일에 다수의 익스텐트가 있는 경우는, 1개 이상의 파일이 필요하게 됩니다.파일 헤더는 고정 길이 블록이지만 고정 길이 섹션과 가변 길이 섹션을 모두 포함합니다.

  • 헤더에는 NUM 및 SEQ, 보호(보안) 정보 및 파일헤더의 나머지 위치가 포함됩니다.
  • ident 섹션에는 계정 메타데이터(파일 이름, 작성 및 변경 시간, 마지막 백업 시간)가 포함됩니다.
  • 맵은 파일의 각 가상 블록에 매핑되는 물리적 디스크 블록(확장)을 설명합니다.
  • 액세스 컨트롤 리스트에는, 파일의 ACL 정보가 포함됩니다.
  • 예약된 영역은 파일 헤더 끝에 있는 공간으로 운영 체제에서 사용되지 않습니다.이는 고객 고유의 정보 또는 벤더 고유의 정보에 사용할 수 있습니다.
  • 헤더의 마지막 2바이트는 헤더의 유효성을 확인하기 위해 앞의 255 워드의 체크섬입니다.

가능하면 헤더의 맵섹션과 ACL섹션이 프라이머리 헤더에 완전히 포함됩니다.단, ACL이 너무 길거나 파일에 익스텐트가 너무 많이 포함되어 있는 경우 프라이머리 헤더에 저장하기에 충분한 공간이 없습니다.이 경우 오버플로우 정보를 저장하기 위해 확장 헤더가 할당됩니다.

Indexf layout.png
헤더의 레이아웃.

파일 헤더는 4개의 오프셋(,IDOFFSET 및 )으로 시작합니다.고정길이 헤더 뒤의 영역 크기(맵이나 ACL 영역 등)는 다를 수 있으므로 이러한 추가 영역을 찾기 위해서는 오프셋이 필요합니다.각 오프셋은 파일헤더의 선두에서 그 영역의 선두까지의 16비트 워드의 수입니다.

파일에 여러 헤더가 필요한 경우 확장 세그먼트 번호()SEGNUM는 INDEXF의 첫 번째 엔트리에서 0으로 시작하는 이 헤더의 시퀀스 번호를 포함합니다.시스템

STRUCLEV 에 파일 시스템의 현재 구조 수준(높은 바이트 단위)과 버전(낮은 바이트 단위)을 나타냅니다.ODS-2는 구조 수준2입니다버전 번호가 증가하면 이전 소프트웨어가 무시할 수 있는 하위 호환성이 있는 변경을 나타냅니다.구조 수준 자체의 변경은 호환되지 않습니다.

W_FID (및 파일, 시퀀스 및 상대 볼륨 번호의 3가지 값을 포함한다)에는 이 파일의 ID가 포함되어 있습니다.또한 (3개의 값으로 구성되어 있는) 다음 확장 헤더의 위치가 저장되어 있습니다.이 두 값에서 RVN은 "현재" 볼륨을 나타내기 위해 0으로 지정됩니다(0은 일반적으로 유효한 RVN이 아닙니다).

FILECHAR 에는 파일의 처리 또는 편성 방법에 영향을 주는 몇 가지 플래그가 포함되어 있습니다.

  • NOBACKUP 이 파일은 백업 실행 시 무시됩니다.
  • WRITEBACK 는 파일에 대한 캐시된(캐시된) 쓰기를 활성화합니다.
  • READCHECK 그럼 파일의 모든 읽기가 2회 실행되며 데이터 무결성을 확보하기 위해 비교됩니다.
  • WRITCHECK 모든 쓰기가 후속 읽기 및 비교에 의해 검증됩니다.
  • CONTIGB OS는 가능한 한 연속적인 방법으로 파일에 스토리지를 할당하려고 합니다.
  • LOCKED 파일이 액세스 해제된 경우 설정됩니다.설정되어 있는 경우는, 파일이 마지막 사용 후에 올바르게 닫히지 않고, 컨텐츠가 일관성이 없는 것을 나타냅니다.
  • CONTIG 는 파일이 디스크에 연속적으로 저장됨을 나타냅니다.즉, 각 가상 i)는 한k(\ k 동안 논리(물리) +(\i+에 매핑됩니다.
  • BADACL 파일에 비활성 액세스컨트롤 리스트가 있는 경우 설정됩니다.
  • SPOOL 파일이 인쇄 중에 사용되는 중간 파일과 같은 스풀 파일인 경우 설정됩니다.
  • DIRECTORY 파일이 디렉토리인 경우 설정됩니다.
  • BADBLOCK 파일에 불량 블록이 포함되어 있는 경우 설정됩니다.
  • MARKDEL 파일이 삭제 마크가 붙어 있지만 아직 사용 중인 경우 설정됩니다.마지막 사용자가 파일을 닫으면 삭제됩니다.
  • 설정된 경우 파일에서 사용하는 공간이 소유자의 저장소 할당량에서 사용되지 않습니다NOCHARGE.
  • ERASE 파일 삭제 시 파일 내용을 덮어씁니다.

ACCMODE 에 파일에 액세스하기 위해 프로세스가 실행되어야 하는 특권 수준을 나타냅니다.VMS는 사용자, 슈퍼바이저, exec 및 커널의 4가지 특권 수준을 정의합니다.각 액세스 유형(읽기, 쓰기, 실행 및 삭제)은 2비트 정수로 인코딩됩니다.

FILEPROT 에 파일의 임의 접근컨트롤 정보를 나타냅니다.시스템, 소유자, 그룹, 월드 등 4비트씩 4개의 그룹으로 나뉩니다.비트 0은 읽기 액세스, 1은 쓰기, 2는 실행, 3은 삭제에 해당합니다.비트를 설정하면 그룹에 대한 특정 액세스가 거부됩니다.비트를 클리어하면 그룹에 대한 접근이 허용됩니다.

파일 헤더가 확장 헤더인 경우 에는 프라이머리 헤더의 파일 ID가 포함되어 있습니다.확장 헤더에는 파일의 프라이머리 엔트리가 격납되어 있는 디렉토리 파일의 파일 ID가 포함됩니다.

기타 파일

  • 저장소 비트맵 파일:
비트맵 파일은 볼륨에서 사용된 공간과 사용 가능한 공간에 대한 정보를 저장하는 역할을 합니다.스토리지 컨트롤 블록(SCB)에는 스토리지 컨트롤 블록(SCB)이 포함되어 있습니다.SCB에는 개요 정보가 포함되어 있습니다.또, 디스크상의 블록 클러스터가 빈 상태인지 할당되어 있는지를 나타내는 비트맵도 포함되어 있습니다.VMS의 이전 버전에서는 클러스터가 3개의 블록으로 구성되었지만 디스크 크기가 증가함에 따라 클러스터 크기도 증가했습니다.
  • 잘못된 블록 파일:
불량 블록 파일에는 실제 볼륨에 있는 알려진 불량 블록이 모두 포함되어 있습니다.그 목적은 시스템이 파일을 할당하지 못하도록 하는 것입니다.이 파일은 디스크 제조 초기에 일반적으로 표면에 불량 패치가 더 많았던 경우에 더 많이 사용되었습니다.
  • 볼륨 세트 목록 파일:
볼륨 세트 목록은 볼륨 세트의 볼륨 1에 있으며 세트에 포함된 모든 볼륨의 레이블 목록과 세트의 볼륨 이름을 포함합니다.
  • 계속 파일:
다중 볼륨 세트의 파일이 두 구성 볼륨의 경계를 통과할 때 계속 파일이 확장 헤더로 사용되며 파일의 나머지 부분을 찾을 수 있는 볼륨을 나타냅니다.
  • 할당량 파일:
쿼터 파일에는 볼륨에서 각 UIC의 디스크 공간 사용량에 대한 정보가 포함되어 있습니다.각 UIC에 대한 레코드와 볼륨상의 영역이 할당되어 있습니다.또, 그 UIC가 사용하고 있는 스페이스의 양에 관한 정보도 포함되어 있습니다.주의: DISK QUATOR 기능은 옵션이며, 이 기능이 유효하게 되어 있는 경우에만 파일이 존재합니다.
  • 볼륨 보안 프로파일:
볼륨 보안 프로필에는 볼륨의 소유자 UIC, 볼륨 보호 마스크 및 액세스 제어 목록이 포함됩니다.
  • GUID 파티션 테이블:
이 파일은 Extensible Firmware Interface 준거 펌웨어에 의해 사용되는 MBR(마스터 부트 레코드) 및 GPT(GUID 파티션 테이블) 디스크 구조를 오버레이하여 보호합니다.이 파일은 OpenVMS I64 디스크 초기화 중에 기본적으로 생성되며 OpenVMS Alpha에서 선택적으로 INITIALIZE/GPT를 사용하여 생성됩니다.

「 」를 참조해 주세요.

  • 파일 시스템 비교
  • NTFS - Files-11과 구조 및 메타데이터의 많은 유사점을 가지고 있으며, 개념적으로 거의 확실하게 파생되었습니다.

레퍼런스

  1. ^ "OpenVMS User's Manual" (PDF). vmssoftware.com. VSI. July 2020. Chapter 14, Advanced Programming with DCL. Retrieved 2021-04-09.

추가 정보

  • Andrew C. Goldstein, VAX/VMS Software Development (1985-01-11). "Files-11 On-Disk Structure Specification". {{cite journal}}:Cite 저널 요구 사항 journal=(도움말)
  • Hewlett-Packard Development Company, L.P. (September 2003). "Appendix A: Files-11 Disk Structure". OpenVMS System Manager's Manual, Volume 2: Tuning, Monitoring, and Complex Systems.
  • Kirby McCoy (1990). VMS File System Internals. Bedford, Mass.: Digital Press. ISBN 1-55558-056-4.

외부 링크