ADFS

Advanced Disc Filing System(ADFS)은 아콘(Acorn) 컴퓨터 제품군 및 RISC OS 기반 후속 기기에서 사용하는 고유한 파일 시스템이다. 초…

ADFS
개발사휴고 타이슨, 닉 리브스 (아콘 컴퓨터)
정식 명칭Advanced Disc Filing System
도입1983년(43년 전)(1983) - 아콘 MOS
파티션 식별자Hugo 또는 Nick (디렉터리 헤더/푸터)
구조
디렉터리 내용계층적 고정 길이 테이블
파일 할당파일당 하나의 범위 및 여유 공간 범위 테이블(L), 내장 파일 ID가 포함된 비트맵(E)
불량 블록없음(L),[1] 비트맵에 표시(E)
제약사항
최대 볼륨 크기512 MB
최대 파일 크기512 MB
최대 파일 수디렉터리당 47개(L), 디렉터리당 77개(E)
최대 파일 이름 길이10자
파일 이름 내 허용 문자ASCII (아콘 MOS), ISO/IEC 8859-1 (RISC OS)
기능
날짜 사용 권한수정
날짜 범위1900년 1월 1일 - 2248년 6월 3일
날짜 정밀도10 ms
포크없음
특성로드 주소, 실행 주소 및 파일 순환 번호 (아콘 MOS); 파일 형식 및 수정 시간 (RISC OS); 사용자 읽기/쓰기/실행 전용; 공개 읽기/쓰기/실행 전용; 삭제 잠금
파일 시스템 권한없음
투명한 압축없음
투명한 암호화없음
데이터 중복 제거없음
기타
지원 운영 체제아콘 MOS, RISC OS

Advanced Disc Filing System(ADFS)은 아콘(Acorn) 컴퓨터 제품군 및 RISC OS 기반 후속 기기에서 사용하는 고유한 파일 시스템이다. 초기에는 희귀한 아콘 윈체스터 파일링 시스템(Acorn Winchester Filing System)을 기반으로 했으나, 플로피 디스크 지원이 추가되면서(WD1770 플로피 디스크 컨트롤러 사용) ADFS로 명칭이 변경되었으며, 이후 32비트 시스템에서는 PC 스타일 플로피 컨트롤러의 변형을 사용했다.[2]

아콘의 원래 디스크 파일링 시스템은 디스크 면당 31개의 파일, 파일 이름당 7자, 디렉터리 이름당 1자로 제한되었으며, 이는 이전의 아톰(Atom) 및 시스템 3~5 유로카드 컴퓨터에서 계승된 형식이었다. 이러한 제약 중 일부를 극복하기 위해 아콘은 ADFS를 개발했다. 가장 극적인 변화는 계층적 디렉터리 구조의 도입이었다. 파일 이름 길이는 7자에서 10자로 늘어났고, 디렉터리 내 파일 수는 47개로 확장되었다. ADFS는 DFS의 일부 표면적인 속성을 유지했는데, 디렉터리 구분 기호는 계속 마침표(.)를 사용했고, $는 파일 시스템의 계층적 루트를 나타내게 되었다. ^는 상위 디렉터리를, @는 현재 디렉터리를, \는 이전에 방문한 디렉터리를 참조하는 데 사용되었다.

BBC 마스터 컴팩트(BBC Master Compact)에는 ADFS 버전 2.0이 포함되어 있었는데, 이는 ROM 내에 포맷, 검증 및 백업 명령을 추가했으나 하드 디스크에 대한 지원은 생략했다.[3]

8비트 사용

