hotchpotch/wikipedia-multilingual-ir-pairs huggingface dataset:
키예프 (카메라 브랜드) 키예프 중형 카메라
키예프 88과 키예프 88 TTL은 살류트 S와 동일한 카메라였지만 플래시의 동조 연결을 위한 핫 슈가 추가되었다. 이 카메라들은 기본으로 Volna-3 렌즈가 장착되었다. 이 두 모델의 차이점은 키예프 88 TTL에는 TTL 측광 오각프리즘이 있었고, 키예프 88에는 측광 기능이 없는 오각프리즘이 있었다는 점이다. 이 카메라들은 교체 가능한 뷰파인더와 프리즘을 가지고 있었기 때문에 실제 차이점은 카메라를 구매할 때 어떤 액세서리가 상자에 들어있었느냐는 것뿐이었고, 카메라는 동일했다.
이 카메라는 원래의 나사식 렌즈 마운트를 펜타콘 식스 마운트로 교체하여 렌즈 옵션을 확장했기 때문에 살류트 이후 가장 큰 업그레이드일 것이다.
이 카메라는 매우 희귀하다(약 2000대 생산). 이전 키예프가 6x6 형식을 사용한 것과 달리 이 카메라는 6x4.5 네거티브를 촬영한다. 조리개 우선 자동, 반자동 및 수동 촬영 모드를 제공하며, 교체 가능한 렌즈, 초점 스크린, 뷰파인더 및 필름 매거진을 사용한다. 펜타콘 식스 마운트를 사용하며 기본으로 Volna-3 렌즈가 장착되어 있다. 셔터 속도는 4초에서 1/1000초 + B까지이다.
키예프 (카메라 브랜드) 키예프 중형 카메라
키예프 중형 카메라의 다른 계열은 펜타콘 식스를 기반으로 하며 아마도 제니트 70에서 영감을 받았을 것이다. 이 카메라들은 확대된 35mm 필름 일안 반사식 카메라처럼 보인다. 펜타콘 식스와 동일한 렌즈 마운트를 사용하여 해당 시스템용으로 제작된 모든 렌즈를 사용할 수 있다. 여기에는 마이어 옵틱 괴를리츠, 자이스, 슈나이더 크로이츠나흐 (엑작타 66용), 킬피트 및 기타 아르세날 공장에서 만든 렌즈가 포함되지만 이에 국한되지 않는다. 이 카메라들은 펜타콘 식스보다 간단한 프레임 전진 메커니즘을 가지고 있지만, 공장에서 제대로 조정되지 않아 프레임 간격이 잘못되는 경우가 많다. 이 문제는 해결될 수 있다.
키예프 (카메라 브랜드) 키예프 중형 카메라
120 필름과 220 필름을 모두 사용할 수 있는 6x6 일안 반사식 카메라이며, 셔터 릴리즈 버튼은 카메라 왼쪽에 있으며 교체 가능한 뷰파인더와 1/2초에서 1/1000초 + B까지의 속도를 가진 수평 주행 포컬 플레인 셔터를 사용한다. 기본적으로 Vega-12 렌즈와 함께 제공되었다. 명판에 КИЕВ 대신 KIEV라고 쓰여진 수출 버전도 있으며, 렌즈도 Вега에서 Vega로 변경된다. 사용자가 카메라를 들여다보면서 사진을 구상할 수 있지만 이미지가 좌우 반전되는 단점이 있는 웨이스트 레벨 파인더 또는 노출계가 없는 오각프리즘 파인더 옵션과 함께 제공되었다.
원래 키예프 6S와 거의 동일한 카메라였지만, 전면 플레이트가 달랐다. 키예프 로고는 이제 검은색 배경에 크롬으로 쓰여 있다. 기본으로 CdS TTL 측광 오각프리즘을 제공했다.
키예프 (카메라 브랜드) 키예프 중형 카메라
현재의 키예프 60은 보다 전통적인 오른손잡이용 셔터 릴리즈를 가지고 있지만, 220 필름을 사용하지는 않는다. 그 외에는 키예프 6S와 기계적으로 유사한 카메라지만, 미러 락업으로 개조할 수 있는 유일한 펜타콘 식스 기반 모델이다. 6S와 비교하여 플래시 사용이 훨씬 쉬운데, 카메라 왼쪽에 핫 슈 어댑터를 나사로 조일 수 있는 나사산이 있어 6S처럼 플래시를 손에 들고 있을 필요가 없기 때문이다.
키예프 중형 카메라의 낮은 가격은 예산 내에서 중형 카메라 시장에 진입하려는 많은 아마추어 사진가들을 끌어들였다. 일부는 키예프 핫셀블라드 타입 카메라 설정에 렌즈, 뷰파인더, 필름 매거진과 같은 다른 러시아 또는 우크라이나 부품을 추가한 가격이 비슷한 핫셀블라드 설정 가격의 일부에 불과하다고 보고했다. 또한, 저렴한 가격에도 불구하고 키예프 렌즈는 광학적으로 우수하며, 많은 렌즈가 자이스 디자인을 기반으로 하고 있다.
키예프 (카메라 브랜드) 키예프 중형 카메라
이러한 이유로, 개선되고 좀 더 다듬은 키예프 카메라를 제공하는 여러 타사 유통업체가 나타났다. 그러나 일부는 아르세날 공장의 가변적인 품질을 이용하여 아르세날에서 공급한 카메라를 다양한 수준으로 재조립, 개조 및 테스트하여 부가가치를 창출하기도 했다.
그러나 이 카메라들에는 간단한 수리로는 제거되지 않는 여러 가지 특징이 여전히 존재한다. 가장 눈에 띄는 특징은 일부 오리지널 핫셀블라드와 같은 키예프 카메라의 셔터 속도는 셔터를 코킹(셔터 메커니즘을 스프링으로 장전하고 필름을 진행)한 후에만 변경해야 한다는 것이다. 코킹되지 않은 카메라에서 셔터 속도를 변경하면 타이밍 메커니즘이 손상될 수 있다. 이는 펜타콘 식스 기반 키예프에서는 문제가 되지 않는다. 셔터 속도 다이얼을 시계 방향으로만 돌려야 하고 반시계 방향으로는 돌리면 안 된다는 상반된 보고도 있다. 이는 하트블레이가 미러 락업(MLU) 기능을 추가하기 위해 개조한 일부 카메라에서 분명히 알려진 문제이다. 다른 카메라에서는 이 문제가 있을 수도 있고 없을 수도 있으므로 특별한 주의가 필요하다.
키예프 (카메라 브랜드) 키예프 중형 카메라
이전 소련 외 지역에서 키예프 카메라를 판매하는 업체들은 종종 공장에서 나오는 저렴하고 기본적인 카메라에 자체적인 개조를 가한다.
미러 락업은 이 카메라들에 추가할 수 있는 기능이다. 이는 셔터가 열리기 직전에 미러가 미러 박스 상단에 부딪혀 발생할 수 있는 소량의 움직임 흐림을 제거하지만, 다른 움직임 흐림의 원인은 여전히 남아있다. 이는 피사체가 크게 확대될 때(긴 렌즈 또는 망원 렌즈를 사용할 때) 또는 근접촬영시 가장 유용하다. 이 카메라들 중 일부는 미러 슬랩이 정말 강하여, 손에 들고 촬영하지 않을 때도 움직임 흐림을 유발하므로, 느린 셔터 속도를 사용하는 경향이 있다면 MLU는 정말 유용한 기능이다. 또 다른 수정은 미러 박스 측면에 플랫 스프링을 추가하는 것이다. 이는 미러가 반동하여 초기 충격 후 추가 진동을 일으키는 것을 방지하여 손에 들고 촬영할 때 느린 셔터 속도를 더 쉽게 사용할 수 있게 해준다.
키예프 (카메라 브랜드) 키예프 중형 카메라
펜타콘 식스 기반 키예프는 때때로 6x4.5 프레임 크기로 촬영하도록 개조되는데, 종종 키예프 645 등으로 불리며, 원래 카메라의 정사각형 6x6 형식에 비해 "인쇄 친화적인" 직사각형 형식으로 한 롤의 필름당 더 많은 사진을 얻을 수 있다. 그러나 필름이 옆으로 공급되기 때문에 6x4.5 변형은 다른 대부분의 카메라에서 볼 수 있는 풍경 측면과 달리 세로 측면으로 사진을 생성한다. 한편, 핫셀블라드 기반 키예프는 다른 필름 백을 사용하기만 하면 6x4.5 프레임 크기로 촬영할 수 있다. 6x4.5 필름 백은 다른 6x6 백, 예를 들어 즉석 필름 백과 교체할 수 있지만, 펜타콘 식스 기반 키예프 프레임 크기 수정은 영구적이다.
키예프 (카메라 브랜드) 키예프 중형 카메라
키예프 88CM의 원래 펜타콘 식스 마운트는 아르세날 공장의 모든 렌즈를 사용할 수 있지만, 펜타콘 식스용 자이스 조나와 같은 다른 렌즈들은 장착하기 어렵다. 그러나 키예프 88CM이 펜타콘 식스 마운트용으로 만들어진 모든 렌즈를 사용할 수 있도록 하는 타사 개조를 통해 이 문제를 극복할 수 있다. 핫셀블라드와 같은 나사 마운트를 사용하는 키예프 카메라는 더 많은 렌즈를 사용할 수 있기 때문에 더 바람직한 펜타콘 식스 마운트로 개조될 수 있다. 새로운 마운트의 레지스터 거리가 원래 마운트보다 짧기 때문에, 마운트는 카메라 본체 내부에 위치하며 어댑터와 함께 기존의 모든 나사 마운트 렌즈를 사용할 수 있게 한다. 이는 이미 나사 마운트 렌즈를 가지고 있지만 렌즈 옵션을 확장하기 위해 렌즈 마운트를 개조하려는 경우에 바람직하다. 이 경우, 다른 마운트와 동일한 렌즈를 모두 구입할 필요가 없다.
키예프 중형 카메라용 렌즈는 두 가지 다른 렌즈 마운트로 제공되었다. 마운트 B와 마운트 V(키릴 문자에서 В는 우리가 아는 V를, Б는 B를 나타낸다)로, 마운트 B는 펜타콘 식스 마운트 렌즈를 나타내고, V는 살류트 스크류 마운트를 나타낸다.
1990년대에는 렌즈들이 모두 Arsat으로 이름이 변경되어 서로 구별하기가 더 어려워졌지만, 광학적으로는 위에 나열된 렌즈 중 하나이다. 렌즈 이름이 변경될 때 마운트 지정도 변경되었다. 펜타콘 식스 마운트 렌즈는 Arsat C로 이름이 변경되었고, 스크류 마운트 렌즈는 문자 B를 유지했다.
가장 높이 평가되는 것 중 하나는 Zodiak-8 어안 렌즈이다. 이 렌즈는 기계적으로 매우 우수하고 광학적으로 탁월하다고 알려져 있으며, 이 유형의 우크라이나 이외의 렌즈를 얻으려면 수천 달러를 들여야 한다는 점을 고려하면 놀라운 일이다.
45mm 및 65mm 광학을 기반으로 한 타사에서 만든 시프트 및 틸트-시프트 렌즈도 사용할 수 있다. 이 렌즈를 통해 사진가는 조리개를 조정하지 않고도 겉보기 피사계 심도를 더 깊게 만들 수 있는 샤임플러그 원리를 활용하고, 뷰 카메라에서 볼 수 있는 것과 유사한 다른 제어 기능을 얻을 수 있다.
널리 알려지지는 않았지만, 키예프 6S는 "KIEV-C SKD"라는 이름으로 개조된 형태로 우주로 나갔으며, 일부 정보에 따르면 약 33세트가 생산되었다. 이 카메라는 존드 6호와 존드 7호 우주선에 사용되었는데, 존드 6호는 추락했지만 존드 7호는 지구와 달의 사진을 촬영하는 데 성공했다. 이 카메라는 일반 변형보다 훨씬 넓고 무거웠으며 전동 필름 와인딩 메커니즘을 가지고 있었고 원격 셔터 릴리즈도 함께 제공되었다. 셔터 속도는 동일하게 유지되었고, 이를 위해 제작된 3개의 렌즈는 일반 모델을 기반으로 했으며, 우주에서의 사용을 위해 다른 코팅과 사양으로 크게 수정되었다. 90/2.8 Vega 12B는 Vega 12-C로 변형되었고, f/2.8 및 f/4 변형이 있었으며, 일반적인 6개의 조리개 날개 대신 11개의 조리개 날개를 사용했다. 또한 특수한 노란색 코팅이 있었지만, 그 목적은 문서화되지 않았다. Tair-33은 Tair-33-S로 변형되어 5.6/300을 유지했으며, 일부 정보에 따르면 "무인 촬영"을 위한 버전도 있었는데, 이 렌즈는 초점 링이 없었다. 65/3.5 Mir-3도 Mir-3-S라는 우주 변형을 보았지만, 이에 대해 알려진 바는 많지 않다.
Fmt (유닉스)
유닉스, 플랜 9, 인페르노 및 유닉스 계열 운영체제의 fmt 명령어는 사람이 읽을 수 있도록 자연어 텍스트를 포맷한다.
Fmt (유닉스) 개요
이 명령어는 전자 메일 메시지를 작성한 후 전송하기 전에 다시 포맷하는 데 사용되었다. 구문은 다양한 유닉스 시스템에서 유사하지만 동일하지는 않다. fmt는 BSD 및 GNU 코어 유틸리티의 fold가 입력 줄을 정확히 래핑하는 것과는 달리, 전역적으로 최적화되고 균형 잡힌 출력을 생성하기 위해 입력 줄을 분리, 채우기 및 결합하여 각 줄의 길이가 목표 너비에 최대한 가깝도록 시도한다.
Fmt (유닉스) 개요
fmt의 대부분의 구현에서 단어 묶음 최적화 절차는 일반적으로 두 가지 기준을 요구한다: 목표 출력 줄 너비와 최대 허용 줄 너비 (최적화를 위한 여유 공간을 주기 위해 이전 것보다 커야 한다). 이 두 가지 옵션을 동시에 제공하는 것이 항상 가능하지 않을 수 있다. 예를 들어, GNU fmt의 초기 버전은 -w 스위치로 주어지거나 호환성을 위해 첫 번째 명령줄 옵션으로 직접 -digits로 최대 너비 옵션만 받을 수 있다 (이후 버전은 목표 너비를 지정하기 위해 -g를 사용하고 최대 너비를 위해 -w를 사용한다). 자세한 예시는 fmt의 솔라리스 맨 페이지와 FreeBSD 매뉴얼 항목을 참조하고, 대부분의 리눅스 배포판에 포함된 GNU fmt 유틸리티의 최신 문서와 비교하라. 플랜 9 fmt 맨 페이지도 참조하라.
par와 달리 fmt는 유니코드 지원이 없으며 텍스트 맞춤을 지원하지 않는다.
이 명령어는 일반적인 GNU 유닉스 계열 유틸리티의 네이티브 Win32 이식 모음인 UnxUtils의 일부로 마이크로소프트 윈도우용 별도 패키지로 제공된다.
Fmt (유닉스) 예시
각 줄의 너비는 최대 50자이며 텍스트는 이 제약 조건 내에서 흐른다.
Pax (명령어)
pax는 다양한 운영체제에서 사용할 수 있으며 1995년부터 정의된 아카이빙 유틸리티이다. tar와 cpio 사이에 발생한 호환되지 않는 옵션들과 다양한 유닉스 버전에서 이들의 구현을 정리하기보다는, IEEE는 두 아카이버의 유용한 옵션을 모두 지원할 수 있는 새로운 아카이브 유틸리티인 pax를 설계했다. pax 명령어는 유닉스 및 유닉스 계열 운영체제와 IBM i, 그리고 마이크로소프트 윈도우 NT에서 윈도우 2000까지 사용할 수 있다.
2001년에 IEEE는 기본적으로 확장 속성이 추가된 tar와 유사한 새로운 pax 형식을 정의했다. 이 형식은 대부분의 리눅스 배포판 및 FreeBSD의 pax 명령어에서는 지원되지 않지만, GNU 및 FreeBSD의 tar 명령어에서는 지원된다. 이 형식은 AIX, Solaris 및 HP-UX의 pax 명령어에서도 지원된다.
"pax"라는 이름은 portable archive exchange의 약어이지만, "평화"를 의미하는 라틴어 단어를 암시하기도 한다. 명령어 호출 및 구조는 tar와 cpio의 평화로운 통합을 나타낸다.
Pax (명령어) 역사
pax의 첫 공개 구현은 마크 H. 콜번(Mark H. Colburn)이 1989년에 작성했다. 콜번은 이를 comp.sources.unix에 유즈닉스/IEEE POSIX의 TAR 및 CPIO 대체 프로그램으로 게시했다. HP-UX, IRIX, SCO UNIX의 pax 매뉴얼 페이지는 pax를 콜번의 작품으로 언급한다.
1990년 7월의 POSIX.2 드래프트 10부터 pax 명령어를 다룬다. 또한 1991년 POSIX.2 및 IEEE 1003.1b 드래프트는 cpio 및 ustar 아카이브 형식을 특징으로 하는 pax 명령어를 다룬다.
또 다른 pax 프로그램 버전은 키스 뮐러(Keith Muller)가 1992~1993년에 만들었다. 이 버전은 4.4BSD (1995년)에 처음 등장했다. pax 명령어는 1995년 X/Open issue 4 (Single Unix Specification 버전 1)에 cpio 및 ustar 아카이브 형식을 특징으로 등장했으며 이 두 형식은 1997년 Single Unix Specification에서도 유일하게 다루어진 형식이었다.
Pax (명령어) 역사
1997년, 썬 마이크로시스템즈는 ustar 형식에 확장을 추가하는 방법을 제안했다. 이 방법은 새로운 pax 파일 형식으로 POSIX.1-2001 표준에 채택되었다. pax 유틸리티에 대한 POSIX 사양은 이 형식을 포함하도록 업데이트되었다.
Pax (명령어) 기능
pax는 -r ("읽기") 및 -w ("쓰기") 옵션의 조합으로 호출되는 네 가지 일반 모드를 가지고 있다.
이 표는 모달 동작을 요약한다:
이 모델은 유사한 기본 작업 세트를 가진 cpio와 유사하다.
아카이브 내용 나열:
아카이브 내용을 현재 디렉터리로 추출:
현재 디렉터리의 아카이브 생성:
현재 디렉터리 트리를 다른 위치로 복사:
대상 디렉터리는 미리 존재해야 한다.
기본적으로 pax는 아카이브 및 목록 작업에 표준 입출력을 사용한다. 이는 아카이브 파일을 지정하는 "tar 스타일" 옵션 -f로 변경할 수 있다. Pax는 디렉터리 내용을 재귀적으로 고려한다는 점에서 cpio와 다르다. 이 동작을 비활성화하려면 POSIX pax에는 이를 비활성화하는 옵션 -d가 있다.
Pax (명령어) 기능
pax 명령어는 cpio와 tar 기능의 혼합이다. tar와 마찬가지로 pax는 디렉터리 항목을 재귀적으로 처리하는데, 이 기능은 cpio 스타일 동작을 위해 -d로 비활성화할 수 있다. 파일 입출력 처리도 혼합되어 있다. 명령줄에 파일 이름 목록이 지정되면 파일 입력 또는 목록 작성(tar와 유사)을 위한 셸 글로브로 간주된다. 그렇지 않으면 pax는 파일 목록에 표준 입력을 사용하는 cpio 스타일 동작을 취한다. 마지막으로 pax는 tar의 -f FILE 옵션을 사용하여 명명된 아카이브 파일에 읽기/쓰기를 지원한다.
예를 들어, 현재 디렉터리를 cpio 스타일로 아카이빙하려면, cpio를 사용하는 것처럼 find와 함께 pax를 사용할 수 있다.
(find에 필터가 없으면 위 예시와 동일해지므로 이 구성은 의미가 없다.)
아카이브에서 내용을 추출하는 명령어는 cpio와 동일하다.
이러한 명령어는 tar와 유사한 구문으로도 호출할 수 있다.
Pax (명령어) 기능
대부분의 pax 구현은 압축을 위해 -z (Gzip) 및 -j (Bzip2) 스위치를 사용한다. 그러나 이 기능은 POSIX에서 지정되지 않았다. pax는 압축된 아카이브에 추가할 수 없다는 점을 유의해야 한다.
gzip으로 압축된 아카이브를 추출하는 예시:
tar 및 cpio와 마찬가지로 pax 출력은 다른 압축/압축 해제 프로그램으로 파이프될 수 있다. 여기에 xz가 사용된 예시:
xz로 압축된 아카이브를 입력으로 나열하는 예시:
POSIX.1-2001은 pax 명령어가 최소한 cpio, ustar 및 pax 아카이브 형식을 지원해야 한다고 요구한다.
4.4BSD 구현에서 파생된 pax 명령어 버전은 일반적으로 -x 옵션을 통해 선택 가능한 해당 버전에서 지원하는 형식을 상속한다.
POSIX.1-2001 pax 형식은 이 BSD 버전의 pax 명령어에서 지원되지 않는다. 이 형식은 대부분의 리눅스 배포판(pax 명령어가 MirCPIO-paxmirabilis의 MirBSD 브랜치에서 파생됨) 및 FreeBSD에서는 지원되지 않는다. 이 형식은 AIX, Solaris 및 HP-UX의 pax 명령어에서 지원된다. 또한 Python tarfile 모듈, BSD 라이선스가 적용된 libarchive, 7-ZIP 및 GNU tar와 FreeBSD tar에서도 지원된다. 2003년 군나르 리터(Gunnar Ritter)가 개발한 Heirloom Project pax 명령어는 pax 형식뿐만 아니라 많은 추가 형식도 지원한다.
pax는 다중 볼륨 아카이빙을 지원한다. 볼륨의 끝에 도달하면 다음 메시지가 나타난다.
다중 미디어에서 아카이브를 복원할 때, 아카이브의 끝에 도달하기 전에 미디어의 끝에 도달하면 pax는 동일한 방식으로 다음 미디어를 요청한다.
Pax (명령어) 표준화, 수용 및 인기도
2001년에 IEEE에 의해 표준화되었음에도 불구하고, 2010년 기준으로 pax는 비교적 인기가 적거나 채택률이 낮다. 이는 부분적으로 유닉스 사용자들로부터 이에 대한 필요성이 없었기 때문이며, 단지 POSIX 위원회가 더 일관된 인터페이스를 원했을 뿐이다. Pax는 또한 상당히 수다스럽고 문제가 발생하면 사용자 상호 작용을 기대한다.
pax는 2005년 7월 6일에 출시된 버전 3.0부터 리눅스 기본 규격에 의해 모든 준수 시스템에 존재해야 하지만 지금까지 기본적으로 이를 탑재하고 설치하는 리눅스 배포판은 거의 없다. 그러나 대부분의 배포판은 pax를 별도로 설치 가능한 패키지로 포함한다.
pax는 또한 윈도우 NT에도 존재했는데, 여기서는 파일 아카이브(테이프는 지원되지 않음)로 제한되었다. 나중에 인테릭스 하위 시스템으로 이동되었다. Win32 ACL 아카이빙 또는 복원을 지원하지 않는다. pax는 윈도우 2000에도 존재했다.
Installer (macOS)에서 처리하는 패키지는 종종 Archive.pax.gz 파일에 내용의 대부분을 담고 있으며, 이는 시스템의 pax(heirloom) 유틸리티를 사용하여 읽을 수 있다.
Tput
컴퓨팅에서 tput은 터미널 기능을 활용하는 표준 유닉스 운영체제 명령어이다.
시스템에 따라 tput은 terminfo 또는 termcap 데이터베이스를 사용하며, 터미널 유형에 대한 환경도 살펴본다.
Tput 역사
tput은 1980년대 초 유닉스 시스템 V에 제공되었다. AT&T tput의 복제본은 1986년 9월 mod.sources 뉴스그룹(이후 comp.sources.unix) 7권에 제출되었다. 시스템 V 프로그램과 달리, 이 복제본은 terminfo 대신 termcap을 사용했다. cm (커서 주소 지정) 기능에 대한 명령줄 매개변수를 허용했고, terminfo 기능 이름을 인식했다.
시스템 V 릴리스 3은 서로 다른 초기화 기능을 새로운 옵션 init으로, 재설정 기능을 reset으로 통합하여 터미널을 초기화하거나 재초기화하는 tput 사용을 간소화한 개선된 버전을 제공했다. 시스템 V 릴리스 3.2는 terminfo 데이터베이스에 swidm (enter_doublewide_mode)와 같은 몇 가지 프린터 관련 기능을 추가하여 tput이 사용할 수 있게 했다. 또한 색상 기능도 추가했다.
시스템 V 릴리스 4는 tput이 사용할 수 있는 표준화된 ANSI 색상 기능 setaf와 setab를 포함한 추가 terminfo 기능을 정의했다.
Tput 역사
BSD 플랫폼은 4.3BSD-Reno (1990년 6월)에 tput의 다른 구현을 제공했다. 이 구현은 termcap을 사용했으며, termcap 기능 이름만 인식했고, 커서 주소 지정에 대한 명령줄 매개변수를 허용하지 않았다. FreeBSD는 1994년에 이를 사용하여 하나 또는 두 개의 숫자 명령줄 매개변수를 허용하도록 개선했다.
로스 리지(Ross Ridge)의 mytinfo 패키지(1992년)는 termcap 또는 terminfo 기능 이름을 모두 허용하는 tput을 제공했다. 리노 구현과 마찬가지로, 매개변수화된 기능에 명령줄 인수를 전달하지 않았다. ncurses는 1995년 6월 mytinfo 코드를 통합했다. 초기 버전은 -S 옵션을 추가하고, 시스템 V 릴리스 4 문서에 설명된 대로 명령줄 매개변수를 해석했다.
Tput 이식성
오픈 그룹은 하나의 옵션(-T, 터미널 유형 지정)과 세 개의 키워드(init, clear, reset)를 정의한다.
대부분의 구현은 필요한 매개변수와 함께 터미널 기능의 이름을 허용한다.
그러나 일부 구현은 termcap 이름을 예상하는 반면, 다른 구현은 terminfo 이름을 예상한다.
모든 시스템 V 릴리스 4 구현과 호환되도록 설계된 구현은 -S 옵션(tput이 표준 입력에서 데이터를 읽도록 지시)과 추가 키워드 longname도 인식한다. 또한 명령줄 매개변수를 허용하며, 일반적으로 매개변수의 형식으로 숫자 매개변수와 문자열 매개변수를 구별하고, 모든 숫자로 구성된 문자를 확인한다. 예를 들어 함수 키 레이블을 숫자로 구성된 문자열로 설정하는 것은 불가능하다. 다른 접근 방식을 사용하여 ncurses는 문자열 매개변수를 사용하는 terminfo 기능 테이블을 통해 예상되는 매개변수 유형을 결정하여 모호성을 제거한다.
Terminfo
Terminfo는 프로그램이 단말기를 장치 독립적인 방식으로 사용할 수 있도록 하는 라이브러리이자 데이터베이스이다. 메리 앤 호턴은 termcap에 대한 개선책으로 1981-1982년에 최초의 terminfo 라이브러리를 구현했다. 개선 사항은 다음과 같다.
terminfo는 유닉스 시스템 V 릴리스 2에 포함되었고, 곧 System V에서 (BSD가 계속 사용했던) termcap 대신 선호되는 단말기 설명 형식이 되었다. 이는 파벨 커티스에 의해 1982-1984년에 pcurses에서 모방되었으며, 메리 호턴의 수정 사항을 적용하거나 통합하여 다른 유닉스 구현에서도 사용할 수 있었다. 더 자세한 정보는 1986년 12월 comp.sources.unix 뉴스그룹 게시물을 참조하라.
terminfo 데이터베이스는 수백 가지의 다른 단말기 디스플레이 기능을 설명할 수 있다. 이를 통해 외부 프로그램은 단말기 유형에 독립적으로 문자 기반 디스플레이 출력을 가질 수 있다.
일부 구성은 다음과 같다.
Terminfo 데이터 모델
terminfo 데이터베이스는 하나 이상의 단말기 설명으로 구성된다.
각 설명은 단말기의 표준 이름을 포함해야 한다. 또한 단말기 이름에 대한 하나 이상의 별칭을 포함할 수 있다. 표준 이름 또는 별칭은 라이브러리가 terminfo 데이터베이스를 검색하는 키이다.
설명에는 관례적인 이름을 가진 하나 이상의 기능이 포함된다.
기능은 불리언, 숫자, 문자열 유형을 가진다.
terminfo 라이브러리는 각 기능 이름에 대해 미리 정의된 유형을 가지고 있다.
다음 구문을 통해 각 기능의 유형을 확인한다.
terminfo를 사용하는 애플리케이션은 각 기능에 대한 유형을 알고 있으며, 미리 정의된 유형 기능 중 하나에 기능 이름이 해당할 때만 성공적으로 반환하는 라이브러리 호출을 사용하여 terminfo 데이터베이스에서 기능 값을 얻는다.
Terminfo 데이터 모델
termcap과 마찬가지로 일부 문자열 기능은 키보드의 특수 키를 눌러 호스트로 보낼 수 있는 이스케이프 시퀀스를 나타낸다. 다른 기능은 애플리케이션이 단말기로 보낼 수 있는 문자열을 나타낸다. 후자의 경우, terminfo 라이브러리 함수는 (termcap 라이브러리와 마찬가지로) 애플리케이션 매개변수를 전송되는 문자열에 대체하는 기능을 수행한다. 이러한 함수는 스택 기반 표현식 파서를 제공하는데, 이는 주로 SGR (Select Graphic Rendition)과 같이 선택적 매개변수를 가지는 제어 시퀀스에 대해 전송되는 문자 수를 최소화하는 데 도움을 주기 위해 사용된다. 대조적으로, termcap 라이브러리는 대부분의 단말기에 유용한 제한된 수의 연산만 제공한다.
terminfo 설명은 하나의 설명의 내용을 다른 설명에 포함시키거나, 포함된 설명의 기능을 억제하거나, 기능을 재정의하거나 추가함으로써 구성될 수 있다. 어떤 저장 모델이 사용되든, terminfo 라이브러리는 독립 실행형 도구(예: tic)를 사용하여 컴파일된 데이터를 이용하여 요청된 설명에서 단말기 설명을 반환한다.
Terminfo 저장 모델
terminfo 데이터는 이진 파일로 저장되어 termcap보다 수정하기가 덜 간단하다. 데이터는 저장된 파일에서 terminfo 라이브러리에 의해 검색될 수 있다. 데이터 자체는 불리언, 숫자, 문자열 기능에 대한 테이블로 각각 구성된다. 이는 메리 호턴이 고안한 방식이며, 사용 가능한 이름에 대한 일부 차이점을 제외하고 대부분의 terminfo 구현에서 사용된다. X/Open은 컴파일된 단말기 설명의 형식을 지정하지 않는다. 사실, 흔히 사용되는 tic 또는 infocmp 유틸리티조차 언급하지 않는다. 컴파일된 terminfo 항목은 각 기능이 할당된 테이블 내 색인을 식별하는 메타데이터를 포함하지 않으므로, 구현 간에 반드시 호환되지는 않는다. 그러나 대부분의 구현이 동일한 전체 테이블 구조(including 헤더 및 데이터 항목의 크기 포함)를 사용하기 때문에, 특정 구현에 대한 데이터를 읽을 수 있는 사용자 지정 terminfo 라이브러리를 자동으로 구성할 수 있다. 예를 들어, Ncurses는 여러 다른 구현을 위한 terminfo 데이터와 일치하도록 빌드될 수 있다.
Terminfo 저장 모델
terminfo 라이브러리의 원본(가장 일반적인) 구현은 디렉터리 계층에서 데이터를 검색한다. 단말기 설명 이름의 첫 글자를 경로 이름의 한 구성 요소로 사용하고, 단말기 설명 이름을 검색할 파일의 이름으로 사용하여 terminfo 라이브러리는 일반적으로 큰 termcap 파일을 검색하는 것보다 성능이 뛰어나다.
terminfo의 일부 구현은 단말기 설명을 해시된 데이터베이스(예: 버클리 DB 버전 1.85와 같은 것)에 저장한다. 이들은 두 가지 유형의 레코드를 저장한다. 표준 항목을 가리키는 별칭과 단말기 기능에 대한 데이터를 포함하는 표준 항목 자체이다.
Terminfo 제한 및 확장
오픈 그룹은 terminfo의 제한(최소 보장 값)을 문서화하는데, 이는 소스 파일에만 적용된다.
이 중 특히 중요한 두 가지는 다음과 같다.
14자 제한은 파일 이름이 그 이상 길 수 없었던 매우 오래된 파일 시스템을 대상으로 한다. 그러한 파일 시스템은 일반적으로 구식이 되었지만, 이 제한은 1980년대 후반부터 문서화되어 있었고 그 이후로 검토되지 않았다.
32,767 제한은 부호 있는 2의 보수 16비트 값의 양수 값에 대한 것이다. terminfo 항목은 취소되거나 없는 값을 나타내기 위해 음수를 사용할 수 있다.
termcap과 달리 terminfo는 소스 및 컴파일된 표현을 모두 가진다. 컴파일된 표현에 대한 제한은 지정되지 않았다. 그러나 대부분의 구현은 tic(터미널 정보 컴파일러)에 대한 문서에서 컴파일된 항목이 4,096바이트를 초과할 수 없음을 명시한다.
Termcap
Termcap("terminal capability")은 유닉스 계열 컴퓨터에서 사용되는 레거시 라이브러리 및 데이터베이스로, 프로그램이 단말기를 터미널과 독립적인 방식으로 사용할 수 있도록 하여 휴대용 텍스트 모드 애플리케이션 작성을 크게 단순화한다. 이것은 Ncurses, tput 및 기타 프로그램에서 사용하는 Terminfo 데이터베이스로 대체되었다.
termcap 데이터베이스는 수백 가지의 다양한 디스플레이 터미널의 기능을 설명할 수 있다. 이를 통해 프로그램은 터미널 유형에 관계없이 문자 기반 디스플레이 출력을 가질 수 있다. vi 및 이맥스와 같은 화면 텍스트 편집기는 termcap을 사용할 수 있는 프로그램의 예이다. 다른 프로그램은 Termcap 범주에 나열되어 있다. termcap 데이터베이스에 대한 액세스는 일반적으로 별도의 라이브러리(예: GNU Termcap)에 의해 제공되었다.
데이터베이스가 설명하는 내용의 예:
Termcap 역사
빌 조이는 버클리 유닉스 운영체제를 위해 1978년에 첫 termcap 라이브러리를 작성했다. 이후 대부분의 유닉스 및 유닉스 계열 환경, 심지어 OS-9에도 이식되었다. 조이의 설계는 초기 Incompatible Timesharing System의 터미널 데이터 저장소 설계에 영향을 받은 것으로 알려져 있다.
Termcap 데이터 모델
Termcap 데이터베이스는 하나 이상의 터미널 설명으로 구성된다.
각 설명에는 터미널의 표준 이름이 포함되어야 한다. 터미널 이름에 대한 하나 이상의 별칭도 포함될 수 있다. 표준 이름 또는 별칭은 라이브러리가 termcap 데이터베이스를 검색하는 데 사용하는 키이다.
설명에는 하나 이상의 기능이 포함되며, 이는 관습적인 이름을 가지고 있다. 기능은 불리언, 숫자 및 문자열 유형을 가진다. termcap 라이브러리는 각 기능 이름에 대해 미리 결정된 유형을 가지고 있지 않다. 구문을 통해 각 기능의 유형을 결정한다:
termcap을 사용하는 애플리케이션은 일반적으로 사용되는 기능에 대해 특정 유형을 기대하며, 데이터베이스 내용이 가정된 유형과 일치할 때만 성공적으로 반환되는 라이브러리 호출을 사용하여 termcap 데이터베이스에서 기능 값을 얻는다.
Termcap 설명은 하나의 설명의 내용을 다른 설명에 포함시키고, 포함된 설명에서 기능을 억제하거나, 기능을 재정의하거나 추가하여 구성할 수 있다. 어떤 저장 모델이 사용되든, termcap 라이브러리는 요청 시 요청된 설명에서 터미널 설명을 구성하며, 포함, 억제 또는 재정의를 수행한다.
Termcap 저장 모델
Termcap 데이터는 텍스트로 저장되므로 쉽게 수정할 수 있다. 텍스트는 파일이나 환경 변수에서 termcap 라이브러리에 의해 검색될 수 있다.
TERM 환경 변수에는 터미널 유형 이름이 포함되어 있다.
TERMCAP 환경 변수에는 termcap 데이터베이스가 포함될 수 있다. 이는 터미널 에뮬레이터가 셸 및 종속 프로그램에 터미널 특성을 제공하기 위해 설정하는 단일 termcap 설명을 저장하는 데 가장 자주 사용된다.
TERMPATH 환경 변수는 최신 termcap 구현에서 지원되며 termcap 파일의 검색 경로를 정의한다.
termcap 라이브러리의 원본(및 가장 일반적인) 구현은 플랫 텍스트 파일에서 데이터를 검색한다. 500KB와 같은 큰 termcap 파일을 검색하는 것은 느릴 수 있다. 성능 향상을 위해 reorder와 같은 유틸리티를 사용하여 가장 자주 사용되는 항목을 파일 시작 부분에 배치한다.
Termcap 저장 모델
4.4BSD 기반 termcap 구현은 터미널 설명을 해시된 데이터베이스(예: 버클리 DB 버전 1.85와 유사한 것)에 저장한다. 이들은 두 가지 유형의 레코드를 저장한다: 표준 항목을 가리키는 별칭과 표준 항목 자체. termcap 항목의 텍스트는 문자 그대로 저장된다.
Termcap 제한 및 확장
원래 termcap 구현은 적은 메모리를 사용하도록 설계되었다.
termcap 인터페이스의 최신 구현은 일반적으로 항목 시작 부분에 두 문자 이름이 필요하지 않다.
기능 이름은 모든 구현에서 여전히 두 문자이다.
터미널 설명을 읽는 데 사용되는 tgetent 함수는 데이터에 충분히 커야 하는 버퍼를 사용하며, 1024자로 가정된다. termcap 인터페이스의 최신 구현은 고정 버퍼 대신 널 포인터를 허용하거나, NetBSD termcap의 ZZ 기능 등을 통해 맞지 않는 데이터를 숨김으로써 이 제약을 완화할 수 있다. Terminfo 라이브러리 인터페이스도 termcap 인터페이스를 에뮬레이션하며, 실제로는 고정 크기 버퍼를 사용하지 않는다.
terminfo 라이브러리의 termcap 에뮬레이션은 위치를 제한하지 않고 여러 다른 항목을 포함할 수 있도록 한다. termcap 라이브러리의 몇 가지 다른 최신 구현도 이 기능을 제공할 수 있지만, 잘 문서화되어 있지는 않다.
Termcap 사용되지 않는 기능
특수 기능인 "hz" 기능은 ASCII 물결표 문자('~')를 제어 시퀀스 시작 문자로 사용하는 불운한 특성을 가진 Hazeltine 1500 터미널을 지원하기 위해 특별히 정의되었다. 해당 터미널을 지원하려면 데이터베이스를 사용하는 코드가 특정 제어 시퀀스를 도입하는 데 물결표를 사용하는 방법을 알아야 할 뿐만 아니라, 표시되는 텍스트의 모든 물결표를 다른 인쇄 가능한 문자로 대체하는 방법도 알아야 했다. 텍스트의 물결표가 터미널에 의해 제어 시퀀스의 시작으로 해석되어 텍스트 누락 및 화면 손상이 발생했기 때문이다. 또한, (밑줄 시작 및 끝과 같은) 속성 표시는 화면에서 공간을 차지했다. 데이터베이스 소스 코드의 주석은 종종 이를 "Hazeltine brain damage"라고 언급했다. Hazeltine 1500은 1970년대 후반에 널리 사용되던 터미널이었기 때문에, 애플리케이션이 그 한계를 처리할 수 있는 것이 중요했다.
NILFS
NILFS 또는 NILFS2(New Implementation of a Log-structured File System)는 리눅스 커널용 로그 구조화 파일 시스템 구현이다. 일본전신전화 (NTT) 사이버스페이스 연구소와 전 세계 커뮤니티가 개발했다. NILFS는 GNU 일반 공중 사용 허가서 (GPL) 조건에 따라 출시되었다.
NILFS 설계
"NILFS는 저장 매체를 원형 버퍼처럼 취급하고 새 블록은 항상 끝에 기록되는 로그 구조화 파일 시스템이다. [...] 로그 구조화 파일 시스템은 자연스럽게 웨어 레벨링을 수행하므로 플래시 미디어에 자주 사용된다. [...] NILFS는 스냅샷을 강조한다. 로그 구조화 방식은 특정 형태의 카피 온 라이트 동작이므로 파일 시스템 스냅샷 생성에 자연스럽게 적합하다. NILFS 개발자는 사용자 시작 파일 시스템 문제에서 복구하는 데 사용할 수 있는 "연속 스냅샷" 생성에 대해 이야기한다. [...]"
로그 구조화 파일 시스템으로 알려진 카피 온 라이트 기술을 사용하여 NILFS는 모든 데이터를 연속적인 로그와 같은 형식으로 기록하며, 이 형식은 덮어쓰지 않고 오직 추가만 된다. 이 방식은 탐색 시간을 줄이고 기존 파일 시스템에서 충돌 후 발생하는 데이터 손실을 최소화하도록 설계되었다. 예를 들어, 시스템이 쓰기 작업 중에 충돌하면 Ext3 파일 시스템에서 데이터 손실이 발생한다. 시스템이 재부팅되면 저널은 쓰기가 완료되지 않았음을 기록하고 부분 데이터 쓰기는 손실된다.
NILFS 설계
솔라리스 운영체제 및 BSD에서 사용되는 UFS 파생 파일 시스템과 같은 일부 파일 시스템은 이러한 데이터 손실을 방지하는 스냅샷 기능을 제공하지만, 대규모 파일 시스템에서는 스냅샷 구성이 길어질 수 있다. 반대로 NILFS는 NTT Labs에 따르면 "서비스를 중단하지 않고 파일 시스템의 즉각적인 상태를 지속적이고 자동으로 [저장]할 수 있다."
NILFS가 지속적으로 저장하는 "즉각적인 상태"는 실제 파일 시스템이 읽기-쓰기 방식으로 마운트된 것과 동시에 읽기 전용으로 마운트될 수 있다. 이 기능은 하드웨어 오류 및 기타 시스템 충돌 후 데이터 복구에 유용하다. 대화형 NILFS "검사" 유틸리티의 "lscp"(체크포인트 나열) 명령은 먼저 체크포인트 주소(이 경우 "2048")를 찾는 데 사용된다.
체크포인트 주소는 체크포인트를 마운트하는 데 사용된다.
NILFS 기능
NILFS는 연속 스냅샷 기능을 제공한다. 전체 파일 시스템의 버전 관리 기능 외에도 사용자는 실수로 덮어쓰거나 삭제한 파일을 언제든지 최근 시점으로 복원할 수 있다. NILFS는 기존 LFS처럼 일관성을 유지할 수 있으므로 시스템 충돌 후 빠른 복구를 달성한다.
연속 스냅샷 기능은 시점 스냅샷을 지원하는 파일 시스템(예: Btrfs)을 포함하여 대부분의 파일 시스템에서 제공되지 않는다.
NILFS는 몇 초마다 또는 동기 쓰기 기준으로 여러 개의 체크포인트를 생성한다(변경 사항이 없는 경우는 제외). 사용자는 지속적으로 생성되는 체크포인트 중에서 중요한 버전을 선택하고 이를 스냅샷으로 변경할 수 있으며, 스냅샷은 체크포인트로 다시 변경될 때까지 보존된다.
볼륨이 가득 찰 때까지 스냅샷 수에는 제한이 없다. 각 스냅샷은 읽기 전용 파일 시스템으로 마운트할 수 있다. 쓰기 가능한 마운트 및 다른 스냅샷과 동시에 마운트할 수 있으며, 이 기능은 사용 중에 일관된 백업을 만드는 데 편리하다.
NILFS 기능
NILFS의 가능한 용도는 버전 관리, 변조 감지, SOX 규정 준수 로깅, 데이터 손실 복구 등이다.
현재 NILFS의 주요 버전은 버전 2이며 NILFS2라고 불린다. NILFS2는 여러 스냅샷을 유지하면서 디스크 공간을 회수하기 위한 온라인 쓰레기 수집을 구현한다.
다른 NILFS 기능은 다음과 같다.
2023년 현재 NILFS는 전용 일관성 검사 유틸리티(fsck)가 없어 유효한 체크포인트를 찾지 못하게 하는 심각한 오류로부터 복구할 수 없다.
NILFS 호환성
NILFS는 아치 리눅스, 데비안 (버전 5.0부터), 페도라, 젠투, 리눅스 민트, NixOS, 우분투 (버전 9.10부터) 등 다양한 GNU/리눅스 배포판에서 사용할 수 있다. 사용자는 일반적으로 nilfs-utils 또는 nilfs-tools 패키지를 설치해야 한다. NILFS가 포함된 부팅 CD는 PrRescue에서도 구할 수 있다.
또한 GParted와 같은 파티션 편집 애플리케이션에서도 지원된다.
별도의 BSD 라이선스 구현은 현재 '읽기 전용' 지원과 함께 NetBSD에 포함되어 있다.
NILFS 상대적 성능
2015년 1월 Linux.conf.au에서 발표된 SD 카드 및 파일 시스템을 위한 임베디드 시스템에서 다음과 같이 언급되었다.
NILFS 라이선스
NILFS2 파일 시스템 유틸리티는 GNU 일반 공중 사용 허가서 버전 2에 따라 제공되며, lib/nilfs 라이브러리와 해당 헤더 파일은 GNU 약소 일반 공중 사용 허가서 버전 2.1에 따라 제공된다.
NILFS 개발자
NTT Corporation 연구소에서 일했거나 현재 일하고 있는 nilfs-utils의 일본인 주요 저자 및 주요 기여자는 다음과 같다.
다른 주요 기여자는 다음과 같다.
OCFS2
오라클 클러스터 파일 시스템(Oracle Cluster File System, OCFS, 두 번째 버전은 OCFS2)은 오라클 코퍼레이션이 개발하고 GNU 일반 공중 사용 허가서에 따라 배포된 공유 디스크 파일 시스템이다. OCFS의 첫 번째 버전은 클러스터 컴퓨팅을 사용하는 오라클의 데이터베이스 관리 시스템을 수용하는 데 중점을 두고 개발되었다. 이 때문에 POSIX 호환 파일 시스템이 아니었다. 버전 2에서는 POSIX 기능이 포함되었다.
OCFS2 (버전 2)는 리눅스 커널 버전 2.6.16에 통합되었다. 처음에는 "실험적"(알파 테스트) 코드로 표시되었다. 이 제한은 리눅스 버전 2.6.19에서 제거되었다. 2008년 말 커널 버전 2.6.29에서 접근 제어 목록 및 할당량과 같은 더 많은 기능이 OCFS2에 포함되었다.
OCFS2는 OpenVMS DLM과 유사하지만 훨씬 더 단순한 분산 락 관리자를 사용했다.
오라클은 2010년 11월에 reflink라는 카피 온 라이트 기능을 포함한 버전 1.6을 발표했다.
FTPFS
FTPFS는 표준 API를 통해 파일 전송 프로토콜(FTP) 서버에 대한 액세스를 지원하는 파일 시스템을 의미한다.
플랜 9의 ftpfs 명령어는 데니스 리치가 고안했으며 시스템의 첫 번째 릴리스(1992년)에 포함되었다. 이는 FTP를 통해 접근 가능한 원격 파일 시스템을 로컬 파일 시스템의 일부처럼 보이게 했다.
리눅스 시스템에서 FTPFS는 처음에는 사용자가 FTP 서버를 로컬 파일 시스템에 마운트할 수 있도록 하는 리눅스 커널 모듈로 구현되었지만, 완벽한 방법으로 여겨지지는 않았다. 2003년에는 LUFS를 사용하도록 전환되었고, 이후 FUSE로 전환되었다. 현재는 FTP 트랜잭션에 보편적인 libcurl을 사용하기 때문에 CurlFtpFS라고 불리며 주요 리눅스 배포판의 일부가 되고 있다. FTP 사이트의 스마트 미러링을 위한 LftpFS도 존재한다.
FTPFS
MacOS에서는 GUI(⌘ Command+K) 또는 명령줄(mount_ftp)을 통해 사용할 수 있는 읽기 전용 FTP 파일 시스템이 포함되어 있다. 읽기 전용 제한은 mount_ftp의 man 페이지(macOS 시스템에서 Terminal.app에서 "man mount_ftp" 참조)에 명시되어 있다. 그러나 무료 애플리케이션인 Macfusion은 FTPFS의 작동 가능한 구현을 포함하고 있다. 또한 macOS Fuse가 이를 활성화한다고 보고되었지만, 그렇게 하는 방법은 다양한 명확한 man 페이지(예: sshfs)나 macOS Fuse 위키에서 문서화되지 않았다(2013년 3월 4일 기준).
윈도우 XP, 윈도우 7 및 기타 윈도우 운영 체제의 경우, 이 기능은 "네트워크 환경"/"네트워크 위치" 셸 기능에 의해 부분적으로 제공된다. 네트워크 위치는 FTP 서버 또는 WebDAV 서버에 대한 링크이며 윈도우 탐색기에서 다른 네트워크 파일 시스템처럼 액세스할 수 있다. 그러나 이것은 가장 낮은 수준의 Win32 파일 시스템 API를 통한 투명한 액세스를 제공하지는 않는다. 이러한 기능은 WebDrive 및 FTPDrive와 같은 타사 프로그램을 통해 제공될 수 있다.
AdvFS
AdvFS 또는 Tru64 UNIX Advanced File System은 1980년대 후반부터 1990년대 중반까지 디지털 이큅먼트 코퍼레이션이 자사의 OSF/1 버전 유닉스 운영체제(이후 Digital UNIX/Tru64 UNIX)를 위해 개발한 파일 시스템이다. 2008년 6월, GPL-2.0-only 라이선스 하에 자유 소프트웨어로 출시되었다. AdvFS는 다운타임으로부터의 빠른 복구가 필수적인 고가용성 시스템에서 사용되어 왔다.:428
AdvFS 기능
AdvFS는 저장소 풀(파일 도메인이라 불림)과 논리 파일 시스템(파일 세트라 불림)이라는 상대적으로 발전된 개념을 사용한다. 파일 도메인은 파티션, LVM 또는 LSM 장치가 될 수 있는 여러 블록 장치로 구성된다. 파일 세트는 단일 파일 도메인 내에서 생성된 논리 파일 시스템이다. 관리자는 활성 파일 도메인에서 볼륨을 추가하거나 제거할 수 있으며, 제거 시 남은 파일 도메인에 충분한 공간이 있는 경우에 가능하다. 이는 제거될 디스크에 있는 모든 데이터나 메타데이터가 제거 전에 온라인으로 다른 디스크로 먼저 마이그레이션되어야 했기 때문에 구현하기 까다로운 초기 기능 중 하나였다.
파일 세트는 균형을 이룰 수 있으며, 이는 파일 세트의 파일 내용이 물리적 볼륨 전체에 걸쳐 균형을 이룰 수 있음을 의미한다. 파일 세트의 특정 파일은 사용 가능한 볼륨에 걸쳐 스트라이프될 수 있다.
AdvFS 기능
관리자는 활성 또는 비활성 파일 세트의 스냅샷(또는 클론)을 찍을 수 있다. 이를 통해 쉬운 온라인 백업 및 편집이 가능하다.
또 다른 기능은 관리자가 활성 사용자가 있는 동안에도 파일 도메인에서 블록 장치를 추가하거나 제거할 수 있도록 한다. 이 추가/제거 기능을 통해 시스템 종료 없이 더 큰 장치로 마이그레이션하거나 잠재적으로 실패할 수 있는 하드웨어에서 마이그레이션할 수 있다.
주요 기능은 다음과 같다:
리눅스에서 AdvFS는 여러 파일에 대한 변경 사항을 원자적으로 커밋하기 위해 추가적인 ‘’syncv’’ 시스템 호출을 지원한다.
AdvFS 역사
Tru64 UNIX Advanced File System으로도 알려진 AdvFS는 1980년대 후반부터 벨뷰의 디지털 이큅먼트 코퍼레이션 공학자들이 개발하기 시작했다(DECwest). 이 프로젝트는 취소된 OZIX 운영체제 프로젝트의 파일 시스템으로 시작되었다.
이것은 DEC OSF/1 시스템(이후 Digital UNIX/Tru64 UNIX)에 처음으로 제공되었다. 시간이 지나면서 개발은 워싱턴주 벨뷰와 뉴햄프셔주 내슈아에 위치한 팀으로 옮겨졌다. 버전은 항상 운영체제 버전보다 한 버전 뒤쳐졌다. 따라서 DEC OSF/1 v3.2에는 AdvFS v2.x가, Digital UNIX 4.0에는 AdvFS v3.x가, Tru64 UNIX 5.x에는 AdvFS v4.x가 있었다. 일반적으로 AdvFS v4만이 충분한 도구 세트를 갖추고 관리자들이 어떤 종류의 문제에서도 벗어날 수 있도록 하여 생산 수준의 안정성으로 성숙했다고 간주된다. 원래 팀은 파일 시스템 저널이 항상 미러링된 드라이브에 할당될 것이라는 가정 하에 "fsck" 스타일 복구 유틸리티 없이 로그 기반 복구를 출시할 만큼 충분한 자신감을 가졌다.
AdvFS 역사
1996년, 리와 데카스는 Petal로 알려진 새로운 디스크 가상화 계층 위에 AdvFS를 사용하는 방법을 설명했다. 나중 논문에서, 데카스 등은 Petal 위에 구축된 자체 파일 시스템(Frangipani)을 설명하고 동일한 저장 계층에서 실행되는 AdvFS의 성능과 비교했다.
샤피로와 밀러는 AdvFS에 저장된 파일의 성능을 Oracle RDBMS 버전 7.3.4 BLOB 저장소와 비교했다.
컴팩 시에라 병렬 파일 시스템(PFS)은 여러 로컬 AdvFS 파일 시스템을 기반으로 클러스터 파일 시스템을 만들었다. 2000-2001년 로렌스 리버모어 국립연구소(LLNL)에서 수행된 테스트에 따르면 기본 AdvFS 파일 시스템은 적절한 성능을 보였지만(높은 CPU 사용률에도 불구하고), 그 위에 있는 PFS 클러스터링 계층은 성능이 좋지 않았다.
2008년 6월 23일, 휴렛 팩커드는 리눅스 커널과도 호환되도록 GPL-2.0-only 라이선스(최근 출시된 GPLv3 대신) 하에 소스포지에 소스 코드를 공개했다.
GPFS
GPFS(General Parallel File System, 브랜드명 IBM Storage Scale, 이전에는 IBM Spectrum Scale)는 IBM에서 개발한 고성능 클러스터 파일 시스템 소프트웨어다. 이는 공유 디스크 또는 공유 없음 분산 병렬 모드, 또는 이 둘의 조합으로 배포될 수 있다. 전 세계의 많은 대기업과 Top 500 리스트에 있는 일부 슈퍼컴퓨터에서 사용된다.
예를 들어, 오크리지 국립연구소의 서밋의 파일 시스템이다.

