shopkeeper/korean_wiki_content_only_120125 huggingface dataset:
terminfo는 유닉스 시스템 V 릴리스 2에 포함되었고, 곧 System V에서 (BSD가 계속 사용했던) termcap 대신 선호되는 단말기 설명 형식이 되었다. 이는 파벨 커티스에 의해 1982-1984년에 pcurses에서 모방되었으며, 메리 호턴의 수정 사항을 적용하거나 통합하여 다른 유닉스 구현에서도 사용할 수 있었다. 더 자세한 정보는 1986년 12월 codice_1 뉴스그룹 게시물을 참조하라.
terminfo 데이터베이스는 수백 가지의 다른 단말기 디스플레이 기능을 설명할 수 있다. 이를 통해 외부 프로그램은 단말기 유형에 독립적으로 문자 기반 디스플레이 출력을 가질 수 있다.
일부 구성은 다음과 같다.
terminfo 데이터베이스는 하나 이상의 단말기 설명으로 구성된다.
각 설명은 단말기의 표준 이름을 포함해야 한다. 또한 단말기 이름에 대한 하나 이상의 별칭을 포함할 수 있다. 표준 이름 또는 별칭은 라이브러리가 terminfo 데이터베이스를 검색하는 키이다.
데이터 값.
설명에는 관례적인 이름을 가진 하나 이상의 기능이 포함된다.
기능은 불리언, 숫자, 문자열 유형을 가진다.
terminfo 라이브러리는 각 기능 이름에 대해 미리 정의된 유형을 가지고 있다.
다음 구문을 통해 각 기능의 유형을 확인한다.
terminfo를 사용하는 애플리케이션은 각 기능에 대한 유형을 알고 있으며, 미리 정의된 유형 기능 중 하나에 기능 이름이 해당할 때만 성공적으로 반환하는 라이브러리 호출을 사용하여 terminfo 데이터베이스에서 기능 값을 얻는다.
termcap과 마찬가지로 일부 문자열 기능은 키보드의 특수 키를 눌러 호스트로 보낼 수 있는 이스케이프 시퀀스를 나타낸다. 다른 기능은 애플리케이션이 단말기로 보낼 수 있는 문자열을 나타낸다. 후자의 경우, terminfo 라이브러리 함수는 (termcap 라이브러리와 마찬가지로) 애플리케이션 매개변수를 전송되는 문자열에 대체하는 기능을 수행한다. 이러한 함수는 스택 기반 표현식 파서를 제공하는데, 이는 주로 SGR (Select Graphic Rendition)과 같이 선택적 매개변수를 가지는 제어 시퀀스에 대해 전송되는 문자 수를 최소화하는 데 도움을 주기 위해 사용된다. 대조적으로, termcap 라이브러리는 대부분의 단말기에 유용한 제한된 수의 연산만 제공한다.
terminfo 설명은 하나의 설명의 내용을 다른 설명에 포함시키거나, 포함된 설명의 기능을 억제하거나, 기능을 재정의하거나 추가함으로써 구성될 수 있다. 어떤 저장 모델이 사용되든, terminfo 라이브러리는 독립 실행형 도구(예: tic)를 사용하여 컴파일된 데이터를 이용하여 요청된 설명에서 단말기 설명을 반환한다.
저장 모델.
terminfo 데이터는 이진 파일로 저장되어 termcap보다 수정하기가 덜 간단하다. 데이터는 저장된 파일에서 terminfo 라이브러리에 의해 검색될 수 있다. 데이터 자체는 불리언, 숫자, 문자열 기능에 대한 테이블로 각각 구성된다. 이는 메리 호턴이 고안한 방식이며, 사용 가능한 이름에 대한 일부 차이점을 제외하고 대부분의 terminfo 구현에서 사용된다. X/Open은 컴파일된 단말기 설명의 형식을 지정하지 않는다. 사실, 흔히 사용되는 tic 또는 infocmp 유틸리티조차 언급하지 않는다. 컴파일된 terminfo 항목은 각 기능이 할당된 테이블 내 색인을 식별하는 메타데이터를 포함하지 않으므로, 구현 간에 반드시 호환되지는 않는다. 그러나 대부분의 구현이 동일한 전체 테이블 구조(including 헤더 및 데이터 항목의 크기 포함)를 사용하기 때문에, 특정 구현에 대한 데이터를 읽을 수 있는 사용자 지정 terminfo 라이브러리를 자동으로 구성할 수 있다. 예를 들어, Ncurses는 여러 다른 구현을 위한 terminfo 데이터와 일치하도록 빌드될 수 있다.
디렉터리 트리.
terminfo 라이브러리의 원본(가장 일반적인) 구현은 디렉터리 계층에서 데이터를 검색한다. 단말기 설명 이름의 첫 글자를 경로 이름의 한 구성 요소로 사용하고, 단말기 설명 이름을 검색할 파일의 이름으로 사용하여 terminfo 라이브러리는 일반적으로 큰 termcap 파일을 검색하는 것보다 성능이 뛰어나다.
해시된 데이터베이스.
terminfo의 일부 구현은 단말기 설명을 해시된 데이터베이스(예: 버클리 DB 버전 1.85와 같은 것)에 저장한다. 이들은 두 가지 유형의 레코드를 저장한다. 표준 항목을 가리키는 별칭과 단말기 기능에 대한 데이터를 포함하는 표준 항목 자체이다.
제한 및 확장.
오픈 그룹은 terminfo의 제한(최소 보장 값)을 문서화하는데, 이는 소스 파일에만 적용된다.
이 중 특히 중요한 두 가지는 다음과 같다.
14자 제한은 파일 이름이 그 이상 길 수 없었던 매우 오래된 파일 시스템을 대상으로 한다. 그러한 파일 시스템은 일반적으로 구식이 되었지만, 이 제한은 1980년대 후반부터 문서화되어 있었고 그 이후로 검토되지 않았다.
32,767 제한은 부호 있는 2의 보수 16비트 값의 양수 값에 대한 것이다. terminfo 항목은 취소되거나 없는 값을 나타내기 위해 음수를 사용할 수 있다.
termcap과 달리 terminfo는 소스 및 컴파일된 표현을 모두 가진다. 컴파일된 표현에 대한 제한은 지정되지 않았다. 그러나 대부분의 구현은 tic(터미널 정보 컴파일러)에 대한 문서에서 컴파일된 항목이 4,096바이트를 초과할 수 없음을 명시한다.
Termcap("terminal capability")은 유닉스 계열 컴퓨터에서 사용되는 레거시 라이브러리 및 데이터베이스로, 프로그램이 단말기를 터미널과 독립적인 방식으로 사용할 수 있도록 하여 휴대용 텍스트 모드 애플리케이션 작성을 크게 단순화한다. 이것은 Ncurses, tput 및 기타 프로그램에서 사용하는 Terminfo 데이터베이스로 대체되었다.
termcap 데이터베이스는 수백 가지의 다양한 디스플레이 터미널의 기능을 설명할 수 있다. 이를 통해 프로그램은 터미널 유형에 관계없이 문자 기반 디스플레이 출력을 가질 수 있다. vi 및 이맥스와 같은 화면 텍스트 편집기는 termcap을 사용할 수 있는 프로그램의 예이다. 다른 프로그램은 범주에 나열되어 있다. termcap 데이터베이스에 대한 액세스는 일반적으로 별도의 라이브러리(예: GNU Termcap)에 의해 제공되었다.
데이터베이스가 설명하는 내용의 예:
빌 조이는 버클리 유닉스 운영체제를 위해 1978년에 첫 termcap 라이브러리를 작성했다. 이후 대부분의 유닉스 및 유닉스 계열 환경, 심지어 OS-9에도 이식되었다. 조이의 설계는 초기 Incompatible Timesharing System의 터미널 데이터 저장소 설계에 영향을 받은 것으로 알려져 있다.
Termcap 데이터베이스는 하나 이상의 터미널 설명으로 구성된다.
각 설명에는 터미널의 표준 이름이 포함되어야 한다. 터미널 이름에 대한 하나 이상의 별칭도 포함될 수 있다. 표준 이름 또는 별칭은 라이브러리가 termcap 데이터베이스를 검색하는 데 사용하는 키이다.
설명에는 하나 이상의 기능이 포함되며, 이는 관습적인 이름을 가지고 있다. 기능은 불리언, 숫자 및 문자열 유형을 가진다. termcap 라이브러리는 각 기능 이름에 대해 미리 결정된 유형을 가지고 있지 않다. 구문을 통해 각 기능의 유형을 결정한다:
termcap을 사용하는 애플리케이션은 일반적으로 사용되는 기능에 대해 특정 유형을 기대하며, 데이터베이스 내용이 가정된 유형과 일치할 때만 성공적으로 반환되는 라이브러리 호출을 사용하여 termcap 데이터베이스에서 기능 값을 얻는다.
Termcap 설명은 하나의 설명의 내용을 다른 설명에 포함시키고, 포함된 설명에서 기능을 억제하거나, 기능을 재정의하거나 추가하여 구성할 수 있다. 어떤 저장 모델이 사용되든, termcap 라이브러리는 요청 시 요청된 설명에서 터미널 설명을 구성하며, 포함, 억제 또는 재정의를 수행한다.
Termcap 데이터는 텍스트로 저장되므로 쉽게 수정할 수 있다. 텍스트는 파일이나 환경 변수에서 termcap 라이브러리에 의해 검색될 수 있다.
환경 변수.
TERM 환경 변수에는 터미널 유형 이름이 포함되어 있다.
TERMCAP 환경 변수에는 termcap 데이터베이스가 포함될 수 있다. 이는 터미널 에뮬레이터가 셸 및 종속 프로그램에 터미널 특성을 제공하기 위해 설정하는 단일 termcap 설명을 저장하는 데 가장 자주 사용된다.
TERMPATH 환경 변수는 최신 termcap 구현에서 지원되며 termcap 파일의 검색 경로를 정의한다.
termcap 라이브러리의 원본(및 가장 일반적인) 구현은 플랫 텍스트 파일에서 데이터를 검색한다. 500KB와 같은 큰 termcap 파일을 검색하는 것은 느릴 수 있다. 성능 향상을 위해 reorder와 같은 유틸리티를 사용하여 가장 자주 사용되는 항목을 파일 시작 부분에 배치한다.
4.4BSD 기반 termcap 구현은 터미널 설명을 해시된 데이터베이스(예: 버클리 DB 버전 1.85와 유사한 것)에 저장한다. 이들은 두 가지 유형의 레코드를 저장한다: 표준 항목을 가리키는 별칭과 표준 항목 자체. termcap 항목의 텍스트는 문자 그대로 저장된다.
원래 termcap 구현은 적은 메모리를 사용하도록 설계되었다.
termcap 인터페이스의 최신 구현은 일반적으로 항목 시작 부분에 두 문자 이름이 필요하지 않다.
기능 이름은 모든 구현에서 여전히 두 문자이다.
터미널 설명을 읽는 데 사용되는 tgetent 함수는 데이터에 충분히 커야 하는 버퍼를 사용하며, 1024자로 가정된다. termcap 인터페이스의 최신 구현은 고정 버퍼 대신 널 포인터를 허용하거나, NetBSD termcap의 ZZ 기능 등을 통해 맞지 않는 데이터를 숨김으로써 이 제약을 완화할 수 있다. Terminfo 라이브러리 인터페이스도 termcap 인터페이스를 에뮬레이션하며, 실제로는 고정 크기 버퍼를 사용하지 않는다.
terminfo 라이브러리의 termcap 에뮬레이션은 위치를 제한하지 않고 여러 다른 항목을 포함할 수 있도록 한다. termcap 라이브러리의 몇 가지 다른 최신 구현도 이 기능을 제공할 수 있지만, 잘 문서화되어 있지는 않다.
사용되지 않는 기능.
특수 기능인 "hz" 기능은 ASCII 물결표 문자('~')를 제어 시퀀스 시작 문자로 사용하는 불운한 특성을 가진 Hazeltine 1500 터미널을 지원하기 위해 특별히 정의되었다. 해당 터미널을 지원하려면 데이터베이스를 사용하는 코드가 특정 제어 시퀀스를 도입하는 데 물결표를 사용하는 방법을 알아야 할 뿐만 아니라, 표시되는 텍스트의 모든 물결표를 다른 인쇄 가능한 문자로 대체하는 방법도 알아야 했다. 텍스트의 물결표가 터미널에 의해 제어 시퀀스의 시작으로 해석되어 텍스트 누락 및 화면 손상이 발생했기 때문이다. 또한, (밑줄 시작 및 끝과 같은) 속성 표시는 화면에서 공간을 차지했다. 데이터베이스 소스 코드의 주석은 종종 이를 "Hazeltine brain damage"라고 언급했다. Hazeltine 1500은 1970년대 후반에 널리 사용되던 터미널이었기 때문에, 애플리케이션이 그 한계를 처리할 수 있는 것이 중요했다.
NILFS 또는 NILFS2("New Implementation of a Log-structured File System")는 리눅스 커널용 로그 구조화 파일 시스템 구현이다. 일본전신전화 (NTT) 사이버스페이스 연구소와 전 세계 커뮤니티가 개발했다. NILFS는 GNU 일반 공중 사용 허가서 (GPL) 조건에 따라 출시되었다.
"NILFS는 저장 매체를 원형 버퍼처럼 취급하고 새 블록은 항상 끝에 기록되는 로그 구조화 파일 시스템이다. [...] 로그 구조화 파일 시스템은 자연스럽게 웨어 레벨링을 수행하므로 플래시 미디어에 자주 사용된다. [...] NILFS는 스냅샷을 강조한다. 로그 구조화 방식은 특정 형태의 카피 온 라이트 동작이므로 파일 시스템 스냅샷 생성에 자연스럽게 적합하다. NILFS 개발자는 사용자 시작 파일 시스템 문제에서 복구하는 데 사용할 수 있는 "연속 스냅샷" 생성에 대해 이야기한다. [...]"
로그 구조화 파일 시스템으로 알려진 카피 온 라이트 기술을 사용하여 NILFS는 모든 데이터를 연속적인 로그와 같은 형식으로 기록하며, 이 형식은 덮어쓰지 않고 오직 추가만 된다. 이 방식은 탐색 시간을 줄이고 기존 파일 시스템에서 충돌 후 발생하는 데이터 손실을 최소화하도록 설계되었다. 예를 들어, 시스템이 쓰기 작업 중에 충돌하면 Ext3 파일 시스템에서 데이터 손실이 발생한다. 시스템이 재부팅되면 저널은 쓰기가 완료되지 않았음을 기록하고 부분 데이터 쓰기는 손실된다.
솔라리스 운영체제 및 BSD에서 사용되는 UFS 파생 파일 시스템과 같은 일부 파일 시스템은 이러한 데이터 손실을 방지하는 스냅샷 기능을 제공하지만, 대규모 파일 시스템에서는 스냅샷 구성이 길어질 수 있다. 반대로 NILFS는 NTT Labs에 따르면 "서비스를 중단하지 않고 파일 시스템의 즉각적인 상태를 지속적이고 자동으로 [저장]할 수 있다."
NILFS가 지속적으로 저장하는 "즉각적인 상태"는 실제 파일 시스템이 읽기-쓰기 방식으로 마운트된 것과 동시에 읽기 전용으로 마운트될 수 있다. 이 기능은 하드웨어 오류 및 기타 시스템 충돌 후 데이터 복구에 유용하다. 대화형 NILFS "검사" 유틸리티의 "lscp"(체크포인트 나열) 명령은 먼저 체크포인트 주소(이 경우 "2048")를 찾는 데 사용된다.
nilfs&gt; listcp
1 6 Tue Jul 12 14:55:57 2005 MajorCP|LogiBegin|LogiEnd
2048 2352 Tue Jul 12 14:55:58 2005 MajorCP|LogiEnd
nilfs&gt; quit
체크포인트 주소는 체크포인트를 마운트하는 데 사용된다.
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda2 70332412 8044540 62283776 12% /nilfs
/dev/sda2 70332412 8044540 62283776 12% /nilfs-cp
NILFS는 연속 스냅샷 기능을 제공한다. 전체 파일 시스템의 버전 관리 기능 외에도 사용자는 실수로 덮어쓰거나 삭제한 파일을 언제든지 최근 시점으로 복원할 수 있다. NILFS는 기존 LFS처럼 일관성을 유지할 수 있으므로 시스템 충돌 후 빠른 복구를 달성한다.
연속 스냅샷 기능은 시점 스냅샷을 지원하는 파일 시스템(예: Btrfs)을 포함하여 대부분의 파일 시스템에서 제공되지 않는다.
NILFS는 몇 초마다 또는 동기 쓰기 기준으로 여러 개의 체크포인트를 생성한다(변경 사항이 없는 경우는 제외). 사용자는 지속적으로 생성되는 체크포인트 중에서 중요한 버전을 선택하고 이를 스냅샷으로 변경할 수 있으며, 스냅샷은 체크포인트로 다시 변경될 때까지 보존된다.
볼륨이 가득 찰 때까지 스냅샷 수에는 제한이 없다. 각 스냅샷은 읽기 전용 파일 시스템으로 마운트할 수 있다. 쓰기 가능한 마운트 및 다른 스냅샷과 동시에 마운트할 수 있으며, 이 기능은 사용 중에 일관된 백업을 만드는 데 편리하다.
NILFS의 가능한 용도는 버전 관리, 변조 감지, SOX 규정 준수 로깅, 데이터 손실 복구 등이다.
현재 NILFS의 주요 버전은 버전 2이며 NILFS2라고 불린다. NILFS2는 여러 스냅샷을 유지하면서 디스크 공간을 회수하기 위한 온라인 쓰레기 수집을 구현한다.
다른 NILFS 기능은 다음과 같다.
2023년 현재 NILFS는 전용 일관성 검사 유틸리티(fsck)가 없어 유효한 체크포인트를 찾지 못하게 하는 심각한 오류로부터 복구할 수 없다.
NILFS는 아치 리눅스, 데비안 (버전 5.0부터), 페도라, 젠투, 리눅스 민트, NixOS, 우분투 (버전 9.10부터) 등 다양한 GNU/리눅스 배포판에서 사용할 수 있다. 사용자는 일반적으로 nilfs-utils 또는 nilfs-tools 패키지를 설치해야 한다. NILFS가 포함된 부팅 CD는 PrRescue에서도 구할 수 있다.
또한 GParted와 같은 파티션 편집 애플리케이션에서도 지원된다.
별도의 BSD 라이선스 구현은 현재 '읽기 전용' 지원과 함께 NetBSD에 포함되어 있다.
상대적 성능.
2015년 1월 Linux.conf.au에서 발표된 "SD 카드 및 파일 시스템을 위한 임베디드 시스템"에서 다음과 같이 언급되었다.
NILFS2 파일 시스템 유틸리티는 GNU 일반 공중 사용 허가서 버전 2에 따라 제공되며, lib/nilfs 라이브러리와 해당 헤더 파일은 GNU 약소 일반 공중 사용 허가서 버전 2.1에 따라 제공된다.
NTT Corporation 연구소에서 일했거나 현재 일하고 있는 codice_1의 일본인 주요 저자 및 주요 기여자는 다음과 같다.
다른 주요 기여자는 다음과 같다.
오라클 클러스터 파일 시스템(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는 표준 API를 통해 파일 전송 프로토콜(FTP) 서버에 대한 액세스를 지원하는 파일 시스템을 의미한다.
플랜 9의 ftpfs 명령어는 데니스 리치가 고안했으며 시스템의 첫 번째 릴리스(1992년)에 포함되었다. 이는 FTP를 통해 접근 가능한 원격 파일 시스템을 로컬 파일 시스템의 일부처럼 보이게 했다.
리눅스 시스템에서 FTPFS는 처음에는 사용자가 FTP 서버를 로컬 파일 시스템에 마운트할 수 있도록 하는 리눅스 커널 모듈로 구현되었지만, 완벽한 방법으로 여겨지지는 않았다. 2003년에는 LUFS를 사용하도록 전환되었고, 이후 FUSE로 전환되었다. 현재는 FTP 트랜잭션에 보편적인 libcurl을 사용하기 때문에 CurlFtpFS라고 불리며 주요 리눅스 배포판의 일부가 되고 있다. FTP 사이트의 스마트 미러링을 위한 LftpFS도 존재한다.
MacOS에서는 GUI() 또는 명령줄(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 또는 Tru64 UNIX Advanced File System은 1980년대 후반부터 1990년대 중반까지 디지털 이큅먼트 코퍼레이션이 자사의 OSF/1 버전 유닉스 운영체제(이후 Digital UNIX/Tru64 UNIX)를 위해 개발한 파일 시스템이다. 2008년 6월, GPL-2.0-only 라이선스 하에 자유 소프트웨어로 출시되었다. AdvFS는 다운타임으로부터의 빠른 복구가 필수적인 고가용성 시스템에서 사용되어 왔다.
AdvFS는 저장소 풀(파일 도메인이라 불림)과 논리 파일 시스템(파일 세트라 불림)이라는 상대적으로 발전된 개념을 사용한다. 파일 도메인은 파티션, LVM 또는 LSM 장치가 될 수 있는 여러 블록 장치로 구성된다. 파일 세트는 단일 파일 도메인 내에서 생성된 논리 파일 시스템이다. 관리자는 활성 파일 도메인에서 볼륨을 추가하거나 제거할 수 있으며, 제거 시 남은 파일 도메인에 충분한 공간이 있는 경우에 가능하다. 이는 제거될 디스크에 있는 모든 데이터나 메타데이터가 제거 전에 온라인으로 다른 디스크로 먼저 마이그레이션되어야 했기 때문에 구현하기 까다로운 초기 기능 중 하나였다.
파일 세트는 균형을 이룰 수 있으며, 이는 파일 세트의 파일 내용이 물리적 볼륨 전체에 걸쳐 균형을 이룰 수 있음을 의미한다. 파일 세트의 특정 파일은 사용 가능한 볼륨에 걸쳐 스트라이프될 수 있다.
관리자는 활성 또는 비활성 파일 세트의 스냅샷(또는 클론)을 찍을 수 있다. 이를 통해 쉬운 온라인 백업 및 편집이 가능하다.
또 다른 기능은 관리자가 활성 사용자가 있는 동안에도 파일 도메인에서 블록 장치를 추가하거나 제거할 수 있도록 한다. 이 추가/제거 기능을 통해 시스템 종료 없이 더 큰 장치로 마이그레이션하거나 잠재적으로 실패할 수 있는 하드웨어에서 마이그레이션할 수 있다.
주요 기능은 다음과 같다:
리눅스에서 AdvFS는 여러 파일에 대한 변경 사항을 원자적으로 커밋하기 위해 추가적인 ‘’syncv’’ 시스템 호출을 지원한다.
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" 스타일 복구 유틸리티 없이 로그 기반 복구를 출시할 만큼 충분한 자신감을 가졌다.
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(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는 1993년 IBM 알마덴 연구 센터의 연구 프로젝트인 타이거 샤크(Tiger Shark) 파일 시스템으로 시작되었다. 타이거 샤크는 처음에는 고속 멀티미디어 애플리케이션을 지원하도록 설계되었다. 이 설계는 과학 컴퓨팅에 잘 맞는 것으로 판명되었다.
또 다른 조상은 1992년부터 1995년 사이에 IBM 토마스 J. 왓슨 연구 센터의 연구 프로젝트로 개발된 IBM의 베스타(Vesta) 파일 시스템이다. 베스타는 고성능 멀티컴퓨터에 병렬 I/O 서브시스템이 실행되는 병렬 애플리케이션의 요구를 수용하기 위해 파일 파티셔닝 개념을 도입했다. 파티셔닝을 통해 파일은 바이트 시퀀스가 아니라 병렬로 접근할 수 있는 여러 개의 분리된 시퀀스이다. 파티셔닝은 파일 시스템을 호스팅하는 I/O 노드의 수와 유형을 추상화하고, I/O 노드 내의 물리적 데이터 분배와 관계없이 다양한 논리적으로 파티션된 파일 보기를 허용한다. 분리된 시퀀스는 병렬 애플리케이션의 개별 프로세스에 대응하도록 배열되어 확장성을 향상시킨다.
베스타는 1994년경 PIOFS 파일 시스템으로 상용화되었으며, 1998년경 GPFS가 그 뒤를 이었다. 이전 파일 시스템과 새로운 파일 시스템의 주요 차이점은 GPFS가 Vesta/PIOFS에서 제공하는 특수화된 API를 표준 유닉스 API로 대체했다는 점이다. 고성능 병렬 I/O를 지원하는 모든 기능은 사용자에게 숨겨져 백그라운드에서 구현되었다. GPFS는 또한 관련 제품인 IBM 멀티미디어 서버(IBM Multi-Media Server) 및 IBM 비디오 충전기(IBM Video Charger)와 많은 구성 요소를 공유하며, 이 때문에 많은 GPFS 유틸리티가 접두사 mm—멀티미디어(multi-media)로 시작한다.
2010년 IBM은 GPFS-SNC라는 기능을 포함한 GPFS 버전을 미리 선보였다. 여기서 SNC는 공유 없음 클러스터(Shared Nothing Cluster)를 의미한다. 이는 2012년 12월 GPFS 3.5와 함께 공식적으로 출시되었으며, 현재 FPO
(파일 배치 최적화기)로 알려져 있다.
이것은 클러스터 파일 시스템이다. 파일을 구성된 크기의 블록으로 나누고, 각 블록은 1메가바이트 미만이며, 여러 클러스터 노드에 분산된다.
이 시스템은 표준 블록 저장 볼륨에 데이터를 저장하지만, RAID 블록 저장 시스템과 매우 유사하게 중복성 및 병렬 접근을 위해 해당 볼륨을 가상화할 수 있는 내부 RAID 계층을 포함한다. 또한 상위 파일 수준에서 볼륨 간에 복제할 수 있는 기능도 있다.
아키텍처의 특징은 다음과 같다.
다른 기능으로는 고가용성, 이기종 클러스터에서의 사용 가능성, 재해 복구, 보안, DMAPI, HSM 및 ILM이 있다.
하둡 분산 파일 시스템(HDFS)과의 비교.
하둡의 HDFS 파일 시스템은 상품 하드웨어, 즉 RAID 디스크 및 스토리지 에어리어 네트워크(SAN)가 없는 데이터 센터에 유사하거나 더 많은 양의 데이터를 저장하도록 설계되었다.
정보 수명 주기 관리.
저장 풀은 파일 시스템 내에서 디스크를 그룹화할 수 있도록 한다. 관리자는 성능, 지역성 또는 신뢰성 특성을 기반으로 디스크를 그룹화하여 저장 계층을 만들 수 있다. 예를 들어, 한 풀은 고성능 파이버 채널 디스크일 수 있고 다른 풀은 더 경제적인 SATA 저장 장치일 수 있다.
파일셋(fileset)은 파일 시스템 이름 공간의 하위 트리이며, 이름 공간을 더 작고 관리하기 쉬운 단위로 분할하는 방법을 제공한다. 파일셋은 할당량을 설정하고 초기 데이터 배치 또는 데이터 마이그레이션을 제어하는 정책에 지정될 수 있는 관리 경계를 제공한다. 단일 파일셋의 데이터는 하나 이상의 저장 풀에 존재할 수 있다. 파일 데이터가 어디에 존재하고 어떻게 마이그레이션되는지는 사용자 정의 정책의 규칙 세트를 기반으로 한다.
두 가지 유형의 사용자 정의 정책이 있다: 파일 배치 및 파일 관리. 파일 배치 정책은 파일이 생성될 때 파일 데이터를 적절한 저장 풀로 보낸다. 파일 배치 규칙은 파일 이름, 사용자 이름 또는 파일셋과 같은 속성으로 선택된다. 파일 관리 정책은 파일 데이터를 이동하거나 복제하거나 파일을 삭제할 수 있도록 한다. 파일 관리 정책은 디렉터리 구조에서 파일의 위치를 변경하지 않고 데이터를 한 풀에서 다른 풀로 이동하는 데 사용될 수 있다. 파일 관리 정책은 마지막 접근 시간, 경로 이름 또는 파일 크기와 같은 파일 속성으로 결정된다.
정책 처리 엔진은 확장 가능하며 여러 노드에서 동시에 실행될 수 있다. 이를 통해 관리 정책을 수십억 개의 파일이 있는 단일 파일 시스템에 적용하고 몇 시간 내에 완료할 수 있다.
부산 동래읍성축제.
1995년 제1회 충렬제를 시작으로 31년 동안 이어져온 부산광역시 동래구의 대표적인 역사교육형 체험축제로, 올해는 '동래성 사람들, 역사와 미래를 잇다!'라는 새로운 슬로건으로 개최된다. 2025년 제31회 동래읍성역사축제는 새로운 시작을 위해 대표프로그램인 동래성전투재현 실경뮤지컬을 더욱 업그레이드하여 미디어아트와 접목한 퍼포먼스를 제공할 예정이며, 야외방탈출, 몰입형영상체험관 등 새로운 콘텐츠를 추가하여 10월 24일부터 10월 26일까지 5개 분야 51개 프로그램으로 구성될 예정이다.
주요프로그램.
동래성 전투재현 뮤지컬
[제1장 : 평 화] 평화로운 동래읍성
평화로운 동래의 모습
논밭을 가로 있는 농민들의 모습
풍물패들의 흥겨운 가락
노인들과 아이들의 행복한 모습
[제2장 : 잔 치] 송상현 부사의 부임잔치
송상현부사의 부임소식에 환호하는 백성
부사의 부임을 축하하기 위한 잔치의 준비
배우와 관객들이 어우러진 신나는 춤판
[제3장 : 침 략] 전령으로부터 전해진 왜군침략소식
전령으로부터 전쟁소식이 들려온다
혼란에 빠진 백성들
나라를 지킬지 도망을 갈지에 대한 의견이 분분하다.
[제4장 : 맹 세] 나라를 지키기 위한 조건없는 맹세
송상현 부사는 나라를 지키는 이유에 대해 노래한다.
송상현 부사에게 동화된 백성들은 나라에 대한 조건없는 맹세를 다짐한다.
동래성 전투 이야기.
임진년, 첫 전투지 ‘부산진성’이 함락되었다는 소식을 전해들은 경상좌병사(현재의 육군 부대장) 이각(李珏)은 송상현(宋象賢) 동래부사에게 모든 것을 떠넘기고 성문을 열고 도망갔다. 그래서 동래읍성은 고립무원의 상태에서 적의 대군을 맞아 격전을 벌일 수 밖에 없었다.
1592년 4월 14일 오후 왜군은 3개 부대로 나누어 “싸우려면 싸우고, 싸우지 않으려면 길을 빌려 달라.(戰則戰矣 不戰則假我道)”라는 문구가 새겨진 나무 팻말을 세우고 동래읍성 남문 앞으로 다가왔다. 이에 송 부사는 “싸워서 죽기는 쉬워도 길을 빌려주기는 어렵다.(戰死易假道難)”라는 글을 나무판자에 적어 적진에 던졌다.
15일 아침, 마침내 하늘을 가르는 왜군의 조총 소리와 함께 치열한 전투가 시작되었다. 공격 중심지는 남문이었다. 조선군은 남문을 중심으로 집결해 항전했으나, 시간이 갈수록 불리해지기 시작했다.
결국 왜군이 상대적으로 방어가 허술한 동북쪽 경사진 성벽을 무너뜨리고 성 안으로 밀어닥치자 성 안에서는 백병전(白兵戰)이 벌어졌다.
백성들은 낫, 괭이, 막대기 등을 들고 죽기로 싸웠지만 왜군의 병력에는 중과부적으로 동래읍성은 고을 백성들의 비명 소리가 넘쳐났다.
송 부사는 전세가 기운 것을 알고 갑옷 위에 관복을 입고 임금이 계신 북쪽으로 네 번 절한 뒤 부모님에게 올릴 글을 부채에 쓴 후 장렬히 최후를 맞이한다.
孤城月暈(고성월운) 외로운 성은 달무리처럼 포위되었는데
列鎭高枕(열진고침) 여러 다른 진영에서는 도와줄 기척이 없습니다.
君臣義重(군신의중) 임금과 신하의 의리가 무거우니
父子恩輕(부자은경) 부모와 자식의 은정을 가벼이 하오리다.
오시는 길.
시내버스로 오실 때
(명륜초등학교에서 하차) 110-1,110, 51, 49
(동래우체국에서 하차) 179, 50
지하철에서 마을버스환승
마을버스 6번 : 동래역(1호선 하차) → 복천박물관(행사장)
마을버스 7번 : 온천장역(1호선 하차) →동래문화회관(행사장)
남해고속도로 : 서부산 TG→동서고가도로→진양램프→하마정교차로→ 온천교사거리→동래문화원(행사장)
경부고속도로 : 구서 IC→중앙대로→오시게로→온천장입구→동래문화원(행사장)
축제셔틀버스
1코스 : 도시철도 1호선 동래역(3번출구) ↔ 축제장(동래문화회관 소극장 앞) ▸ 10분 간격
2코스 : 도시철도 4호선 명장역(3번 출구) → 축제장(복천박물관) → 명장역(3번 출구) → 온천천 카페거리(샤브향 온천천점)(하차)
2025.10.24.(금) 16:00~21:00
2025.10.25.(토)~10.26.(일) 10:00~21:00
동래구청 홈페이지 https://www.dongnae.go.kr/festival/index.dongnae
zswap은 가상 메모리 압축의 한 형태로, 스와프된 페이지를 위한 압축된 쓰기 저장(write-back) 캐시를 제공하는 리눅스 커널 기능이다. 메모리 페이지가 스와프 아웃될 때 스와프 장치로 이동하는 대신, zswap은 해당 페이지를 압축한 다음 시스템 RAM에 동적으로 할당된 메모리 풀에 저장한다. 실제 스와프 장치로의 쓰기 저장은 지연되거나 완전히 회피되어, 스와핑이 필요한 리눅스 시스템의 I/O를 크게 줄인다. 대신 압축을 수행하기 위해 추가적인 CPU 사이클이 필요하다.
I/O 감소의 결과로, zswap은 임베디드 장치, 넷북 및 유사한 저가형 하드웨어 장치를 포함한 다양한 플래시 메모리 기반 저장 장치를 사용하는 장치뿐만 아니라, SSD를 저장 장치로 사용하는 다른 장치에도 이점을 제공한다. 플래시 메모리는 쓰기 증폭으로 인해 수명이 제한적이므로, 이를 스와프 공간으로 사용하는 것을 피하면 빠르게 마모되는 것을 방지할 수 있다.
zswap은 스와프 공간으로 사용될 수 있는 다양한 유형의 스토리지를 추상화하는 리눅스 커널 메커니즘인 frontswap이 제공하는 API를 사용하여 리눅스 커널의 나머지 가상 메모리 서브시스템에 통합된다. 결과적으로 zswap은 내부적으로 유사-RAM 장치로 보이는 것을 제공하여 frontswap의 백엔드 드라이버로 작동한다. 즉, frontswap API는 zswap이 메모리 페이지가 스와프 아웃될 때 이를 가로채고, 이미 스와프된 페이지에 대한 페이지 부재를 가로챌 수 있게 한다. 이 두 경로에 대한 접근은 zswap이 스와프된 페이지를 위한 압축된 쓰기 저장 캐시 역할을 할 수 있도록 한다.
내부적으로 zswap은 리눅스 커널의 크립토 API가 제공하는 압축 적재 가능 커널 모듈을 사용한다. 이를 통해 예를 들어, 리눅스 커널이 지원하는 모든 하드웨어 압축 가속기를 사용하여 주 CPU에서 압축 작업을 오프로드할 수 있다. 원하는 압축 모듈 선택은 커널 부트 매개변수 값을 통해 부팅 시 동적으로 수행할 수 있다. 지정하지 않으면 Lempel–Ziv–Oberhumer (LZO) 압축이 선택된다. 리눅스 커널 버전 3.13부터는 커널 부트 매개변수 에 값 을 지정하여 zswap을 명시적으로 활성화해야 한다. 그러나 로 커널을 구성할 때 기본적으로 활성화되거나, sysfs 인터페이스를 통해 언제든지 활성화할 수 있다.
zswap이 사용하는 메모리 풀의 최대 크기는 sysfs 매개변수를 통해 구성할 수 있다. 이 매개변수는 풀이 차지할 수 있는 전체 시스템 RAM의 최대 비율을 지정한다. 메모리 풀은 구성된 최대 크기로 미리 할당되지 않고, 필요에 따라 증가하고 축소된다. 스와핑 결과로 구성된 최대 풀 크기에 도달하거나 메모리 부족 조건으로 인해 풀을 확장할 수 없을 때, 스와프된 페이지는 캐시 축출 기반으로 LRU 방식으로 메모리 풀에서 스와프 장치로 축출된다. 이 접근 방식은 zswap을 진정한 스와프 캐시로 만든다. 캐시가 가득 차면 가장 오래된 캐시된 페이지가 스와프 장치로 축출되어 새로운 스와프 페이지가 압축되고 캐시될 공간을 만든다.
zbud은 zswap이 압축된 페이지를 저장하기 위해 내부적으로 사용하는 특수 목적의 메모리 할당자이다. 이는 오라클의 zcache에서 사용되는 zbud 할당자를 재작성하여 구현되었다. zcache는 리눅스 커널을 위한 또 다른 가상 메모리 압축 구현이다. 내부적으로 zbud는 물리적 메모리 페이지당 최대 두 개의 압축된 페이지("버디", 따라서 할당자 이름)를 저장하여, 해제된 공간의 쉬운 통합 및 재사용으로 인한 이점과 낮은 메모리 활용 가능성으로 인한 단점을 모두 가져온다. 그러나 설계 결과로 zbud는 원래 압축되지 않은 페이지가 차지했을 것보다 더 많은 메모리 공간을 할당할 수 없다.
zswap과 zbud는 모두 세스 제닝스(Seth Jennings)가 만들었다. 첫 공개 발표는 2012년 12월이었고, 개발은 2013년 5월까지 계속되어 코드베이스가 실험적 커널 기능 상태였음에도 불구하고 성숙 단계에 도달했다.
zswap (zbud와 함께)은 2013년 9월 2일에 출시된 커널 버전 3.11에서 리눅스 커널 메인라인에 병합되었다.
2014년 6월 8일에 출시된 리눅스 커널 버전 3.15부터 zswap은 여러 스와프 장치를 제대로 지원한다.
2024년 3월 11일에 출시된 리눅스 커널 버전 6.8부터 zswap은 특정 cgroup에 대한 쓰기 저장을 비활성화하는 것을 지원한다.
zswap의 대안 중 하나는 zram으로, 리눅스 커널에 유사하지만 여전히 다른 "RAM에 압축된 페이지 스와프" 메커니즘을 제공한다.
주요 차이점은 zram이 데이터를 저장하기 위해 RAM을 사용하여 압축된 블록 장치를 제공한다는 점이다. 이는 일반적이고 별개의 스와프 장치 역할을 한다.
이에 비해 zswap은 스와프 장치를 위한 RAM 기반 캐시 역할을 한다. 이는 zswap에 덜 사용된 스와프 페이지에 대한 캐시 축출 메커니즘을 제공하는데, zram은 커널 버전 4.14에서 이 도입되기 전까지는 이 기능이 없었다. 하지만 설계상 zswap을 사용하려면 이미 존재하는 스와프 장치가 적어도 하나 필요하다.
ISACA(정식 명칭: 정보 시스템 감사 및 통제 협회, Information Systems Audit and Control Association)는 IT 거버넌스에 중점을 둔 국제 전문 협회이다.
ISACA는 현재 8개의 인증 프로그램과 기타 마이크로 인증을 제공한다.
ISACA는 1967년 미국에서 컴퓨터 시스템의 감사 통제 업무를 수행하는 일단의 사람들이 조직 운영에 대해 점점 더 비판적인 입장을 취하면서 시작되었다. 그들은 이 분야에서 정보와 지침을 제공할 중앙 집중식 자료원의 필요성을 인식했다. 1969년, (나중에) 더글러스 에어크래프트의 직원이었던 스튜어트 타이르나우어(Stuart Tyrnauer)는 이 그룹을 EDP 감사 협회(EDPAA)로 통합했다. 타이르나우어는 처음 3년 동안 이 기구의 창립 회장을 역임했다. 1976년 이 협회는 정보기술 거버넌스 및 통제 분야에 대한 지식과 가치를 확대하기 위한 대규모 연구 노력을 수행하기 위해 교육 재단을 설립했다.
이 협회는 1994년에 정보 시스템 감사 및 통제 협회로 명칭을 변경했다.
2008년 기준으로 이 조직은 긴 이름을 버리고 자신을 ISACA로 브랜딩했다.
2016년 3월, ISACA는 능력 성숙도 통합 모델을 개발한 CMMI 연구소를 인수했다.
2020년 1월, ISACA는 새로운 로고를 도입하며 외관과 디지털 존재를 업데이트하고 새로 단장했다.
ISACA는 현재 180개 이상의 국가에서 185,000명 이상의 회원(ISACA 인증을 보유한 회원 및 전문가)에게 서비스를 제공하고 있다. 회원의 직함은 IS 감사자, 컨설턴트, 교육자, IS 보안 전문가, 규제 기관, 최고 정보 책임자, 최고 정보 보안 책임자 및 내부감사원 등이다. 그들은 거의 모든 산업 분야에서 일한다. 180개국 이상에 225개 이상의 지부가 설립된 ISACA 지부 네트워크가 있다. 지부는 교육, 자원 공유, 옹호, 네트워킹 및 기타 혜택을 제공한다.
ISACA의 첫 번째 사이버 보안 인증인 CSX-P는 2015년 여름에 도입되었다. 이는 개인이 실제 문제와 함께 실제 환경에서 작업해야만 인증을 얻을 수 있는 몇 안 되는 인증 중 하나이다. 특히, 이 시험은 응시자를 실제 사건이 발생하고 있는 라이브 네트워크에 배치한다. 사건에 대응하고 문제를 해결하려는 학생의 노력은 부여되는 점수의 유형으로 이어진다.
readahead(리드어헤드)는 리눅스 커널의 시스템 호출로, 파일 내용을 버퍼 캐시에 로드한다. 이는 파일을 프리페칭하여 나중에 접근할 때 내용이 하드 디스크 드라이브 (HDD) 대신 주 기억 장치 (RAM)에서 읽혀 파일 접근 지연 시간을 훨씬 낮춘다.
많은 리눅스 배포판은 일반적으로 사용되는 파일 목록에 readahead를 사용하여 부팅 속도를 높인다. 이러한 설정에서 커널이 부트 파라미터로 부팅되면, 부팅 중 모든 파일 접근을 기록하고 나중 부팅 시퀀스에서 읽을 새 파일 목록을 작성한다. 이는 기본 readahead 목록에 포함되지 않은 추가 설치된 서비스가 더 빨리 시작되도록 할 것이다.
Systemd를 사용하는 리눅스 배포판에서는 (부팅 시퀀스의 일부로) readahead 바이너리가 systemd-readahead로 대체되었다. 그러나 systemd 버전 217에서 readahead 지원이 제거되었으며, 유지 관리되지 않고 예상 성능 이점을 제공할 수 없다고 설명되었다.
특정 실험적인 페이지 수준 프리페칭 시스템이 성능을 더욱 향상시키기 위해 개발되었다.
브레인 퍽 스케줄러(Brain Fuck Scheduler, BFS)는 2009년 8월 리눅스 커널용으로 설계된 프로세스 스케줄러로, 가장 빠른 적격 가상 마감일 우선 스케줄링 (EEVDF)을 기반으로 하며, 컴플리틀리 페어 스케줄러 (CFS) 및 O(1) 스케줄러의 대안으로 개발되었다. BFS는 콘 콜리바스가 만들었다.
BFS의 목표는 다른 스케줄러와 비교하여, 특정 유형의 컴퓨테이션 작업 부하에 대한 성능을 맞추기 위해 휴리스틱 이론 조정이나 매개변수 튜닝이 필요 없는 더 간단한 알고리즘을 가진 스케줄러를 제공하는 것이다. 콜리바스는 이러한 튜닝 매개변수가 일반 사용자가 이해하기 어렵다고 주장했으며, 특히 여러 매개변수 간의 상호작용 측면에서 더욱 그러하다고 했다. 또한 이러한 튜닝 매개변수를 사용하면 특정 대상 컴퓨테이션 유형에서 성능이 향상될 수 있지만, 일반적인 경우에는 성능이 저하될 수 있다고 주장했다. BFS는 16개 미만의 CPU 코어를 가진 리눅스 데스크톱 컴퓨터에서 응답성을 향상시키는 것으로 보고되었다.
도입 직후, 새로운 스케줄러는 리눅스 커뮤니티에서 슬래시닷에 보도되었으며, 리눅스 매거진과 리눅스 프로 매거진에 리뷰가 실리면서 큰 화제가 되었다. 성능과 응답성이 향상되었다는 다양한 평가가 있었지만, 콘 콜리바스는 BFS를 메인라인 커널에 통합할 의도가 없었다.
"브레인 퍽 스케줄러"라는 이름은 의도적으로 도발적인데, 당시 기존 리눅스 프로세스 스케줄러의 복잡성에 대한 좌절감을 표현하기 위해 창시자 콘 콜리바스가 선택했다. 콜리바스는 컴플리틀리 페어 스케줄러 (CFS)와 같은 다른 스케줄러에서 튜닝 가능한 매개변수와 휴리스틱 기반 설계가 확산되면서 비전문가가 이해하거나 최적화하기 어렵다는 점을 강조하고자 했다. 이와 대조적으로 BFS는 사용자 수준의 구성 없이 데스크톱 상호작용성과 응답성 향상을 목표로 단순성과 예측 가능성을 염두에 두고 설계되었다.
이론적 설계 및 효율성.
2009년 BFS가 도입되었고, 원래 이중 연결 리스트 자료 구조를 사용했지만, 이 자료 구조는 선입 선출 (FIFO) 큐처럼 취급된다. 작업 삽입은 이다. 다음 작업을 실행하기 위한 작업 검색은 최악의 경우 이다. 모든 CPU가 사용하는 단일 전역 실행 큐를 사용한다. 스케줄링 우선순위가 높은 작업이 먼저 실행된다. 실시간 및 등시성 우선순위 클래스를 제외한 모든 정책에서 작업은 가상 마감일 공식에 따라 정렬(또는 배포)되고 선택된다.
실행 동작은 라운드 로빈 스케줄링의 가중 변형이며, 특히 등시성 정책 미만에서 작업이 동일한 우선순위를 가질 때 더욱 그렇다. 사용자 튜닝 가능한 라운드 로빈 간격(타임 슬라이스)은 기본적으로 6밀리초로, 이는 사람이 감지할 수 없는 최소한의 지터로 선택되었다. 콜리바스는 6ms 미만은 무의미하고, 라운드 로빈 타임슬라이스에 대해 300ms 이상은 처리량 측면에서 무익하다고 주장했다. 이 중요한 튜닝 가능 값은 처리량과 지연 시간 사이의 절충안으로 라운드 로빈 스케줄러를 맞춤 설정할 수 있다. 모든 작업은 실시간 FIFO를 제외하고 동일한 타임 슬라이스를 받는데, 이는 무한한 타임 슬라이스를 가진다고 가정된다.
콜리바스는 RDSL 스케줄러에서 사용했던 CPU당 다중 실행 큐(라운드 로빈) 우선순위 배열 대신 이중 연결 리스트 단일 실행 큐를 선택한 이유를 설명했다. 이는 다중 CPU 시나리오에서 공정성을 완화하고, 다중 실행 큐 시나리오에서 각 실행 큐가 자체 지연 시간과 태스크 공정성을 유지해야 하는 복잡성을 제거하기 위함이었다. 그는 MuQSS의 나중 버전에서는 BFS가 확정적인 지연 시간을 보장한다고 주장했다. 그는 또한 CPU가 증가함에 따른 잠금 경합 문제(태스크 노드 데이터 변경, 제거, 생성과 관련됨)와 다음 태스크 실행 조회를 위한 오버헤드를 인식했다. MuQSS는 이러한 문제를 해결하려고 시도했다.
콜리바스는 나중에 2016년 BFS v0.480 릴리스에서 설계를 스킵 리스트로 변경했다. 이로 인해 스케줄러의 효율성이 변경되었다. 그는 태스크 삽입, 태스크 조회, 일 때 태스크 제거를 언급했다.
가상 마감일.
가상 마감일 공식은 현재 시간(niffy 단위 또는 내부 커널 시간 카운터인 나노초 jiffies)에 의해 상쇄된 nice 수준에 따라 스케일링된 라운드 로빈 타임슬라이스인 미래 마감 시간이다. 가상 마감일은 순서만 제안할 뿐, 태스크가 미래에 스케줄링된 niffy에 정확히 실행될 것이라고 보장하지는 않는다.
먼저 prio 비율 조회 테이블이 생성된다. 이는 재귀 수열을 기반으로 한다. 각 nice 수준마다 10%씩 증가한다. 그래프로 그리면 포물선 패턴을 따르며, niced 태스크는 도메인으로 0에서 39(가장 높은 nice 우선순위부터 가장 낮은 nice 우선순위에 해당)까지, 범위로 128에서 5089까지 이동하는 제곱 함수로 분포된다. 이동 부분은 콜리바스가 언급한 가상 마감일 공식의 변수에서 비롯된다.
태스크의 nice-투-인덱스 매핑 함수 는 nice −20...19를 인덱스 0...39로 매핑하여 prio 비율 조회 테이블의 입력으로 사용된다. 이 매핑 함수는 커널 헤더의 sched.h에 있는 매크로이다. 내부 커널 구현은 100에서 140 사이의 정적 우선순위 범위에서 약간 다르지만, 사용자들은 이를 −20...19 nice로 보게 된다.
가상 마감일은 이 정확한 공식에 기반한다:
또는 다음과 같이 표현될 수 있다.
여기서 는 nice 과 현재 시간 (niffy 단위)의 함수로 u64 정수 나노초 단위의 가상 마감일이며, 는 인덱스의 함수로 prio 비율 테이블 조회, 은 태스크의 nice-투-인덱스 매핑 함수, 는 밀리초 단위의 라운드 로빈 타임슬라이스, 은 formula_1의 변환 계수를 나노초 단위의 1밀리초로 근사화한 지연 감소 상수로, 콜리바스는 그 규모와 비슷한 2의 거듭제곱 상수 을 사용한다. 값이 작을수록 가상 마감일이 빨라지며, 이는 음의 nice 값에 해당한다. 값이 클수록 가상 마감일이 뒤로 밀리며, 이는 양의 nice 값에 해당한다. 타임슬라이스가 만료될 때마다 이 공식을 사용한다.
2진수 128은 10진수 100에 해당하며, 이는 "의사 100"일 가능성이 있다. 2진수 115는 10진수 90에 해당한다. 콜리바스는 "빠른 시프트"를 위해 128을 사용하는데, 이는 나눗셈이 2진수 오른쪽 시프트인 경우이다.
스케줄링 정책.
BFS는 CPU 작업에 허용되는 태스크의 양을 결정하기 위해 스케줄링 정책을 사용한다. BFS는 최상위부터 최하위까지 4가지 스케줄링 계층(스케줄링 정책 또는 스케줄링 클래스라고 함)을 사용하여 태스크를 선택하는 방식을 결정하며, 최상위 계층의 태스크가 먼저 실행된다.