8비트 시스템에서 ADFS를 사용하려면 WD1770 또는 이후의 1772 시리즈 플로피 컨트롤러가 필요했는데, 이는 기존 인텔 8271 칩이 ADFS에 필요한 이중 밀도(double-density) 형식을 처리할 수 없었기 때문이다. 그러나 ADFS는 1770 컨트롤러 없이도 하드 디스크를 지원하는 데 사용할 수 있었다. 개발 과정에서 하드 디스크 사용이 주된 목표였으며, 플로피 디스크 처리를 위한 확장은 나중에 이루어졌다. 1770 플로피 컨트롤러는 마스터 시리즈 및 B+ 모델의 설계에 직접 통합되었으며,[4] 이전의 모델 B를 위한 업그레이드 보드로도 제공되었다.[5][6] ADFS는 추가 업그레이드를 통해 모델 B 및 B+ 시스템에 추가할 수 있었다.[7]

아콘 일렉트론(Acorn Electron)의 공식 디스크 확장인 아콘 플러스 3은 기본적으로 ADFS와 함께 제공되었으나, 이 구현에는 몇 가지 눈에 띄는 버그가 있었다. ZYSYSHELP라는 파일이 "시스템에 필요"하며 포맷 중에 생성되었다.[8]: 7  이는 임시 방편(kludge)이었다. 아콘의 초기 일렉트론용 ADFS 구현은 플로피 디스크의 처음 몇 트랙에 쓸 때 불안정했기 때문에, 이를 "수정"하기 위해 문제가 되는 부분에 쓰레기 데이터로 가득 찬 파일을 쓰는 방식을 사용했다. 그러면 ADFS는 해당 부분을 건너뛰었다. 깜빡이는 텍스트 커서를 비활성화하지 않고 *COMPACT 명령을 사용하려고 할 때도 디스크 손상이 발생할 수 있었다.[9][note 1] ADFS의 주요 개발자인 휴고 타이슨은 이 버그가 후기 테스트 과정에서 발견되었으나, 늦은 변경을 피하고 대체 방안이 존재했기 때문에 초기 ROM 릴리스에서는 수정되지 않았다고 회상한다.

