hotchpotch/wikipedia-multilingual-ir-pairs huggingface dataset:
라틴어의 격 변화 형용사
일부 제1변화 및 제2변화 형용사의 남성형은 -er로 끝난다. 제2변화 -r 명사와 마찬가지로 일부 형용사는 굴절 내내 e를 유지하고, 일부는 e를 생략한다. Sacer, sacra, sacrum는 e를 생략하는 반면 miser, misera, miserum는 e를 유지한다.
아홉 개의 제1, 제2변화 대명사 형용사는 모든 성별에서 속격과 여격 단수가 불규칙하다. 이들은 ūnus nauta라는 니모닉을 사용하여 기억할 수 있다. 다음은 그 형용사들이다.
제3변화 형용사는 일반적으로 제3변화 i-어간 명사처럼 곡용되지만, 탈격 단수에서 -e 대신 -ī를 가진다는 점이 다르다(i-어간 명사의 경우 순수 i-어간만 -ī를 가짐). 그러나 일부 형용사, 예를 들어 한 어미를 가진 vetus, veteris ('늙은, 나이든')는 탈격 단수에서 -e, 속격 복수에서 -um, 주격 및 대격 중성 복수에서 -a를 가진다.
이들은 모든 성별에 대해 단 하나의 주격 어미를 가지지만, 다른 격의 어미는 평소와 같이 다양하다. 명사와 마찬가지로 굴절을 보여주기 위해 속격이 주어진다.
라틴어의 격 변화 형용사
두 어미를 가진 제3변화 형용사는 남성과 여성에 대한 한 가지 형태와 중성에 대한 별도의 형태를 가진다. 남성과 여성에 대한 어미는 -is이며, 중성에 대한 어미는 -e이다. 속격은 주격 남성 단수와 동일하므로 속격을 명시할 필요는 없다.
세 어미를 가진 제3변화 형용사는 세 가지 성별 모두에 대해 세 가지 별도의 주격 형태를 가진다. 제3변화 및 제2변화 -r 명사와 마찬가지로 남성형은 -er로 끝난다. 여성형은 -ris로, 중성형은 -re로 끝난다. 속격은 주격 여성 단수와 동일하다.
영어와 마찬가지로 형용사도 최상급과 비교급 형태를 가진다. 규칙적인 제1, 제2변화 및 한두 어미를 가진 제3변화 형용사의 경우, 비교급은 어간에 남성과 여성은 -ior를, 중성은 -ius를 추가하여 형성된다. 둘 다 속격은 -iōris를 추가하여 형성된다. 따라서 이들은 제3변화로 곡용되지만, i-어간으로 곡용되지는 않는다. 최상급은 어간에 -issimus, -issima, -issimum을 추가하여 형성되며, 따라서 제1, 제2변화 형용사처럼 곡용된다.
라틴어의 격 변화 형용사
남성 주격 단수 형태가 -er로 끝나는 형용사(제1, 제2, 제3변화 모두)는 약간 다르다. 일반 형용사와 마찬가지로 비교급은 어간에 -ior를 추가하여 형성되지만, 최상급의 경우 주격 남성 단수에 -rimus를 추가한다.
남성-여성 주격 단수에서 -lis로 끝나는 두 어미를 가진 일부 제3변화 형용사는 불규칙 최상급 형태를 가진다. 다음은 그러한 유일한 형용사들이다.
-eus 또는 -ius로 끝나는 제1, 제2변화 형용사는 어미를 취하여 비교급과 최상급을 형성하지 않는다는 점에서 특이하다. 대신, magnoperē ('많이, 크게')의 비교급과 최상급인 magis ('더')와 maximē ('가장')를 각각 사용한다.
-quus 또는 -guus로 끝나지 않는 많은 -uus 형용사도 이 규칙을 따른다.
대부분의 언어와 마찬가지로 라틴어에도 불규칙 비교급과 최상급을 가진 형용사가 있다.
라틴어의 격 변화 수사
라틴어에는 여러 종류의 수사가 있다. 가장 흔한 두 가지는 기수와 서수이다. 또한 배수사나 부사 수사와 같이 더 희귀한 수사들도 있다.
모든 기수사는 곡용되지 않지만, ūnus('하나'), duo('둘'), trēs('셋'), 복수 백단위 ducentī('이백'), trecentī('삼백') 등과 mīlle('천')는 형용사처럼 격과 성을 가진다. Ūnus, ūna, ūnum은 속격에서 -īus 또는 -ius, 여격에서 -ī를 가지는 제1-2변화 대명사처럼 곡용된다. Duo는 불규칙하게 곡용되며, trēs는 제3변화 복수 형용사처럼 곡용되고, -centī('백') 수사는 제1-2변화 형용사처럼 곡용되며, mīlle는 단수에서 불변하고 복수에서는 제3변화 i-어간 중성 명사처럼 곡용된다.
ūnus의 복수형 어미는 plūrālia tantum 명사와 함께 사용된다. 예를 들어, ūna castra (하나의 [군사] 캠프), ūnae scālae (하나의 사다리).
라틴어의 격 변화 수사
ambō ('둘 다')라는 단어는 duo처럼 곡용되지만, o가 길다는 점이 다르다. 두 곡용 모두 라틴어에서는 폐기된 인도유럽조어 쌍수에서 유래하며, 복수형이 아니다.
수사 centum('백')은 곡용되지 않지만, 다른 모든 백 단위 수사들은 곡용된다(ducentī, trecentī, quadringentī, quīngentī, sescentī, septingentī, octingentī, nōngentī).
단어 mīlle '천'은 단수 불변 형용사이다. 그러나 그 복수형인 mīlia는 복수 제3변화 i-어간 중성 명사이다. "네 마리의 말"을 라틴어로 쓰려면 속격을 사용한다. quattuor mīlia equōrum, 문자 그대로 "네 개의 말의 천".
나머지 숫자들은 형용사나 명사로 사용될 때 모두 곡용되지 않는다.
라틴어 수사의 다양한 종류에 대한 자세한 정보는 라틴어 수사 (언어학)을 참조한다.
라틴어의 격 변화 부사 및 그 비교급과 최상급
부사는 곡용되지 않는다. 그러나 형용사를 부사로 만들려면 부사를 형성해야 한다.
제1, 제2변화 형용사의 부사는 어간에 -ē를 추가하여 형성된다.
일반적으로 제3변화 형용사의 부사는 어간에 -iter를 추가하여 형성된다. 그러나 한 가지 어미를 가진 대부분의 제3변화 형용사는 단순히 어간에 -er를 추가한다.
부사의 비교급 형태는 해당 비교급 형용사의 주격 중성 단수와 동일하다. 부사의 최상급 형태는 해당 최상급 형용사에 규칙 어미 -ē를 붙여서 간단하게 형성된다. 해당 형용사 형태와 마찬가지로, -eus 또는 -ius로 끝나는 제1, 제2변화 형용사는 별도의 어미 대신 magis와 maximē를 사용한다.
형용사와 마찬가지로 라틴어에도 불규칙 비교급과 최상급 형태를 가진 부사가 있다.
라틴어의 격 변화 곡용 내 특이성
일부 명사는 단수로만 사용된다(단수고유명사) 예:
일부 명사는 복수로만 사용되거나(plurale tantum) 복수일 때 단수 의미를 가진다. 예:
불변 명사는 모든 단수 격에서 형태가 하나뿐인 명사이다.
이종 명사는 성별에 따라 달라지는 명사이다.
SquashFS
Squashfs는 리눅스용 압축된 읽기 전용 파일 시스템이다. Squashfs는 파일, 아이노드 및 디렉터리를 압축하며, 더 나은 압축을 위해 4 KiB에서 최대 1 MiB까지의 블록 크기를 지원한다. 여러 압축 알고리즘이 지원된다. Squashfs는 Squashfs 파일 시스템에 접근하기 위한 GPL에 따라 라이선스된 자유 소프트웨어의 이름이기도 하다.
Squashfs는 일반적인 읽기 전용 파일 시스템 사용과 낮은 오버헤드가 필요한 제한된 블록 장치 기억 장치 시스템(예: 임베디드 시스템)에 사용하도록 고안되었다.
SquashFS 용례
Squashfs는 아치 리눅스, 클론질라, 데비안, 페도라, 젠투 리눅스, KDE 네온, 칼리 리눅스, 리눅스 민트, NixOS, Salix, 우분투, 오픈수세의 라이브 CD 버전과 OpenWrt 및 DD-WRT 라우터 펌웨어와 같은 임베디드 배포판에서 사용된다. 또한 크롬캐스트, 타이니 코어 리눅스에서 확장 기능 패키징을 위해, 일부 안드로이드 릴리스(안드로이드 누가)의 시스템 파티션에도 사용된다. 일반적으로 유니언FS, Overlayfs 또는 aufs와 같은 유니언 마운트 파일 시스템과 결합하여 라이브 리눅스 배포판을 위한 읽기-쓰기 환경을 제공한다. 이는 Squashfs의 고속 압축 기능과 라이브 CD에서 실행하는 동안 배포판을 변경할 수 있는 기능을 모두 활용한다. 데비안 라이브, Mandriva One, 퍼피 리눅스, Salix 라이브 및 SLAX와 같은 배포판은 이 조합을 사용한다. 휴대용 리눅스 애플리케이션 생성을 목표로 하는 앱이미지 프로젝트는 AppImage 생성을 위해 Squashfs를 사용한다. 스냅 패키지 시스템도 Squashfs를 파일 컨테이너 형식으로 사용한다.
SquashFS 용례
Squashfs는 리눅스 터미널 서버 프로젝트 및 Splashtop에서도 사용된다. unsquashfs 및 mksquashfs 도구는 윈도우 NT – 윈도우 8.1로 포팅되었다. 7-Zip도 Squashfs를 지원한다.
SquashFS 역사
Squashfs는 초기에 비정규 리눅스 패치로 유지보수되었다. 초기 버전 1.0은 2002년 10월 23일에 출시되었다. 2009년 Squashfs는 리눅스 2.6.29의 일부로 리눅스 메인라인에 통합되었다. 이 과정에서 이전 형식에 대한 하위 호환성 코드가 제거되었다. 그 이후로 Squashfs 커널 공간 코드는 리눅스 메인라인 트리에 유지보수되었으며, 사용자 공간 도구는 프로젝트의 깃허브 페이지에 남아있다.
Squashfs의 원래 버전은 Gzip 압축을 사용했지만, 리눅스 커널 2.6.34는 LZMA 및 LZO 압축을 지원했고, 리눅스 커널 2.6.38은 xz에서 사용되는 LZMA2 압축을 지원했고, 리눅스 커널 3.19는 LZ4 압축을 지원했으며, 리눅스 커널 4.14는 Zstandard 압축을 지원했다.
리눅스 커널 2.6.35는 확장 파일 속성을 지원했다.
YAFFS
YAFFS(Yet Another Flash File System)는 찰스 매닝이 Aleph One사를 위해 설계하고 작성한 파일 시스템이다.
YAFFS1은 이 파일 시스템의 첫 번째 버전으로, 당시의 512 바이트 페이지 크기(+ 16 바이트 여유(OOB; Out-Of-Band) 영역)를 가진 NAND 칩을 위해 설계되었다. 작업은 2002년에 시작되어 그해 말에 처음 출시되었다. 초기 작업은 Toby Churchill Ltd와 Brightstar Engineering의 후원을 받았다.
이러한 구형 칩은 일반적으로 페이지당 2~3회 쓰기 주기를 허용한다. YAFFS는 이를 활용하여 특정 예비 영역 바이트에 써서 더티 페이지를 표시한다. 최신 NAND 플래시 칩은 페이지 크기가 더 커졌는데, 처음에는 2K 페이지(+ 64 바이트 OOB), 나중에는 4K 페이지가 되었으며, 더 엄격한 쓰기 요구 사항이 적용되었다. 소거 블록(128킬로바이트) 내의 각 페이지는 순차적으로 기록되어야 하며, 각 페이지는 한 번만 기록되어야 한다.
YAFFS
"한 번 쓰기 규칙"("write once property")을 강제하는 스토리지 시스템을 설계하는 것은 몇 가지 장점이 있다.
YAFFS2는 이러한 최신 칩들을 수용하기 위해 설계되었다. 이는 YAFFS1 소스 코드를 기반으로 하며, 주요 차이점은 내부 구조가 512바이트 크기로 고정되어 있지 않고, 각 기록된 페이지에 블록 시퀀스 번호가 부여된다는 점이다. 이런 방식으로 이전 페이지는 "한 번 쓰기" 규칙을 위반하지 않고 논리적으로 덮어쓸 수 있다. 2003년 말에 출시되었다.
YAFFS
YAFFS는 데이터 무결성을 최우선으로 하는 견고한 로그 구조화 파일 시스템이다. YAFFS의 보조 목표는 고성능이다. YAFFS는 일반적으로 대부분의 대안보다 뛰어난 성능을 보인다. 또한 이식성을 고려하여 설계되었으며 리눅스, WinCE, pSOS, RTEMS, eCos, ThreadX 및 다양한 특수 목적 운영 체제에서 사용되었다. 'YAFFS/Direct' 변형은 운영 체제가 없거나 임베디드 운영 체제 또는 부트로더가 있는 상황에서 사용된다. 이 변형은 동일한 코어 파일 시스템을 가지고 있지만 상위 및 하위 수준 코드와 NAND 플래시 하드웨어 모두에 대한 인터페이스가 더 간단하다.
YAFFS 코드베이스는 GPL과 Aleph One에서 제공하는 제품별 라이선스 모두로 라이선스가 부여된다.
YAFFS는 높은 수준에서 파티션별로 잠겨 있어 한 번에 하나의 스레드만 쓸 수 있다.
YAFFS YAFFS1
YAFFS 파일 시스템을 초기화하는 특별한 절차는 플래시 메모리를 단순히 지우는 것 외에는 없다. 불량 블록이 발생하면 YAFFS는 스마트 미디어 방식에 따라 블록의 여유 영역에서 다섯 번째 바이트를 표시한다. 이렇게 표시된 블록은 그 이후로 할당되지 않은 상태로 유지된다.
파일 데이터를 쓰기 위해 YAFFS는 처음에 파일 메타데이터(예: 타임스탬프, 이름, 경로 등)를 설명하는 전체 페이지(YAFFS 용어로는 청크)를 쓴다. 새 파일에는 고유한 개체 ID 번호가 할당되며, 파일 내의 모든 데이터 청크에는 여유 영역 내에 이 고유한 개체 ID가 포함된다. YAFFS는 이러한 청크의 물리적 위치에 대한 RAM의 트리 구조를 유지 관리한다. 청크가 더 이상 유효하지 않으면(파일이 삭제되거나 파일의 일부가 덮어쓰여진 경우) YAFFS는 청크의 여유 영역에 있는 특정 바이트를 '더티'로 표시한다. 전체 블록(32페이지)이 더티로 표시되면 YAFFS는 블록을 지우고 공간을 회수할 수 있다. 파일 시스템의 여유 공간이 부족하면 YAFFS는 유효한 페이지 그룹을 새 블록으로 통합한다. 그런 다음 YAFFS는 원래 블록 내의 더티 페이지가 사용하던 공간을 회수한다.
YAFFS YAFFS1
YAFFS 시스템이 마운트할 때 NAND 플래시 장치는 여유 영역을 스캔하여 유효한 데이터를 확인하기 위해 각 블록을 방문해야 한다. 이 정보를 사용하여 메모리 상주 트리 데이터 구조를 재구성한다.
YAFFS YAFFS2
YAFFS2는 YAFFS1과 개념이 유사하며 많은 코드를 공유한다. YAFFS2 코드베이스는 하위 호환성을 통해 YAFFS1 데이터 형식을 지원한다. 주요 차이점은 YAFFS2가 최신 NAND 플래시의 "한 번 쓰기" 요구 사항을 충족하기 위해 상당한 노력을 기울여야 한다는 점이다.
YAFFS YAFFS2
YAFFS2는 새로 쓰여진 모든 블록에 단조 증가하는 시퀀스 번호를 표시한다. 청크의 시퀀스는 블록 시퀀스 번호와 블록 내 청크 오프셋으로부터 추론할 수 있다. 따라서 YAFFS2가 플래시를 스캔하여 동일한 ObjectIDs 및 ChunkNumbers를 가진 여러 청크를 감지할 때, 가장 큰 시퀀스 번호를 취하여 사용할 청크를 선택할 수 있다. 효율성을 위해 YAFFS2는 축소 헤더(shrink header) 개념도 도입한다. 예를 들어, 파일 크기가 더 작게 조정될 때 YAFFS1은 영향을 받는 모든 청크를 더티로 표시하지만 YAFFS2는 "한 번 쓰기" 규칙 때문에 그렇게 할 수 없다. 대신 YAFFS2는 특정 수의 페이지가 그 시점 이전에 유효하지 않음을 나타내는 "축소 헤더"를 쓴다. 이를 통해 YAFFS2는 시스템이 재부팅될 때 파일 시스템의 최종 상태를 재구성할 수 있다.
YAFFS2는 NAND 플래시에 대한 보다 추상적인 정의를 사용하여 다양한 지오메트리, 불량 블록 처리 규칙 등을 가진 더 넓은 범위의 플래시 부품과 함께 사용할 수 있도록 한다.
YAFFS2는 나중에 체크포인팅 지원을 추가했는데, 이는 일반적인 마운트 스캔을 우회하여 매우 빠른 마운트 시간을 가능하게 한다. 성능은 달라질 수 있지만, 2 GB의 경우 3초의 마운트 시간이 보고된 바 있다.
미닉스 파일 시스템
미닉스 파일 시스템(MINIX file system)은 미닉스 운영체제의 기본 파일 시스템이다. 1980년대 앤드루 타넨바움이 작성했으며, 복잡한 기능을 생략하면서 유닉스 파일 시스템의 구조를 복제하여 교육용으로 활용될 목적이었다. 1994년까지는 Ext2와 같은 다른 파일 시스템의 인기로 인해 리눅스 사용자들 사이에서 인기가 줄어들었으며, 제한된 파티션 크기와 파일 이름 길이 제한 등 기능 부족이 원인이었다.
미닉스 파일 시스템 역사
MINIX는 1980년대 앤드루 타넨바움에 의해 교육에서 자유롭게 사용할 수 있는 유닉스 계열 운영체제로 작성되었다. MINIX 파일 시스템은 MINIX와 함께 사용하도록 설계되었으며, 유닉스 파일 시스템의 기본 구조를 복사했지만 MINIX의 전반적인 목표인 유용한 교육 보조 도구가 되기 위해 소스 코드를 깨끗하고 명확하며 간단하게 유지하기 위해 복잡한 기능은 피했다.
미닉스 파일 시스템 역사
리누스 토르발스가 처음으로 리눅스 운영체제 커널 (1991년)을 작성하기 시작했을 때, 그는 MINIX를 실행하는 컴퓨터에서 작업했으며, MINIX의 파일 시스템 레이아웃을 채택했다. 그러나 이는 곧 문제가 되었다. MINIX는 파일 이름 길이를 14자(이후 버전에서는 30자)로 제한했고, 파티션을 64메가바이트로 제한했으며, 파일 시스템이 성능이 아닌 교육 목적으로 설계되었기 때문이다. MINIX 파일 시스템의 리눅스 구현은 멀티스레드였지만, MINIX의 파일 시스템 구현은 단일 스레드였다. 확장 파일 시스템 (ext; 1992년 4월)은 MINIX의 것을 대체하기 위해 개발되었지만, 이의 두 번째 버전인 Ext2가 출시된 후에야 리눅스는 상업용 파일 시스템을 얻게 되었다. 1994년 기준으로, MINIX 파일 시스템은 리눅스 사용자들 사이에서 "거의 사용되지 않았다".
미닉스 파일 시스템 설계 및 구현
MINIX 파일 시스템은 여섯 가지 구성 요소를 갖는다.
아이노드 영역이다. 각 파일 또는 디렉토리는 아이노드로 표현되며, 유형(파일, 디렉토리, 블록, 문자, 파이프), 사용자 및 그룹 ID, 마지막 접근, 마지막 수정, 마지막 상태 변경 날짜 및 시간을 기록하는 세 가지 타임스탬프를 포함한 메타데이터를 기록한다. 아이노드는 또한 파일 또는 디렉토리 데이터가 실제로 저장되는 데이터 영역의 영역을 가리키는 주소 목록을 포함한다.
Bcachefs
Bcachefs는 리눅스 기반 운영체제를 위한 카피 온 라이트(COW) 파일 시스템이다. 주요 개발자인 켄트 오버스트리트가 2015년에 처음 발표했으며, 리눅스 커널 6.7부터 리눅스 커널에 추가되었다. 이는 ZFS 또는 Btrfs의 최신 기능과 경쟁하기 위해 만들어졌다. 2025년 6월, 리누스 토르발스는 커널 개발 가이드라인을 반복적으로 위반한 결과 bcachefs가 커널에서 제거될 것이라고 발표했다. 2025년 8월, bcachefs의 상태는 '지원됨'에서 '외부에서 유지 관리됨'으로 변경되었다.
2025년 9월 말, 리누스 토르발스는 리눅스 커널 버전 6.17부터 모든 Bcachefs 코드를 제거했다. 이제 외부 모듈로 사용할 수 있다.
Bcachefs 특징
Bcachefs는 리눅스 기반 운영체제를 위한 카피 온 라이트(COW) 파일 시스템이다. 특징으로는 캐싱, ChaCha20 및 Poly1305 알고리즘을 사용한 완전한 파일 시스템 암호화, LZ4, gzip 및 Zstandard를 통한 기본 데이터 압축, 스냅샷, CRC-32C 및 64비트 체크섬 기능이 있다. RAID 구성을 포함하여 블록 장치에 걸쳐 있을 수 있다.
초기 Bcachefs 버전은 리눅스용 블록 계층 캐시 시스템인 Bcache의 모든 기능을 제공했으며, Bcachefs는 Bcache와 코드의 약 80%를 공유한다. 2021년 12월 현재 블록 계층 캐시 기능은 제거되었다.
데이터 구조 수준에서 bcachefs는 다른 많은 최신 파일 시스템처럼 B 트리를 사용하지만, 기본값이 256KiB로 비정상적으로 큰 노드 크기를 가진다. 이 노드들은 내부적으로 로그 구조화되어 하이브리드 데이터 구조를 형성하며, 업데이트 시 노드를 다시 쓰는 필요성을 줄인다. 스냅샷은 COW 트리를 복제하여 구현되지 않고, 파일 시스템 객체에 버전 번호를 추가하여 구현된다.
Bcachefs 특징
COW 기능과 버킷 할당기는 쓰기 홀이나 IO 조각화 문제로 고통받지 않는다고 주장되는 RAID 구현을 가능하게 한다. 반면에 버킷 할당기는 대부분 비어있는 버킷을 처리하기 위해 복사 가비지 컬렉터의 사용을 필요로 한다.
Bcachefs는 스스로를 "작동하고 안정적이며, 소수의 사용자 커뮤니티를 가지고 있다"고 설명한다. 2024년 4월 7일 리눅스 6.9-rc3에 대해 논의하면서 리누스 토르발스는 bcachefs의 안정성에 대해 언급하며 "bcachefs가 이미 안정적이라고 생각했다면, 내가 당신에게 팔 다리가 있다"고 말했다. 그리고 2024년 8월에는 "제정신인 사람은 아무도 bcachefs를 사용하고 안정적일 것이라고 기대하지 않는다"고 말했다.
2024년 8월, "사용자 공간 도구 및 문서"를 제공하는 패키지인 bcachefs-tools의 데비안 유지 관리자는 패키지를 고아로 지정하며 장기 지원 가능성에 의문을 제기했다. 유지 관리자는 블로그 게시물에서 "가까운 미래에 어떤 종류의 프로덕션 용도로든 bcachefs를 사용할 것을 고려한다면, 먼저 장기적으로 얼마나 지원 가능한지, 그리고 그것을 안정적으로 지원하는 데 성공한 사람이 정말 아무도 없는지 고려해야 한다"고 덧붙였다.
Bcachefs 역사
주요 개발은 Bcachefs의 아이디어의 "프로토타입"이라고 설명하는 Bcache의 개발자인 켄트 오버스트리트에 의해 이루어졌다. 오버스트리트는 Bcachefs가 Bcache를 대체할 의도였다. 오버스트리트는 Bcachefs 개발이 Bcache 개발자들이 코드베이스가 "...완전히 성장한 범용 POSIX 파일 시스템으로 진화하고 있다"는 것을 깨달았을 때 시작되었으며, 그 방향으로 나아간다면 "정말 깨끗하고 우아한 디자인"이 그 안에 있을 것이라고 말했다. 2013년 Bcache가 주류 리눅스 커널에 병합된 후 얼마 지나지 않아 오버스트리트는 구글에서 직장을 떠나 Bcachefs에 전념하기 시작했다.
수년간의 무자금 개발 후, 오버스트리트는 2015년에 Bcachefs를 발표했으며, 당시 그는 코드를 "거의 기능이 완성되었다"고 부르며 테스터와 기여자들을 모집했다. 그는 ext4 및 XFS와 같은 파일 시스템의 속도와 성능을 가지면서 ZFS 또는 Btrfs와 같은 스냅샷, 압축 및 캐싱과 같은 최신 기능을 갖춘 고급 파일 시스템이 되기를 의도했다. 2017년 현재 오버스트리트는 Patreon을 통해 Bcachefs 개발을 위한 재정 지원을 받고 있었다.
Bcachefs 역사
2018년 중반 현재, 디스크 상의 형식은 정착되었다. Bcachefs를 주류 리눅스 커널에 포함시키기 위한 패치가 검토를 위해 제출되었다.
2019년 중반까지 Bcachefs의 원하는 기능이 완성되었고, LKML에 관련 패치가 동료 검토를 위해 제출되었다. 2023년 10월 Bcachefs는 리눅스 6.7 커널에 병합되었고, 이는 2024년 1월에 출시되었다.
2024년 11월, 켄트 오버스트리트는 "다른 커뮤니티 구성원에 대한 서면 남용"과 "개인적인 공격에 대한 두려움 없이 생산적인 기술적 논의를 할 수 있는 커뮤니티의 신뢰를 회복하기 위한 불충분한 조치"로 인해 리눅스 행동 강령 위원회로부터 리눅스 6.13 커널 개발 주기 동안 기여를 보내는 것이 제한되었다. 패치는 나중에 리눅스 6.14 커널 개발 동안 문제없이 수락되었다.
Bcachefs 역사
2025년 6월, 리누스 토르발스는 bcachefs가 리눅스 커널에서 제거될 것이라고 발표했다. 리누스는 다음과 같이 설명했다.
[...] 6.17 병합 창에서 우리가 헤어질 것이라고 생각한다.
나는 어떤 버그 수정도 질문할 수 없고 모든 것을 그냥 끌어와야 한다고 당신이 분명히 했다.
솔직히 그 시점에서 나는 전혀 관여하는 것이 불편하고, 우리가 그 논의에서 정말로 근본적으로 동의한 유일한 것은 "우리는 끝났다"는 것이었다.
2025년 8월, 리눅스 6.17에 대한 bcachefs 업데이트를 병합하지 않은 후, 토르발스는 리눅스 커널에서 bcachefs를 "외부에서 유지 관리됨"으로 표시했다. 2025년 9월, 오버스트리트는 bcachefs가 DKMS 모듈로 배포될 것이라고 발표했다.
Bcachefs 각주
Baader, Hans-Joachim (2017년 3월 17일). “Neue Version von Bcachefs bringt Verschlüsselung” [New version of bcachefs brings encryption] (독일어). 《Pro-Linux》. 2018년 11월 23일에 원본 문서에서 보존된 문서. 2018년 11월 23일에 확인함.  |work=에 라인 피드 문자가 있음(위치 145) (도움말)
트랜잭션-안전 FAT 파일 시스템
트랜잭션-안전 FAT 파일 시스템(Transaction-Safe FAT File System, TFAT) 및 트랜잭션-안전 확장 FAT 파일 시스템(Transaction-Safe Extended FAT File System, TexFAT)은 마이크로소프트 제품에서 디스크에 저장된 데이터에 대한 트랜잭션 안전을 제공하기 위해 사용되는 두 가지 파일 시스템을 지칭한다. 목표는 전원 손실 또는 드라이브의 예기치 않은 제거 시 데이터 손실 위험을 줄이는 것이다. 후자의 문제는 USB 드라이브의 확산과 함께 더 흔해졌다.
트랜잭션-안전 FAT 파일 시스템 TFAT
TFAT12, TFAT16, TFAT32 파일 시스템의 트랜잭션-안전 FAT 파일 시스템(TFAT)은 원래의 FAT 파일 시스템인 FAT12, FAT16, FAT32에 대한 드라이버 계층 수정으로, 두 개의 동일한 파일 할당 테이블 대신 두 개의 복사본(FAT 0 및 FAT 1)을 유지한다. 드라이브 작업을 수행하는 동안 변경 사항은 FAT 1에 적용된다. 작업이 완료되면 FAT 1 테이블이 FAT 0으로 복사되어 파일 시스템의 안정적인 뷰를 업데이트한다.
트랜잭션-안전 FAT 파일 시스템 TexFAT
트랜잭션-안전 확장 FAT 파일 시스템(TexFAT)은 exFAT 파일 시스템을 기본 파일 시스템으로 사용하여 TFAT와 유사한 기능을 제공한다. 윈도우 임베디드 CE 6.0과 함께 도입되었으며, 때로는 TFAT라고도 불리는데, 이는 위에 설명된 원래 TFAT와 혼동을 일으킬 수 있다.
기본 파일 시스템으로 exFAT를 사용하면 더 큰 파일과 더 큰 파티션을 허용한다. TexFAT는 TexFAT 볼륨이 있는 미디어 유형에 맞게 설계된 하드웨어 특정 드라이버가 필요하다. TexFAT는 Windows 데스크톱/서버 버전에서 지원되지 않는다.
트랜잭션-안전 FAT 파일 시스템 제한 사항
데스크톱 운영체제의 지원 부족으로 인해 TFAT와 TexFAT 모두 이동식 미디어에 권장되지 않는다. 데스크톱 OS는 드라이브를 여전히 읽을 수 있지만, 트랜잭션 안전 기능을 사용할 수 없으므로 예기치 않은 제거 또는 정전으로 인해 데이터 손실이 발생할 수 있다. 또한, 데스크톱 OS에서 생성된 디렉토리는 나중에 TFAT/TexFAT 인식 운영체제에 드라이브가 연결되더라도 트랜잭션 안전하지 않을 수 있다.
트랜잭션-안전 FAT 파일 시스템 더 읽어보기
Munegowda, Keshava; Raju, G.T.; Raju, Veera Manikandan; Manjunath, T.N. (December 2014). 《Design Methodologies of Transaction-Safe Cluster Allocations in TFAT File System for Embedded Storage Devices》. 2014 International Conference on Information Technology. IEEE. doi:10.1109/ICIT.2014.22.
Munegowda, Keshava; Raju, G.T.; Raju, Veera Manikandan; Manjunath, T.N. (2014년 12월 11일). 《Characterization of Transaction-Safe Cluster Allocation Strategies of TexFAT File System for Embedded Storage Devices》. Computational Intelligence in Data Mining. doi:10.1007/978-81-322-2205-7_47.
Cramfs
cramfs(compressed ROM/RAM 파일 시스템의 약자)는 단순함과 공간 효율성을 위해 설계된 자유(GPL로 배포되는) 읽기 전용 리눅스 파일 시스템이다. 주로 임베디드 및 작은 설치 공간의 시스템에서 사용된다.
기존 파일 시스템의 압축 이미지와 달리 cramfs 이미지는 먼저 압축을 해제하지 않고도 그대로 사용할 수 있다. 이러한 이유로 일부 리눅스 배포판은 메모리 및 이미지 크기 제약이 있는 initrd 이미지(특히 데비안 3.1) 및 설치 이미지(특히 수세 리눅스)에 cramfs를 사용한다.
2013년에 리눅스 관리자들은 cramfs가 SquashFS에 의해 구식화되었다고 밝혔지만, 2017년에는 SquashFS 사용이 불가능할 수 있는 저용량 메모리 장치에서 사용하기 위해 이 파일 시스템이 복원되었다.
Cramfs 설계
cramfs 파일 시스템의 파일은 무작위 읽기 접근을 허용하기 위해 한 페이지씩 Zlib으로 압축된다. 메타데이터는 압축되지 않지만, 기존 파일 시스템보다 공간 효율적인 간결한 표현으로 되어 있다.
파일 시스템은 의도적으로 읽기 전용으로 설계되어 디자인을 단순화했다. 압축된 파일에 대한 무작위 쓰기 접근은 구현하기 어렵다. cramfs는 새 cramfs 이미지로 파일을 압축하는 유틸리티(mkcramfs)를 함께 제공한다.
파일 크기는 16MB 미만으로 제한된다.
최대 파일 시스템 크기는 272MB보다 약간 작다. (파일 시스템의 마지막 파일은 256MB 블록 이전에 시작해야 하지만, 이를 넘어 확장될 수 있다.)
넷웨어 코어 프로토콜
넷웨어 코어 프로토콜(NetWare Core Protocol, NCP)은 노벨의 일부 제품에서 사용되는 네트워크 프로토콜이다. 이 프로토콜은 주로 노벨 네트웨어 클라이언트-서버 운영 체제와 연관되어 있으며, 원래는 주로 MS-DOS 클라이언트 스테이션을 지원했지만, 나중에 마이크로소프트 윈도우, 맥 OS의 역사, 리눅스, 윈도우 NT, Mac OS X, 다양한 유닉스 플랫폼에 대한 지원이 추가되었다.
NCP는 파일, 인쇄, 디렉토리, 클럭 동기화, 메시징, 원격 명령 실행 및 기타 네트워크 서비스 기능에 접근하는 데 사용된다. 원래는 IPX/SPX 프로토콜 스택의 쉬운 네트워크 구성과 작은 메모리 공간을 활용했다. 1991년부터 TCP/IP 구현이 가능해졌다.
노벨 eDirectory는 디렉토리 서비스 트리 내 서버 간의 데이터 변경을 동기화하는 데 NCP를 사용한다.
넷웨어 코어 프로토콜 기술 정보
원래 IPX/SPX 서버 구현은 노벨 네트웨어 플랫폼에서만 제공되었으며 현재는 구식이다. TCP/IP 구현은 TCP/UDP 포트 524를 사용하며 이름 해결을 위해 SLP에 의존한다.
IPX/SPX 네트워크에서 NCP 작동을 위해 IPX 프로토콜이 패킷 유형 필드를 17로 설정하여 사용되었다. 워크스테이션(클라이언트 스테이션) 측에서는 IPX 소켓 번호 0x4003이 사용되었고, 서버 측에서는 소켓 번호 0x0451이 사용되었다.
NCP PDU는 다음과 같은 구조를 가진다:
NCP 유형 필드는 작업 유형을 결정한다:
개별 요청은 시퀀스 번호(모듈로 256)로 식별된다. 연결 번호는 서버의 개별 클라이언트 스테이션 연결을 식별한다. 버전 2.x까지의 노벨 네트웨어 서버는 최대 255개의 연결을 지원했으며 연결 번호는 1옥텟만 차지했다. 나중에는 2옥텟으로 확장되었다. 작업 번호는 요청에서 3, 응답에서 1이다. 데이터 필드는 개별 서비스를 구별하는 NCP 함수 번호 옥텟으로 시작한다.
데이터 필드의 나머지 내용과 길이는 NCP 함수에 따라 달라진다.
EncFS
EncFS는 자유 (LGPL) FUSE 기반의 암호화 파일 시스템이다. 임의의 디렉터리를 암호화된 파일을 위한 저장 공간으로 사용하여 파일을 투명하게 암호화한다.
EncFS 파일 시스템을 마운트하는 데 두 개의 디렉터리가 관여한다: 원본 디렉터리와 마운트 지점. 마운트 지점의 각 파일은 원본 디렉터리에 해당하는 특정 파일을 갖는다. 마운트 지점의 파일은 원본 디렉터리에 있는 파일의 암호화되지 않은 보기를 제공한다. 파일 이름은 원본 디렉터리에서 암호화된다.
파일은 볼륨 키를 사용하여 암호화되며, 이 키는 암호화된 원본 디렉터리 내부에 또는 외부에 저장된다. 이 키를 해독하는 데 비밀번호가 사용된다.
EncFS는 개발자인 발리앙 고흐가 2024년 5월 GitHub 페이지에서 더 이상 업데이트 없이 휴면 상태라고 선언했다. 그는 대신 gocryptfs를 사용하는 것을 권장한다.
EncFS 일반적인 용도
2단계 인증 (2FA)을 추가하여 저장 보안을 강화한다. EncFS 볼륨 키가 암호화된 원본 디렉터리 외부에, 실제 암호화된 데이터와 물리적으로 분리된 위치에 저장될 경우, 2단계 인증 (2FA)을 추가하여 보안이 크게 향상된다. 예를 들어, EncFS는 각 고유 볼륨 키를 실제 암호화된 데이터가 아닌 USB 플래시 드라이브, 네트워크 마운트, 광 디스크 또는 클라우드와 같은 다른 어떤 곳에도 저장할 수 있다. 이 외에도 이 볼륨 키를 해독하는 데 비밀번호가 필요할 수 있다.
EncFS 장점
EncFS는 각 파일이 호스트의 디렉터리 트리의 다른 곳에 암호화된 파일로 개별적으로 저장된다는 이유만으로 다른 디스크 암호화 소프트웨어에 비해 몇 가지 장점을 제공한다.
EncFS는 여러 플랫폼에서 사용할 수 있는 반면, eCryptfs는 리눅스 커널에 종속된다.
EncFS는 기본 파일 시스템 위에 비트 부패 감지 기능을 구현한다.
EncFS는 고정된 크기를 차지하는 "볼륨"이 없으며, 마운트 지점에 파일이 추가되거나 제거됨에 따라 암호화된 디렉터리가 늘어나고 줄어든다.
EncFS의 암호화된 디렉터리는 일반 파일 서버(NFS, SSHFS 등)에 위치할 수 있으며, Rsync와 같은 일반 파일 시스템 도구를 사용하여 효율적으로 미러링 및 백업할 수 있다.
원본 디렉터리의 하위 디렉터리 중 하나에 파일 시스템이 마운트된 경우, 마운트 지점의 일부 디렉터리가 다른 물리적 장치에 존재할 수 있다.
EncFS 장점
백업 유틸리티는 원본 디렉터리에서 변경된 파일만 백업할 수 있다(파일 동기화, 클라우드 스토리지).
데이터 손상이 더욱 격리된다. 파일 데이터 손상은 단일 파일에 국한되며, 파일 시스템의 데이터 손상은 fsck와 같은 신뢰할 수 있는 파일 시스템 복구 유틸리티로 수정할 수 있다. 일부 전체 디스크 암호화 시스템은 이러한 속성 중 하나 또는 둘 다를 가지고 있지 않다.
파일 수정 사항이 기본 파일 시스템에 반영되므로, 전체 디스크 암호화와 달리 운영 체제의 다양한 최적화가 여전히 가능하다. 예를 들어, 해제된 공간에 대한 정보(TRIM)를 전달하면 SSD 드라이브의 성능을 향상시킬 수 있다. 하지만 이는 dm-crypt에서도 지원된다.
파일에 임의로 접근할 수 있다. 예를 들어, 매우 큰 암호화된 비디오 파일 전체를 해독하지 않고도 중간으로 건너뛸 수 있다.
EncFS 단점
EncFS를 사용하는 데에는 몇 가지 단점이 있다.
마운트된 EncFS 디렉터리는 원본 디렉터리를 포함하는 파일 시스템과 동일한 기능 및 제한 사항을 공유한다.
암호화 때문에 EncFS가 생성하는 암호화된 파일의 파일 이름은 원래 파일 이름보다 길다. 따라서 파일 시스템이 지원하는 최대 길이에 가까운 파일 이름은 암호화 후 길이 제한을 초과하므로 EncFS에 저장할 수 없다. 대부분의 파일 시스템은 파일 이름을 255바이트로 제한한다. 이 경우 EncFS는 최대 190바이트의 파일 이름만 지원한다.
원본 디렉터리에 접근할 수 있는 사람은 누구든지 암호화된 파일 시스템에 파일이 몇 개 있는지, 파일 권한, 대략적인 크기, 마지막 접근 또는 수정 시간을 볼 수 있지만, 파일 이름과 파일 데이터는 암호화되어 있다.
EncFS 단점
2014년 2월에 유료 보안 감사가 수행되었으며, 몇 가지 잠재적 취약점이 발견되었다. 결론은 다음과 같다.
EncFS는 공격자가 암호문 사본 하나만 얻고 그 이상은 얻지 못하는 한 아마 안전할 것이다. EncFS는 공격자가 서로 다른 시간에 암호문의 두 개 이상의 스냅샷을 볼 기회가 있다면 안전하지 않다. EncFS는 악의적인 수정으로부터 파일을 보호하려고 하지만, 이 기능에 심각한 문제가 있다.
EncFS 1.8 발표에는 이전 감사에서 제기된 보안 문제를 인정한 몇 가지 근본적인 설계 변경 사항이 포함되었다. 그러나 이러한 취약점에 대한 특정 우려 사항은 여전히 남아 있다.
EncFS 파일 시스템 옵션
새 EncFS 볼륨을 생성할 때, 다양한 요구에 맞게 파일 시스템을 사용자 정의할 수 있는 여러 옵션이 제공된다.
EncFS는 시스템의 다양한 암호화 라이브러리에서 찾을 수 있는 모든 암호를 사용한다. 블로피시와 AES가 일반적으로 사용 가능하다.
가변 키 길이를 지원하는 암호에 대해 암호화 키 길이(keySize)를 선택할 수 있다.
각 파일은 블록 단위로 암호화되며, 이 옵션은 블록의 크기를 제어한다. 단일 바이트가 읽힐 때마다 해당 블록 전체가 해독되어야 한다. 마찬가지로, 각 쓰기 작업에 대해 블록은 해독되고, 변경되고, 다시 암호화되어야 한다.
대부분의 목적에는 기본 블록 크기인 1024가 충분하다.
원본 디렉터리의 파일 이름은 일반 또는 블록 또는 스트림 모드로 암호화될 수 있다. 블록 모드는 파일 이름 길이를 다소 가리지만, 스트림 모드는 가능한 한 짧게 유지하므로 파일 시스템이 디렉터리 트리를 관리하는 방식에 따라 원본 디렉터리의 파일 시스템에서 공간을 절약할 수 있다.
EncFS 파일 시스템 옵션
활성화되면 파일 이름 암호화를 위한 초기화 벡터가 파일의 상위 디렉터리에서 파생되어, 같은 이름을 가진 두 파일(다른 디렉터리에 있지만)이 다른 암호화된 파일 이름을 갖게 된다.
디렉터리 이름이 변경되면 그 안에 포함된 모든 파일과 디렉터리의 암호화된 파일 이름을 다시 암호화해야 하며, 이는 비용이 많이 드는 작업이 될 수 있다. 이 옵션은 매우 많은 파일이 있는 디렉터리가 자주 이름이 변경될 경우 비활성화해야 한다.
활성화되면 각 파일은 무작위 8바이트 초기화 벡터로 암호화되며, 이는 원본 디렉터리의 암호화된 파일 내부에 저장된다. 이 옵션이 비활성화되면 각 파일은 동일한 초기화 벡터로 암호화되어 볼륨 키를 해독하기 더 쉽게 만들 수 있다.
이 옵션을 활성화하면 파일당 추가 8바이트의 비용으로 파일 시스템이 더 안전해진다.
파일 데이터 초기화 벡터가 파일 이름의 초기화 벡터 체인에서 파생되도록 한다. 동일한 데이터는 다른 파일 이름이나 디렉터리가 주어지면 다르게 암호화된다.
EncFS 파일 시스템 옵션
결과적으로, 이 모드가 활성화된 상태에서 파일 이름을 변경하려면 파일의 무작위 초기화 벡터가 파일 이름 초기화 벡터 체인의 변경 사항에 따라 오프셋되거나 데이터가 다시 인코딩되어야 한다. EncFS 개발자들은 후자가 특히 큰 파일의 경우 훨씬 빠르기 때문에 전자를 선택했다.
인코딩이 전체 경로 이름에 의존하도록 한다. 따라서 이름 변경이나 이동은 다시 인코딩을 의미한다. 하드 링크는 지원되지 않는다.
각 암호화된 블록과 함께 체크섬을 저장하여 암호화된 파일의 손상 또는 수정을 EncFS가 감지하도록 한다. 체크섬(blockMACBytes)은 8바이트이며, 선택적으로 최대 8바이트의 추가 임의 데이터(blockMACRandBytes)를 각 블록에 추가하여 동일한 암호화되지 않은 데이터를 가진 두 블록이 동일한 체크섬을 갖는 것을 방지할 수 있다. 이 옵션은 CPU 오버헤드가 많이 발생하는데, 데이터가 읽히거나(무결성 확인) 쓰일 때마다(체크섬 업데이트) 각 블록의 체크섬을 계산해야 하기 때문이다.
오토모티브 SPICE
오토모티브 SPICE(Automotive SPICE)는 자동차 산업에 맞게 조정된 성숙도 모델이다. 이는 전자 및 소프트웨어 기반 시스템(예: ECU)의 개발 프로세스 성숙도를 평가한다. 이 모델은 특수 이익 단체 오토모티브(Special Interest Group Automotive)와 독일 자동차 산업 협회(VDA) 산하 품질 관리 센터(QMC)의 이니셔티브를 기반으로 한다.
SPICE는 Software Process Improvement and Capability Determination의 약자이다. 오토모티브 SPICE(일반적으로 ASPICE로 약칭)는 프로세스 참조 모델과 프로세스 평가 모델을 하나의 표준으로 결합한다.
이는 ISO/IEC 33xxx 제품군(프로세스 평가)의 규정, 예를 들어 ISO/IEC 33001, ISO/IEC 33002, ISO/IEC 33004, ISO/IEC 33020을 준수한다.
오토모티브 SPICE 상표
오토모티브 SPICE라는 이름은 상표법으로 보호되며 VDA의 자산이다.
오토모티브 SPICE 역량 수준
역량 수준은 총 6단계가 있으며, 레벨(Levels)이라고 불린다. 레벨 0은 가장 낮은 역량 수준이고, 레벨 5는 가장 높은 역량 수준이다. 각 프로세스의 역량 수준은 다음과 같이 명명되고 특징 지어진다.
오토모티브 SPICE 오토모티브 SPICE 평가
오토모티브 SPICE 평가는 정의된 조직에 대해 프로세스 평가 모델(PAM)을 사용하여 개발 프로세스를 객관적으로 평가하는 것을 목표로 한다. 각 오토모티브 SPICE 프로세스 부분은 개별적으로 평가되고 해당 성숙도 수준이 할당된다. 예를 들어, 현재 표준에 언급된 시스템 개발(SYS), 소프트웨어 개발(SWE), 프로젝트 관리(MAN), 지원 프로세스(SUP) 등과 같은 프로세스 그룹이 고려된다.
평가 계획에서 평가 의뢰인("스폰서"라고도 함)과 평가 책임자("수석 평가자"라고도 함)는 조직의 맥락과 관련이 있는 프로세스 차원의 프로세스, 평가할 성숙도 수준, 프로세스 인스턴스(예: 개발 사이트)를 정의한다.
오토모티브 SPICE에 따르면, ISO/IEC 33020:2015(이전 ISO/IEC 15504-2) 표준의 요구 사항은 준수하는 오토모티브 SPICE 평가 수행에 적용되며, 예를 들어 수석 평가자의 역량, 입력 문서 생성, 수행할 활동, 출력 문서 생성 및 전체 평가 프로세스의 포괄적인 문서화에 대한 내용을 포함한다.
오토모티브 SPICE 교육 및 자격
오토모티브 SPICE 평가 참가자, 특히 평가 수행 책임자는 오토모티브 SPICE에 대한 필요한 지식을 갖춰야 한다. 이는 교육, 성공적인 인증 및 평가자로서의 정기적인 활동 증명을 통해 이루어진다. 이를 위해 아래에 나열된 교육 제공 기관 및 자격 부여 기관이 존재한다.
다음과 같은 자격 부여 기관이 알려져 있다.
이러한 맥락에서 iNTACS e.V.는 평가자(심사관) 교육을 위한 동명의 제도를 개발한 VDA의 협력 파트너이다. 이 제도는 제조사 이니셔티브 소프트웨어(HIS)[3][4](AUTOSAR 및 ISO 26262 참조) 및 ISO/IEC 15504-2의 자격 요구 사항을 충족한다. iNTACS e.V.와 VDA 간에는 높은 품질 표준으로 오토모티브 SPICE 평가자의 교육 및 인증을 공동으로 보장하고 제도를 더욱 발전시키기 위한 협력 계약이 있다.
2025년 기준으로 약 7600명의 등록된 평가자가 있다.
오토모티브 SPICE의 최신 버전은 2023년 11월에 오토모티브 SPICE 4.0으로 출시되었다.
오토모티브 SPICE 역사
오토모티브 SPICE는 2001년 아우디, BMW, 다임러, 포르쉐, 폭스바겐 등 독일 자동차 제조사와 피아트, 포드, 재규어, 랜드로버, 볼보, SPICE 사용자 그룹, 조달 포럼 등 국제 자동차 제조사 및 이익 단체가 포함된 AUTOSIG(Automotive Special Interest Group)에 의해 개발되었다.
2007년경부터 독일 자동차 제조사인 아우디, BMW, 다임러, 포르쉐, 폭스바겐은 제조사 이니셔티브 소프트웨어(HIS)(이전 HIS Scope, 이후 VDA Scope)의 일환으로 평가 시 고려해야 할 최소 프로세스의 공통 범위에 합의했다.
2007년 1월 1일부로 HIS 회원사는 공급업체와의 공동 프로젝트 작업 맥락에서 오토모티브 SPICE 평가만 수용했다.
현재(2023년 기준) 유효한 버전은 VDA와 QMC가 2023년 12월에 발행한 오토모티브 SPICE 4.0이다. 다음 언어로 번역본을 사용할 수 있다: 영어, 일본어, 한국어, 중국어.[7] 이 최신 버전은 오토모티브 SPICE 3.1을 대체한다.
이 모델은 위 작업 그룹에 의해 지속적으로 개발되거나 개선되고 있다.[9] 아래에 두 가지 확장이 제시되어 있다.
오토모티브 SPICE 확장
2021년경부터 정보 보안은 오토모티브 SPICE의 일부로 명세되고 테스트될 것이다.[10] 사이버 보안은 버전 3.1의 일부가 아니다. 해당 주제에 대한 SAE J3061 표준도 참조하라.
기계 공학을 위한 SPICE(ME-SPICE로 약칭)는 정의된 플러그인 개념에 따른 오토모티브 SPICE의 확장이다. ME-SPICE의 목적은 기계 시스템 또는 메카트로닉 시스템의 기계 부품 개발 프로세스 성능을 평가하는 것이다.
오토모티브 SPICE 문헌
Christoph Stoiber et al.: Keeping Your Maturity Assessment Alive: A Method for the Continuous Tracking and Assessment of Organizational Capabilities and Maturity. In: Business & Information Systems Engineering. March 31, 2023, doi:10.1007/s12599-023-00805-y.
오토모티브 SPICE 참고 서적
오토모티브 SPICE에 관한 대부분의 책은 전통적으로 독일어로 출판된다. 다음은 영어로 제공되는 책이다.
Automotive SPICE Essentials: Automotive SPICE v3.1 – at a glance (E/E Engineering Essentials), Klaus Hoermann (Author), Peter Abowd (Author), Bhaskar Vanamali (Author), Dan Wall (Author), ISBN 978-3-945547-30-4
소거 부호
부호 이론에서 소거 부호 또는 이레이저 코드(erasure code)는 비트 오류(비트 에러) 대신 비트 소거를 가정하는 전방 오류 정정(FEC) 부호로, k개의 심볼로 이루어진 메시지를 n개의 심볼로 이루어진 더 긴 메시지(코드워드)로 변환하여 원래 메시지를 n개의 심볼 중 일부로 복구할 수 있게 한다. r = k/n 비율을 부호율이라고 한다. k’/k 비율(여기서 k’는 복구에 필요한 심볼 수를 나타냄)을 수신 효율이라고 한다. 복구 알고리즘은 n개의 심볼 중 어느 심볼이 손실되었는지 알고 있다고 가정한다.
소거 부호 역사
소거 부호화는 1960년에 어빙 리드와 구스타프 솔로몬이 발명했다.
다양한 소거 부호화 방식이 있다. 가장 널리 사용되는 소거 부호는
리드-솔로몬 부호,
저밀도 패리티 검사 부호(LDPC 부호),
터보 코드이다.
2023년 현재, 최신 데이터 저장 시스템은 세 가지 접근 방식 중 하나를 사용하여 데이터 손실 없이 몇 개의 디스크가 완전히 고장 나는 것을 허용하도록 설계될 수 있다.
기술적으로 RAID는 일종의 소거 부호로 볼 수 있지만,
"RAID"는 일반적으로 단일 호스트 컴퓨터(단일 실패 지점)에 연결된 배열에 적용되는 반면, "소거 부호화"는 일반적으로 여러 호스트를 의미하며,
때로는 저가 서버의 중복 배열(RAIS)이라고도 한다.
소거 부호는 해당 호스트 중 하나라도 작동을 멈출 때 작업이 계속될 수 있도록 한다.
블록 수준 RAID 시스템과 비교할 때, 객체 저장소 소거 부호화는 더 높은 탄력성을 제공하는 몇 가지 중요한 차이점이 있다.
소거 부호 최적 소거 부호
최적 소거 부호는 n개의 코드워드 심볼 중 k개만으로도 원래 메시지를 복구할 수 있는 속성을 가진다(즉, 최적의 수신 효율을 가짐). 최적 소거 부호는 최대 거리 분리 부호(MDS 부호)이다.
패리티 검사는 n = k + 1인 특수한 경우이다. k개의 값 에서 체크섬이 계산되고 k개의 원본 값에 추가된다.
이제 k + 1개의 값 은 체크섬에 대해 일관성이 있다.
이 값들 중 하나인 가 지워지면, 나머지 변수들을 합하여 쉽게 복구할 수 있다.
RAID 5는 XOR를 사용하는 패리티 검사 소거 부호의 널리 사용되는 응용이다.
k = 2인 간단한 경우, 두 원래 심볼 사이의 선을 따라 다른 지점을 샘플링하여 중복 심볼을 만들 수 있다. 이는 오류 메일이라는 간단한 예로 설명된다.
앨리스는 오류 메일을 사용하여 자신의 전화번호(555629)를 밥에게 보내고 싶어 한다. 오류 메일은 이메일과 거의 동일하게 작동하지만, 다음과 같은 차이가 있다.
앨리스는 밥에게 보낸 메시지의 확인을 요청하는 대신 다음 방식을 고안한다.
소거 부호 최적 소거 부호
밥은 f(k)의 형태가 이며, 여기서 a와 b는 전화번호의 두 부분이라는 것을 알고 있다.
이제 밥이 "D=777"과 "E=851"을 받았다고 가정해 보자.
밥은 받은 값(f(4)와 f(5))으로부터 a와 b의 값을 계산하여 앨리스의 전화번호를 재구성할 수 있다.
밥은 어떤 두 오류 메일을 사용해서도 이 절차를 수행할 수 있으므로, 이 예의 소거 부호는 40%의 부호율을 가진다.
앨리스는 전화번호를 하나의 오류 메일로 인코딩할 수 없다는 점에 유의해야 한다. 전화번호는 여섯 자를 포함하고, 하나의 오류 메일 메시지의 최대 길이는 다섯 자이기 때문이다. 만약 그녀가 전화번호를 조각으로 보내 각 조각의 수신 확인을 밥에게 요청했다면, 어쨌든 최소 네 개의 메시지(앨리스로부터 두 개, 밥으로부터 두 개의 확인)가 전송되어야 했을 것이다. 따라서 다섯 개의 메시지를 요구하는 이 예의 소거 부호는 매우 경제적이다.
이 예가 약간 인위적이라는 점에 주목해야 한다. 진정으로 일반적인 소거 부호가 어떤 데이터 집합에서도 작동하려면 주어진 f(i) 외의 다른 것이 필요하다.