서밋은 2019년 11월 Top 500 리스트에서 세계에서 가장 빠른 슈퍼컴퓨터 1위였다. 서밋은 9,000개 이상의 POWER9 프로세서와 27,000개의 엔비디아 볼타 GPU로 구성된 200 페타플롭스 시스템이다. 저장 파일 시스템은 알파인(Alpine)이라고 불린다.
일반적인 클러스터 파일 시스템과 마찬가지로, GPFS는 클러스터의 여러 노드에서 실행되는 애플리케이션에 동시 고속 파일 접근을 제공한다. AIX 클러스터, 리눅스 클러스터, 마이크로소프트 윈도우 서버 또는 x86, Power 또는 IBM Z 프로세서 아키텍처에서 실행되는 AIX, 리눅스 및 윈도우 노드의 이기종 클러스터와 함께 사용할 수 있다.
GPFS 역사
GPFS는 1993년 IBM 알마덴 연구 센터의 연구 프로젝트인 타이거 샤크(Tiger Shark) 파일 시스템으로 시작되었다. 타이거 샤크는 처음에는 고속 멀티미디어 애플리케이션을 지원하도록 설계되었다. 이 설계는 과학 컴퓨팅에 잘 맞는 것으로 판명되었다.
또 다른 조상은 1992년부터 1995년 사이에 IBM 토마스 J. 왓슨 연구 센터의 연구 프로젝트로 개발된 IBM의 베스타(Vesta) 파일 시스템이다. 베스타는 고성능 멀티컴퓨터에 병렬 I/O 서브시스템이 실행되는 병렬 애플리케이션의 요구를 수용하기 위해 파일 파티셔닝 개념을 도입했다. 파티셔닝을 통해 파일은 바이트 시퀀스가 아니라 병렬로 접근할 수 있는 여러 개의 분리된 시퀀스이다. 파티셔닝은 파일 시스템을 호스팅하는 I/O 노드의 수와 유형을 추상화하고, I/O 노드 내의 물리적 데이터 분배와 관계없이 다양한 논리적으로 파티션된 파일 보기를 허용한다. 분리된 시퀀스는 병렬 애플리케이션의 개별 프로세스에 대응하도록 배열되어 확장성을 향상시킨다.