일렉트론에서 디스크 포맷은 기존 DFS 명령인 *FORM40/*FORM80 대신 *EFORM 명령을 통해 수행되었다. 또한 *EFORM 명령은 BBC 마이크로컴퓨터용 1770 ADFS의 동등한 *AFORM 명령과 다르다는 점에 유의해야 한다. 이는 일렉트론에서 ZYSYSHELP 파일을 생성해야 할 필요성 때문에 발생했을 가능성이 크다. *EFORM 명령은 플러스 3과 함께 제공된 웰컴 디스크(Welcome disc)에만 포함되어 있었고 ROM에는 포함되지 않았다.[8]: 48 

ADFS는 하드 디스크와 이중 밀도 MFM 인코딩(L 형식; S 형식(160KB) 및 M 형식(320KB)으로 단면 디스크 지원)을 사용하여 최대 640KB 용량으로 포맷된 5¼인치 및 3½인치 플로피 디스크를 지원했다. BBC 마이크로컴퓨터 시스템(및 이후의 RISC OS)에 구현된 ADFS는 단일 밀도 플로피를 지원한 적이 없다.

ADFS의 하드 디스크 지원은 256바이트 블록 측면에서 L 형식 플로피와 동일한 형식을 사용했다.[10] 실제 사용되는 드라이브에 따라 트랙과 섹터의 기본 배열만 달랐으며, 이는 SCSI 컨트롤러에 의해 관리되었다. 이는 BBC 마이크로의 1MHz 버스, 아콘이 설계한 인터페이스 카드(1MHz 버스-SCSI 어댑터), 그리고 시중에서 판매되는 아답텍 SCSI 컨트롤러(SCSI-ST-506 어댑터)를 통해 ST506/ST412 기반 윈체스터 유닛과 인터페이스되었다.

IDE/ATAPI 스타일 드라이브에 대한 지원은 최근 몇 년간 제3자에 의해 '비공식적으로' 추가되었다.[11]

ADFS 파일 형식은 ADFS의 작성자인 휴고 타이슨의 이름을 따서 디스크의 디렉터리 이름을 구분하기 위해 ASCII 바이트 Hugo를 사용했다.

32비트 사용 (아서 및 RISC OS)

32비트 시스템에서 WD 1770 또는 1772는 초기 기기에서 플로피 컨트롤러로 사용되었다. 이후 모델은 PC 스타일의 멀티 I/O 컨트롤러를 사용하여 ADFS를 약간 변경해야 했다. 'L' 형식에 대한 기존 지원 외에도 아서와 이후의 RISC OS는 BBC 마이크로의 한계를 극복한 향상된 형식을 제공했다.

아서는 이전의 47개와 달리 디렉터리당 77개의 항목을 가진 D 형식을 추가했으며, 하드 디스크에서도 사용할 수 있고 새로운 800KB 이중 밀도 플로피 형식도 추가되었다. 파일당 "형식(type)" 속성이 로드 및 실행 주소를 저장하는 데 사용되던 공간에 추가되었다. 12비트의 형식 정보는 파일의 내용이나 의도된 용도를 나타내는 데 사용되며, 일반적으로 3개의 십육진법 숫자로 표시된다. 이는 애플의 HFS 파일 시스템에 저장된 32비트 형식 속성과 유사하며, 개념적으로는 Be 운영체제(BeOS)에서 사용하는 MIME 타입이나 유닉스 시스템의 매직 넘버(단, 후자는 메타데이터가 아닌 파일의 일부로 저장됨)와 비슷하다.

RISC OS는 각각 이중 밀도 디스크와 고밀도 디스크/하드 디스크 드라이브를 위한 E 및 F 형식을 도입했다. 이러한 형식은 파일 단편화(소위 "새 맵" 사용), 단편당 여러 파일 저장, 디렉터리 테이블 내 소규모 파일 저장을 지원한다. 할당 전략은 단편화를 최소화하도록 최적화되어 있으며, 때로는 파일 저장 작업의 일부로 조각 모음을 수행하기도 한다.[1] RISC OS 4는 긴 파일 이름과 디렉터리당 77개 이상의 파일을 허용하는 E+/F+ 형식을 추가했다. 이요닉스용을 포함한 RISC OS의 최신 버전은 계속해서 ADFS를 제공하며, 더 큰 하드 디스크 크기를 처리할 수 있도록 확장되었다.

8비트 구현과 달리 RISC OS에 구현된 ADFS는 단일 구조(monolithic)가 아니다. "ADFS"라는 시스템 모듈은 블록 드라이버와 사용자 인터페이스만 제공하며, "FileCore" 모듈은 실제 파일 시스템 구현을 포함하고, FileSwitch는 가상 파일 시스템 및 고수준 파일 액세스 API 구현을 포함한다. 이를 통해 IDEFS(IDE 애드온 카드용), SCSIFS, 네트워크 인식 AppFS와 같은 다른 하드웨어도 ADFS 형식을 쉽게 사용할 수 있다. FileCore 및 FileSwitch의 기능은 윈도우 NT의 IFS 및 IO 시스템 관리자와 어느 정도 유사하다. 이러한 유연성 덕분에 RISC OS에 다른 파일 시스템을 비교적 쉽게 구현할 수 있었다.

타 플랫폼에서의 ADFS 지원

리눅스 커널은 E 형식 이후의 ADFS를 지원한다.

NetBSD는 NetBSD 1.4 버전부터 filecore 지원[12]을 포함하고 있다.

Omniflop(윈도우 2000 이상) 및 Libdsk 지원 도구는 내장 드라이브를 사용하여 PC 시스템에서 ADFS 플로피의 '물리적' 레이아웃을 읽을 수 있게 해준다. 그러나 논리적 구조는 구현되지 않은 상태로 남아 있다.

각주

  1. ↑ 가 나 Reeves, Nick (1990년 10월 26일). “E format design document”. 2013년 5월 24일에 확인함. 
  2. ↑ 《Advanced Disc Filing System: User Guide》 (PDF). Acorn Computers Limited. September 1985. 2016년 8월 1일에 확인함. 
  3. ↑ “Taking the lid off the Master Compact”. 《Acorn User》. October 1986. 17면. 2020년 9월 5일에 확인함. 
  4. ↑ Smith, Bruce (July 1985). “B+ Grading”. 《Acorn User》. 160–161면. 2020년 10월 18일에 확인함. 
  5. ↑ 《1770 Disc Interface》 (PDF). Acorn Computers Limited. 2021년 3월 6일에 확인함. 
  6. ↑ 《1770 Disc Interface Upgrade Kit Fitting Instructions》 (PDF). Acorn Computers Limited. August 1985. 2021년 3월 11일에 확인함. 
  7. ↑ 《ADFS upgrade》 (PDF). Acorn Computers Limited. 2021년 3월 6일에 확인함. 
  8. ↑ 가 나 《The Electron Plus 3 User Guide》 (PDF). Acorn Computers Limited. October 1984. 2021년 3월 6일에 확인함. 
  9. ↑ Waddilove, Roland (August 1988). “Improving on perfection”. 《Electron User》 5 (11). 9면. 2021년 1월 20일에 확인함. 
  10. ↑ “Acorn 8-Bit ADFS Filesystem Structure” (TXT). 《Mdfs.net》. 2016년 8월 1일에 확인함. 
  11. ↑ “BBC IDE Interface - MDFS::Info.Comp.BBC.IDE”. 《MDFS.net》. 2016년 8월 1일에 확인함. 
  12. ↑ “Changes and NetBSD News in 1998”. 《Netbsd.org》. 2016년 8월 1일에 확인함. 
  • Watford Electronics, "The Advanced Reference Manual for the BBC Master Series", 1988 (p. 169)
  • Acorn Computers Ltd, "The BBC Microcomputer System Master Series Reference Manual Part 1", Part No, 0443–001, Issue 1, March 1986 - (Pages (J.10-1 to J10-3)

내용주

  1. ↑ 이는 *COMPACT 명령이 작동 중 작업 공간으로 화면 메모리를(기본값) 사용했기 때문이며, 소프트웨어로 구현된 깜빡이는 커서가 해당 메모리 공간을 손상시켰다. 대안으로는 화면 모드 6에서 *COMPACT 40 20과 같이 화면 메모리가 아닌 작업 공간을 사용하도록 인수를 전달하는 방법이 있다. BBC 마이크로에서 깜빡이는 커서는 활성화된 경우 6845 CRTC와 아콘의 비디오 ULA에 의해 화면 메모리 변경 없이 디스플레이 출력 위에 겹쳐졌다. 아콘 일렉트론은 이러한 추가 하드웨어가 없었으며 커서를 깜빡이기 위해 소프트웨어적으로 화면 메모리를 변경해야 했다.

외부 링크

Content Disclaimer

Informasi ini disarikan dari Wikipedia dan disajikan kembali untuk tujuan edukasi. Konten tersedia di bawah lisensi CC BY-SA 3.0. Kami tidak bertanggung jawab atas ketidakakuratan data yang bersumber dari kontribusi publik tersebut.

  1. The information displayed on this website is sourced in part or in whole from Wikipedia and has been adapted for the purpose of restating it. We strive to provide accurate and relevant information, however:
  2. There is no guarantee of absolute accuracy. Wikipedia is an open, collaborative project that can be edited by anyone, so information is subject to change.
  3. It is not intended to constitute professional advice. The content displayed is for informational and educational purposes only. For important decisions (e.g., medical, legal, or financial), please consult a professional.
  4. Content copyright. Wikipedia is licensed under the Creative Commons Attribution-ShareAlike License (CC BY-SA). This means that content may be reused with appropriate attribution and shared under a similar license.
  5. Responsible use. Any risk arising from the use of information from this website is entirely the responsibility of the user.