shopkeeper/korean_wiki_content_only_120125 huggingface dataset:
주격 단수에서 대부분의 남성 명사는 어간과 어미 -us로 구성되지만, 일부는 -er로 끝나며, 이는 반드시 완전한 어간에 붙는 것은 아니다. 중성 명사는 일반적으로 어간과 어미 -um으로 구성된 주격 단수를 가진다. 성별에 관계없이 모든 제2변화 명사는 속격 단수 형태에서 명사의 어근에 -ī 어미가 접미사로 붙는다. 이 변화형 어미 형태에서 지배적인 문자는 o이다.
제2변화의 처격 어미는 -ī(단수)와 -īs(복수)이다. "코린토스에서", "밀라노에서", 그리고 "필리피에서"이다.
제2변화 -ius와 -ium 명사.
-ius와 -ium으로 끝나는 명사는 초기 라틴어에서는 -ī로 끝나는 속격 단수를 가졌지만, 후기 라틴어에서는 -iī로 규칙화되었다. -ius로 끝나는 남성 명사는 모든 시기에 -ī로 끝나는 호격 단수를 가진다. -ī 형태는 주격 단수와 같은 음절에 강세가 오며, 때로는 일반적인 라틴어 강세 규칙을 위반한다. 예를 들어, Vergilius에서 온 속격 및 호격 단수 Vergilī는 짧음에도 불구하고, 마지막에서 두 번째 음절에 강세가 있는 Vergílī로 발음된다. 그러나 고대 라틴어에서는 호격이 규칙적으로 -ie를 사용하여 곡용되었는데, 예: fīlie "[오] 아들아", 의 고어 호격이다.
복수형과 처격에는 -iī(s)의 축약이 없다.
옛 언어에서는 -vus, -quus, -vum으로 끝나는 명사가 주격과 대격 단수에서 u 대신 o를 취했다. 예를 들어, ('노예')는 servos가 될 수 있었고, 대격은 servom이었다.
제2변화 -r 명사.
제2변화의 일부 남성 명사는 주격 단수에서 -er 또는 -ir로 끝난다. 이 명사들의 변화는 규칙적인 제2변화와 동일하며, 주격과 호격 단수에 접미사가 없다는 점만 다르다.
일부(-er 명사 전부 아님)는 속격 및 다른 격에서 e를 생략한다. 예를 들어, ('장인')는 e를 유지한다. 그러나 명사 ('(학교)선생님')는 속격 단수에서 e를 생략한다.
제2변화 명사의 곡용표는 을 참조한다.
호격 puere는 플라우투스 작품에서 발견되지만, 속격 복수 virum은 시에서 발견된다.
제2변화 그리스 명사.
제2변화는 두 가지 종류의 남성 그리스어 명사와 한 가지 형태의 중성 그리스어 명사를 포함한다. 이 명사들은 제1변화 명사들과 마찬가지로 단수에서만 불규칙적이다. 제2변화의 그리스어 명사들은 오미크론 변화에서 유래했다.
일부 그리스어 명사는 일반적인 라틴어 명사처럼 곡용될 수도 있다. 예를 들어, 은 theātrum으로 나타날 수 있다.
불규칙 형태.
('신')의 굴절은 불규칙하다. 클래식 라틴어에서는 deus의 호격 단수 형태가 입증되지 않았다. 교회 라틴어에서는 Deus ('하느님')의 호격은 Deus이다.
시에서는 속격 복수 어미로 -ōrum 대신 -um이 사용될 수 있다.
세 단어는 제2변화 중성 명사임에도 불구하고 -us로 끝난다. 이들은 "보통 사람들, 군중", "점액, 독", 그리고 (그리스어에서 차용된) "바다"이다.
라는 단어는 "1. 끈적한 액체, 점액; 2. 독, 독극물"을 의미하며, 뱀의 독을 나타낸다. 이 라틴어 단어는 아마도 그리스어의 (ios) "독" 또는 "녹"과 산스크리트어 단어 "독성, 독"과 관련이 있을 것이다.
고대에는 가 셀 수 없는 것을 나타냈기 때문에 집합 명사였다. 집합 명사는 특별한 상황에서만 복수형이 되므로, 텍스트에 복수형이 존재하지 않는다.
근대 라틴어에서는 현대의 '바이러스' 개념을 표현하기 위해 복수형이 필요하며, 이는 다음과 같은 변화로 이어진다.
제3변화는 가장 큰 명사 그룹이다. 이 명사들의 주격 단수는 -a, -e, -ī, -ō, -y, -c, -l, -n, -r, -s, -t, 또는 -x로 끝날 수 있다. 이 그룹에는 남성, 여성, 중성 명사가 포함된다.
자음 어간.
자음 어간 명사의 어간은 속격에서 어미 -is를 제거하여 찾을 수 있다. 예를 들어, '평화'의 어간은 pāc-이고, '강'의 어간은 flūmin-이며, '꽃'의 어간은 flōr-이다.
남성, 여성, 중성 명사는 종종 자체적인 주격 단수 어미를 가진다. 예를 들어, 많은 남성 명사는 -or로 끝난다(, '사랑'). 많은 여성 명사는 -īx로 끝난다(, '불사조'), 그리고 많은 중성 명사는 사격에서 r 어간과 함께 -us로 끝난다( '짐'; '시간').
제3변화의 처격 어미는 -ī 또는 -e(단수)와 -ibus(복수)이다. 예: '시골에서' 및 '트랄레스에서'.
제3변화 i-어간 및 혼합 명사.
제3변화에는 다르게 곡용되는 일련의 명사들도 있다. 이들을 i"-어간이라고 부른다. i-어간은 순수 i-어간과 혼합 i-어간 두 가지 하위 범주로 나뉜다. 순수 i-어간은 특별한 중성 어미로 표시된다. 혼합 i-어간은 이중 자음 규칙으로 표시된다. 동음절 규칙으로 표시되는 어간은 대개 혼합형이며, 가끔 순수형이다.
혼합 변화는 속격 복수에서 -ium(그리고 가끔 대격 복수에서 -īs)을 가진다는 점에서 자음형과만 구별된다. 순수 변화는 탈격 단수에서 -ī, 속격 복수에서 -ium, 주격 및 대격 복수 중성에서 -ia, 대격 단수 남성 및 여성에서 -im(그러나 형용사는 -em)을 가진다는 특징이 있다.
대격 복수 어미 -īs는 베르길리우스까지의 초기 라틴어에서 발견되었지만, 초기 제국 이후에는 -ēs로 대체되었다.
대격 단수 어미 -im은 몇몇 단어에서만 발견된다. '기침', '갈증', '티베르 강'에서는 항상; '도끼', '탑', '선미', '열병'에서는 보통; '배'에서는 가끔 발견된다. 그러나 대부분의 명사는 대격 단수 -em을 가진다. -im 어미는 '빠른' 또는 '날카로운'과 같이 별도의 여성형을 가진 형용사에서도, 어떤 남성 공통 명사에서도 발견되지 않는다.
탈격 단수 -ī는 -im을 가지는 명사에서 발견되며, 선택적으로 다른 명사에서도 발견된다. 예: 또는 '불 속에'.
혼합 변화 중성 명사는 두 개가 있다: ('심장')와 ('뼈'). 혼합 변화는 복수형만 있는 형용사 ('대부분')에서도 사용된다.
i-어간과 비i-어간, 혼합 i-어간을 구분하는 규칙은 규칙이라기보다는 지침에 가깝다. 동음절 규칙에 따라 i-어간이 될 것으로 예상되는 많은 단어들, 예를 들어 ('개')나 ('젊은이')는 실제로는 i-어간이 아니며, 속격 복수형은 '개의'와 '젊은이들의'이다. 마찬가지로 ('아버지'), ('어머니'), ('형제'), 그리고 ('부모')는 이중 자음 규칙을 위반한다. 로마 시대에도 이러한 유동성 때문에 중세 라틴어에서는 훨씬 더 많은 불확실성이 발생했다.
'도시, 공동체'와 같이 -tāt-로 끝나는 일부 명사는 자음 어간 또는 i-어간 속격 복수형을 가질 수 있다. 또는 '도시들의'.
제3변화에는 네 개의 불규칙 명사가 있다.
제4변화 (u 어간).
제4변화는 ('파도') 및 ('항구')와 같은 대부분의 남성 단어로 구성된 그룹이며, ('손') 및 ('집')을 포함한 몇 가지 여성 예외가 있다. 제4변화는 또한 ('무릎')을 포함한 여러 중성 명사를 포함한다. 각 명사는 속격 단수 형태에서 명사의 어근에 -ūs 어미가 접미사로 붙는다. 이 변화형의 어미 형태에서 지배적인 문자는 u이지만, 이 변화형은 다른 면에서 제3변화 i 어간과 매우 유사하다.
Domus.
('집, 거주지, 건물, 고향, 가족, 가구, 인종')는 불규칙 명사로, 제4변화와 제2변화 형태를 동시에 혼합한다(특히 문학에서). 그러나 실제로는 일반적으로 -us 어간의 제4변화 명사처럼 곡용되지만, 탈격 단수 -ō, 대격 복수 -ōs, 그리고 처격 사용은 예외이다.
제5변화 (e 어간).
제5변화는 ('사건, 문제, 물건')과 diēs, diēī ('날'; 하지만 요일 이름에서는 )과 같은 대부분의 여성 명사로 구성된 작은 그룹이다.
-iēs로 끝나는 명사는 여격과 속격에서 ēī가 길며, 자음 + -ēs로 끝나는 명사는 보통 이들 격에서 eī가 짧다. 다른 속격 단수 형태도 발견되는데, 예를 들어 (아이네이스 1.636), (농경시 1.208), (엔니우스)가 있다.
제5변화의 처격 어미는 -ē(단수만 해당)로, 탈격 단수와 동일하다. 예: ('오늘').
1인칭과 2인칭은 불규칙하며, 두 대명사 모두 성에 따라 곡용되지 않는다. 그리고 3인칭 재귀대명사 sē, suī는 주어가 단수인지 복수인지에 관계없이 항상 주어를 다시 가리킨다.
속격 형태 , , , , 는 특정 문법 구조에서 보어로 사용되는 반면, , 은 부분격 의미('우리 중 [하나]', '너희 중 [하나]')로 사용된다. 소유를 표현하기 위해 소유 대명사(본질적으로 형용사) , , , 가 사용되며, 소유된 것의 수와 격에 일치하도록 제1변화와 제2변화로 곡용된다. 예: '나의 아버지', '나의 어머니'. 의 호격 단수 남성형은 이다. '나의 사랑하는 아티쿠스'.
소유대명사의 곡용.
소유 형용사 는 고어 변형인 를 가지는데, 와 유사하다. 의 호격은 대개 이고, 드물게 주격과 같은 도 사용된다.
일반적으로 동반 탈격을 나타내기 위해 이 탈격 형태 앞에 놓인다. 그러나 인칭대명사(1인칭과 2인칭), 재귀대명사, 의문대명사에서는 -cum이 탈격 형태의 끝에 붙는다. 즉, '나와 함께', '우리와 함께', '너와 함께', , 그리고 (때로는 ).
대명사는 또한 강조형으로 접미사 -met을 사용하여 bi 형태를 가진다(, /, , ). 이 형태는 속격 복수 형태를 제외한 모든 격에서 사용된다.
대격에서는 mēmē와 tētē 형태가 강조형으로 존재하지만, 널리 사용되지는 않는다.
는 소유 형용사를 가진다. 은 '그/그녀/그것/그들 자신의'를 의미한다.
'그의' 또는 '그녀의'가 주어가 아닌 다른 사람을 지칭할 때는 suus 대신 속격 대명사 (eōrum 및 eārum 포함) '그의/그녀의'를 사용한다.
는 소유 형용사 , 와 유사하지만, 형용사처럼 자신이 수식하는 명사에 일치하도록 곡용되지 않는다. 예를 들어, 대격에서 "그의 아버지"는 (문자 그대로 "그의 아버지")이며, *eium이 아니다. 이는 재귀 형태인 ("자신의 아버지")과 대조된다.
하나의 문장 안에 다른 주어를 가진 다른 문장이 삽입될 때, sē와 suus는 두 주어 중 하나를 가리킬 수 있다.
3인칭 대명사 '그'에 대해서는 아래를 참조한다.
지시대명사 및 형용사.
관계대명사, 지시대명사, 부정대명사는 일반적으로 1, 2변화 형용사처럼 곡용되지만 다음과 같은 차이가 있다.
이러한 차이점들은 대명사적 곡용을 특징짓고, 몇몇 특별한 형용사들( '전체', '혼자', '하나', '없다', '다른', '다른 [둘 중 하나]', 등)도 이 패턴에 따라 곡용된다.
라틴어의 모든 지시, 관계, 부정 대명사는 형용사적으로도 사용될 수 있으며, 몇 가지 작은 차이점이 있다. 예를 들어 의문 대명사에서는 '누구?'와 '무엇?'이 일반적으로 대명사 형태에 사용되고, 와 '어느?'가 형용사 형태에 사용된다.
3인칭 대명사.
약한 지시대명사 , , '저것'은 또한 3인칭 대명사 '그, 그녀, 그것'으로도 사용된다.
이 대명사는 형용사적으로도 자주 사용된다. 예: is homo '저 남자', ea pecunia '저 돈'. 이 대명사에는 소유 형용사가 없으며, 대신 속격이 사용된다. pater eius '그/그녀의 아버지', pater eōrum '그들의 아버지'.
īdem의 곡용.
대명사 또는 대명사 형용사 는 '같은'을 의미한다. 이는 is에 접미사 -dem이 붙어서 파생되었다. 그러나 일부 형태는 동화되었다.
기타 지시대명사.
곡용이 유사한 것은 '다른'이다.
의문대명사는 엄격하게 질문을 할 때 사용된다. 관계대명사 및 의문형용사(관계대명사처럼 곡용됨)와는 구별된다. 의문대명사는 복수형으로 거의 사용되지 않는다. 복수 의문대명사는 복수 관계대명사와 동일하다.
대부분의 경우 형용사는 명사처럼 곡용되지만, 형용사는 일반적으로 세 가지 성별 모두에서 사용될 수 있다는 차이점이 있다.
거의 모든 형용사는 두 가지 유형 중 하나로 분류될 수 있다.
형용사는 수, 성, 격에서 해당 명사와 일치한다. 곡용 유형에서는 일치하지 않는다. 따라서 형용사는 명사와 반드시 같은 어미를 취하지는 않지만, 종종 그렇게 되는 경우가 많다.
제1변화 및 제2변화 형용사.
제1변화 및 제2변화 형용사는 남성, 여성, 중성으로 굴절된다. 남성형은 일반적으로 -us로 끝나지만(아래 참조), 일부는 -er로 끝나며, 여성형은 -a, 중성형은 -um으로 끝난다. 따라서 일부 형용사는 과 같이 주어진다.
-ius로 끝나는 형용사는 (ēbrius의 호격인 ēbrie, "[오] 취한 남자"처럼) 호격 -ie를 사용하는데, 이는 고대 라틴어의 모든 -ius 명사들이 그랬던 것과 같다(fīlius의 고대 호격인 fīlie, "[오] 아들아").
제1변화 및 제2변화 -r 형용사.
일부 제1변화 및 제2변화 형용사의 남성형은 -er로 끝난다. 제2변화 -r 명사와 마찬가지로 일부 형용사는 굴절 내내 e를 유지하고, 일부는 e를 생략한다. 는 e를 생략하는 반면 는 e를 유지한다.
제1변화 및 제2변화 대명사 형용사.
아홉 개의 제1, 제2변화 대명사 형용사는 모든 성별에서 속격과 여격 단수가 불규칙하다. 이들은 라는 니모닉을 사용하여 기억할 수 있다. 다음은 그 형용사들이다.
제3변화 형용사.
제3변화 형용사는 일반적으로 제3변화 i-어간 명사처럼 곡용되지만, 탈격 단수에서 -e 대신 -ī를 가진다는 점이 다르다(i-어간 명사의 경우 순수 i-어간만 -ī를 가짐). 그러나 일부 형용사, 예를 들어 한 어미를 가진 ('늙은, 나이든')는 탈격 단수에서 -e, 속격 복수에서 -um, 주격 및 대격 중성 복수에서 -a를 가진다.
한 어미를 가진 제3변화 형용사.
이들은 모든 성별에 대해 단 하나의 주격 어미를 가지지만, 다른 격의 어미는 평소와 같이 다양하다. 명사와 마찬가지로 굴절을 보여주기 위해 속격이 주어진다.
두 어미를 가진 제3변화 형용사.
두 어미를 가진 제3변화 형용사는 남성과 여성에 대한 한 가지 형태와 중성에 대한 별도의 형태를 가진다. 남성과 여성에 대한 어미는 -is이며, 중성에 대한 어미는 -e이다. 속격은 주격 남성 단수와 동일하므로 속격을 명시할 필요는 없다.
세 어미를 가진 제3변화 형용사.
세 어미를 가진 제3변화 형용사는 세 가지 성별 모두에 대해 세 가지 별도의 주격 형태를 가진다. 제3변화 및 제2변화 -r 명사와 마찬가지로 남성형은 -er로 끝난다. 여성형은 -ris로, 중성형은 -re로 끝난다. 속격은 주격 여성 단수와 동일하다.
형용사의 비교급과 최상급.
영어와 마찬가지로 형용사도 최상급과 비교급 형태를 가진다. 규칙적인 제1, 제2변화 및 한두 어미를 가진 제3변화 형용사의 경우, 비교급은 어간에 남성과 여성은 -ior를, 중성은 -ius를 추가하여 형성된다. 둘 다 속격은 -iōris를 추가하여 형성된다. 따라서 이들은 제3변화로 곡용되지만, i-어간으로 곡용되지는 않는다. 최상급은 어간에 -issimus, -issima, -issimum을 추가하여 형성되며, 따라서 제1, 제2변화 형용사처럼 곡용된다.
-er 형용사의 비교급과 최상급.
남성 주격 단수 형태가 -er로 끝나는 형용사(제1, 제2, 제3변화 모두)는 약간 다르다. 일반 형용사와 마찬가지로 비교급은 어간에 -ior를 추가하여 형성되지만, 최상급의 경우 주격 남성 단수에 -rimus를 추가한다.
-lis 형용사의 비교급과 최상급.
남성-여성 주격 단수에서 -lis로 끝나는 두 어미를 가진 일부 제3변화 형용사는 불규칙 최상급 형태를 가진다. 다음은 그러한 유일한 형용사들이다.
-eus/-ius 형용사의 비교급과 최상급.
-eus 또는 -ius로 끝나는 제1, 제2변화 형용사는 어미를 취하여 비교급과 최상급을 형성하지 않는다는 점에서 특이하다. 대신, ('많이, 크게')의 비교급과 최상급인 ('더')와 ('가장')를 각각 사용한다.
-quus 또는 -guus로 끝나지 않는 많은 -uus 형용사도 이 규칙을 따른다.
불규칙 비교급과 최상급.
대부분의 언어와 마찬가지로 라틴어에도 불규칙 비교급과 최상급을 가진 형용사가 있다.
라틴어에는 여러 종류의 수사가 있다. 가장 흔한 두 가지는 기수와 서수이다. 또한 배수사나 부사 수사와 같이 더 희귀한 수사들도 있다.
모든 기수사는 곡용되지 않지만, ('하나'), ('둘'), ('셋'), 복수 백단위 ('이백'), ('삼백') 등과 ('천')는 형용사처럼 격과 성을 가진다. 은 속격에서 -īus 또는 -ius, 여격에서 -ī를 가지는 제1-2변화 대명사처럼 곡용된다. 는 불규칙하게 곡용되며, 는 제3변화 복수 형용사처럼 곡용되고, -centī('백') 수사는 제1-2변화 형용사처럼 곡용되며, 는 단수에서 불변하고 복수에서는 제3변화 i-어간 중성 명사처럼 곡용된다.
ūnus의 복수형 어미는 plūrālia tantum 명사와 함께 사용된다. 예를 들어, ūna castra (하나의 [군사] 캠프), ūnae scālae (하나의 사다리).
('둘 다')라는 단어는 duo처럼 곡용되지만, o가 길다는 점이 다르다. 두 곡용 모두 라틴어에서는 폐기된 인도유럽조어 쌍수에서 유래하며, 복수형이 아니다.
수사 ('백')은 곡용되지 않지만, 다른 모든 백 단위 수사들은 곡용된다(, , , , , , , ).
단어 mīlle '천'은 단수 불변 형용사이다. 그러나 그 복수형인 mīlia는 복수 제3변화 i-어간 중성 명사이다. "네 마리의 말"을 라틴어로 쓰려면 속격을 사용한다. quattuor mīlia equōrum, 문자 그대로 "네 개의 말의 천".
나머지 숫자들은 형용사나 명사로 사용될 때 모두 곡용되지 않는다.
라틴어 수사의 다양한 종류에 대한 자세한 정보는 라틴어 수사 (언어학)을 참조한다.
부사 및 그 비교급과 최상급.
부사는 곡용되지 않는다. 그러나 형용사를 부사로 만들려면 부사를 형성해야 한다.
제1변화 및 제2변화 형용사에서 파생된 부사.
제1, 제2변화 형용사의 부사는 어간에 -ē를 추가하여 형성된다.
제3변화 형용사에서 파생된 부사.
일반적으로 제3변화 형용사의 부사는 어간에 -iter를 추가하여 형성된다. 그러나 한 가지 어미를 가진 대부분의 제3변화 형용사는 단순히 어간에 -er를 추가한다.
부사의 비교급과 최상급.
부사의 비교급 형태는 해당 비교급 형용사의 주격 중성 단수와 동일하다. 부사의 최상급 형태는 해당 최상급 형용사에 규칙 어미 -ē를 붙여서 간단하게 형성된다. 해당 형용사 형태와 마찬가지로, -eus 또는 -ius로 끝나는 제1, 제2변화 형용사는 별도의 어미 대신 와 를 사용한다.
불규칙 부사 및 그 비교급과 최상급 형태.
형용사와 마찬가지로 라틴어에도 불규칙 비교급과 최상급 형태를 가진 부사가 있다.
곡용 내 특이성.
수의 불규칙성.
일부 명사는 단수로만 사용된다(단수고유명사) 예:
일부 명사는 복수로만 사용되거나(plurale tantum) 복수일 때 단수 의미를 가진다. 예:
불변 명사.
불변 명사는 모든 단수 격에서 형태가 하나뿐인 명사이다.
이종 명사.
이종 명사는 성별에 따라 달라지는 명사이다.
Squashfs는 리눅스용 압축된 읽기 전용 파일 시스템이다. Squashfs는 파일, 아이노드 및 디렉터리를 압축하며, 더 나은 압축을 위해 4 KiB에서 최대 1 MiB까지의 블록 크기를 지원한다. 여러 압축 알고리즘이 지원된다. Squashfs는 Squashfs 파일 시스템에 접근하기 위한 GPL에 따라 라이선스된 자유 소프트웨어의 이름이기도 하다.
Squashfs는 일반적인 읽기 전용 파일 시스템 사용과 낮은 오버헤드가 필요한 제한된 블록 장치 기억 장치 시스템(예: 임베디드 시스템)에 사용하도록 고안되었다.
Squashfs는 아치 리눅스, 클론질라, 데비안, 페도라, 젠투 리눅스, KDE 네온, 칼리 리눅스, 리눅스 민트, NixOS, Salix, 우분투, 오픈수세의 라이브 CD 버전과 OpenWrt 및 DD-WRT 라우터 펌웨어와 같은 임베디드 배포판에서 사용된다. 또한 크롬캐스트, 타이니 코어 리눅스에서 확장 기능 패키징을 위해, 일부 안드로이드 릴리스(안드로이드 누가)의 시스템 파티션에도 사용된다. 일반적으로 유니언FS, Overlayfs 또는 aufs와 같은 유니언 마운트 파일 시스템과 결합하여 라이브 리눅스 배포판을 위한 읽기-쓰기 환경을 제공한다. 이는 Squashfs의 고속 압축 기능과 라이브 CD에서 실행하는 동안 배포판을 변경할 수 있는 기능을 모두 활용한다. 데비안 라이브, Mandriva One, 퍼피 리눅스, Salix 라이브 및 SLAX와 같은 배포판은 이 조합을 사용한다. 휴대용 리눅스 애플리케이션 생성을 목표로 하는 앱이미지 프로젝트는 AppImage 생성을 위해 Squashfs를 사용한다. 스냅 패키지 시스템도 Squashfs를 파일 컨테이너 형식으로 사용한다.
Squashfs는 리눅스 터미널 서버 프로젝트 및 Splashtop에서도 사용된다. unsquashfs 및 mksquashfs 도구는 윈도우 NT – 윈도우 8.1로 포팅되었다. 7-Zip도 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(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킬로바이트) 내의 각 페이지는 순차적으로 기록되어야 하며, 각 페이지는 한 번만 기록되어야 한다.
"한 번 쓰기 규칙"("write once property")을 강제하는 스토리지 시스템을 설계하는 것은 몇 가지 장점이 있다.
YAFFS2는 이러한 최신 칩들을 수용하기 위해 설계되었다. 이는 YAFFS1 소스 코드를 기반으로 하며, 주요 차이점은 내부 구조가 512바이트 크기로 고정되어 있지 않고, 각 기록된 페이지에 블록 시퀀스 번호가 부여된다는 점이다. 이런 방식으로 이전 페이지는 "한 번 쓰기" 규칙을 위반하지 않고 논리적으로 덮어쓸 수 있다. 2003년 말에 출시되었다.
YAFFS는 데이터 무결성을 최우선으로 하는 견고한 로그 구조화 파일 시스템이다. YAFFS의 보조 목표는 고성능이다. YAFFS는 일반적으로 대부분의 대안보다 뛰어난 성능을 보인다. 또한 이식성을 고려하여 설계되었으며 리눅스, WinCE, pSOS, RTEMS, eCos, ThreadX 및 다양한 특수 목적 운영 체제에서 사용되었다. 'YAFFS/Direct' 변형은 운영 체제가 없거나 임베디드 운영 체제 또는 부트로더가 있는 상황에서 사용된다. 이 변형은 동일한 코어 파일 시스템을 가지고 있지만 상위 및 하위 수준 코드와 NAND 플래시 하드웨어 모두에 대한 인터페이스가 더 간단하다.
YAFFS 코드베이스는 GPL과 Aleph One에서 제공하는 제품별 라이선스 모두로 라이선스가 부여된다.
YAFFS는 높은 수준에서 파티션별로 잠겨 있어 한 번에 하나의 스레드만 쓸 수 있다.
YAFFS1.
YAFFS 파일 시스템을 초기화하는 특별한 절차는 플래시 메모리를 단순히 지우는 것 외에는 없다. 불량 블록이 발생하면 YAFFS는 스마트 미디어 방식에 따라 블록의 여유 영역에서 다섯 번째 바이트를 표시한다. 이렇게 표시된 블록은 그 이후로 할당되지 않은 상태로 유지된다.
파일 데이터를 쓰기 위해 YAFFS는 처음에 파일 메타데이터(예: 타임스탬프, 이름, 경로 등)를 설명하는 전체 페이지(YAFFS 용어로는 청크)를 쓴다. 새 파일에는 고유한 개체 ID 번호가 할당되며, 파일 내의 모든 데이터 청크에는 여유 영역 내에 이 고유한 개체 ID가 포함된다. YAFFS는 이러한 청크의 물리적 위치에 대한 RAM의 트리 구조를 유지 관리한다. 청크가 더 이상 유효하지 않으면(파일이 삭제되거나 파일의 일부가 덮어쓰여진 경우) YAFFS는 청크의 여유 영역에 있는 특정 바이트를 '더티'로 표시한다. 전체 블록(32페이지)이 더티로 표시되면 YAFFS는 블록을 지우고 공간을 회수할 수 있다. 파일 시스템의 여유 공간이 부족하면 YAFFS는 유효한 페이지 그룹을 새 블록으로 통합한다. 그런 다음 YAFFS는 원래 블록 내의 더티 페이지가 사용하던 공간을 회수한다.
YAFFS 시스템이 마운트할 때 NAND 플래시 장치는 여유 영역을 스캔하여 유효한 데이터를 확인하기 위해 각 블록을 방문해야 한다. 이 정보를 사용하여 메모리 상주 트리 데이터 구조를 재구성한다.
YAFFS2.
YAFFS2는 YAFFS1과 개념이 유사하며 많은 코드를 공유한다. YAFFS2 코드베이스는 하위 호환성을 통해 YAFFS1 데이터 형식을 지원한다. 주요 차이점은 YAFFS2가 최신 NAND 플래시의 "한 번 쓰기" 요구 사항을 충족하기 위해 상당한 노력을 기울여야 한다는 점이다.
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 파일 시스템은 여섯 가지 구성 요소를 갖는다.
Bcachefs는 리눅스 기반 운영체제를 위한 카피 온 라이트(COW) 파일 시스템이다. 주요 개발자인 켄트 오버스트리트가 2015년에 처음 발표했으며, 리눅스 커널 6.7부터 리눅스 커널에 추가되었다. 이는 ZFS 또는 Btrfs의 최신 기능과 경쟁하기 위해 만들어졌다. 2025년 6월, 리누스 토르발스는 커널 개발 가이드라인을 반복적으로 위반한 결과 bcachefs가 커널에서 제거될 것이라고 발표했다. 2025년 8월, bcachefs의 상태는 '지원됨'에서 '외부에서 유지 관리됨'으로 변경되었다.
2025년 9월 말, 리누스 토르발스는 리눅스 커널 버전 6.17부터 모든 Bcachefs 코드를 제거했다. 이제 외부 모듈로 사용할 수 있다.
Bcachefs는 리눅스 기반 운영체제를 위한 카피 온 라이트(COW) 파일 시스템이다. 특징으로는 캐싱, ChaCha20 및 Poly1305 알고리즘을 사용한 완전한 파일 시스템 암호화, LZ4, gzip 및 Zstandard를 통한 기본 데이터 압축, 스냅샷, CRC-32C 및 64비트 체크섬 기능이 있다. RAID 구성을 포함하여 블록 장치에 걸쳐 있을 수 있다.
초기 Bcachefs 버전은 리눅스용 블록 계층 캐시 시스템인 Bcache의 모든 기능을 제공했으며, Bcachefs는 Bcache와 코드의 약 80%를 공유한다. 2021년 12월 현재 블록 계층 캐시 기능은 제거되었다.
데이터 구조 수준에서 bcachefs는 다른 많은 최신 파일 시스템처럼 B 트리를 사용하지만, 기본값이 256KiB로 비정상적으로 큰 노드 크기를 가진다. 이 노드들은 내부적으로 로그 구조화되어 하이브리드 데이터 구조를 형성하며, 업데이트 시 노드를 다시 쓰는 필요성을 줄인다. 스냅샷은 COW 트리를 복제하여 구현되지 않고, 파일 시스템 객체에 버전 번호를 추가하여 구현된다.
COW 기능과 버킷 할당기는 쓰기 홀이나 IO 조각화 문제로 고통받지 않는다고 주장되는 RAID 구현을 가능하게 한다. 반면에 버킷 할당기는 대부분 비어있는 버킷을 처리하기 위해 복사 가비지 컬렉터의 사용을 필요로 한다.
Bcachefs는 스스로를 "작동하고 안정적이며, 소수의 사용자 커뮤니티를 가지고 있다"고 설명한다. 2024년 4월 7일 리눅스 6.9-rc3에 대해 논의하면서 리누스 토르발스는 bcachefs의 안정성에 대해 언급하며 "bcachefs가 이미 안정적이라고 생각했다면, 내가 당신에게 팔 다리가 있다"고 말했다. 그리고 2024년 8월에는 "제정신인 사람은 아무도 bcachefs를 사용하고 안정적일 것이라고 기대하지 않는다"고 말했다.
2024년 8월, "사용자 공간 도구 및 문서"를 제공하는 패키지인 bcachefs-tools의 데비안 유지 관리자는 패키지를 고아로 지정하며 장기 지원 가능성에 의문을 제기했다. 유지 관리자는 블로그 게시물에서 "가까운 미래에 어떤 종류의 프로덕션 용도로든 bcachefs를 사용할 것을 고려한다면, 먼저 장기적으로 얼마나 지원 가능한지, 그리고 그것을 안정적으로 지원하는 데 성공한 사람이 정말 아무도 없는지 고려해야 한다"고 덧붙였다.
주요 개발은 Bcachefs의 아이디어의 "프로토타입"이라고 설명하는 Bcache의 개발자인 켄트 오버스트리트에 의해 이루어졌다. 오버스트리트는 Bcachefs가 Bcache를 대체할 의도였다. 오버스트리트는 Bcachefs 개발이 Bcache 개발자들이 코드베이스가 "...완전히 성장한 범용 POSIX 파일 시스템으로 진화하고 있다"는 것을 깨달았을 때 시작되었으며, 그 방향으로 나아간다면 "정말 깨끗하고 우아한 디자인"이 그 안에 있을 것이라고 말했다. 2013년 Bcache가 주류 리눅스 커널에 병합된 후 얼마 지나지 않아 오버스트리트는 구글에서 직장을 떠나 Bcachefs에 전념하기 시작했다.
수년간의 무자금 개발 후, 오버스트리트는 2015년에 Bcachefs를 발표했으며, 당시 그는 코드를 "거의 기능이 완성되었다"고 부르며 테스터와 기여자들을 모집했다. 그는 ext4 및 XFS와 같은 파일 시스템의 속도와 성능을 가지면서 ZFS 또는 Btrfs와 같은 스냅샷, 압축 및 캐싱과 같은 최신 기능을 갖춘 고급 파일 시스템이 되기를 의도했다. 2017년 현재 오버스트리트는 Patreon을 통해 Bcachefs 개발을 위한 재정 지원을 받고 있었다.
2018년 중반 현재, 디스크 상의 형식은 정착되었다. Bcachefs를 주류 리눅스 커널에 포함시키기 위한 패치가 검토를 위해 제출되었다.
2019년 중반까지 Bcachefs의 원하는 기능이 완성되었고, LKML에 관련 패치가 동료 검토를 위해 제출되었다. 2023년 10월 Bcachefs는 리눅스 6.7 커널에 병합되었고, 이는 2024년 1월에 출시되었다.
2024년 11월, 켄트 오버스트리트는 "다른 커뮤니티 구성원에 대한 서면 남용"과 "개인적인 공격에 대한 두려움 없이 생산적인 기술적 논의를 할 수 있는 커뮤니티의 신뢰를 회복하기 위한 불충분한 조치"로 인해 리눅스 행동 강령 위원회로부터 리눅스 6.13 커널 개발 주기 동안 기여를 보내는 것이 제한되었다. 패치는 나중에 리눅스 6.14 커널 개발 동안 문제없이 수락되었다.
2025년 6월, 리누스 토르발스는 bcachefs가 리눅스 커널에서 제거될 것이라고 발표했다. 리누스는 다음과 같이 설명했다.
2025년 8월, 리눅스 6.17에 대한 bcachefs 업데이트를 병합하지 않은 후, 토르발스는 리눅스 커널에서 bcachefs를 "외부에서 유지 관리됨"으로 표시했다. 2025년 9월, 오버스트리트는 bcachefs가 DKMS 모듈로 배포될 것이라고 발표했다.
트랜잭션-안전 FAT 파일 시스템(Transaction-Safe FAT File System, TFAT) 및 트랜잭션-안전 확장 FAT 파일 시스템(Transaction-Safe Extended FAT File System, TexFAT)은 마이크로소프트 제품에서 디스크에 저장된 데이터에 대한 트랜잭션 안전을 제공하기 위해 사용되는 두 가지 파일 시스템을 지칭한다. 목표는 전원 손실 또는 드라이브의 예기치 않은 제거 시 데이터 손실 위험을 줄이는 것이다. 후자의 문제는 USB 드라이브의 확산과 함께 더 흔해졌다.
TFAT.
TFAT12, TFAT16, TFAT32 파일 시스템의 트랜잭션-안전 FAT 파일 시스템(TFAT)은 원래의 FAT 파일 시스템인 FAT12, FAT16, FAT32에 대한 드라이버 계층 수정으로, 두 개의 동일한 파일 할당 테이블 대신 두 개의 복사본(FAT 0 및 FAT 1)을 유지한다. 드라이브 작업을 수행하는 동안 변경 사항은 FAT 1에 적용된다. 작업이 완료되면 FAT 1 테이블이 FAT 0으로 복사되어 파일 시스템의 안정적인 뷰를 업데이트한다.
TexFAT.
트랜잭션-안전 확장 FAT 파일 시스템(TexFAT)은 exFAT 파일 시스템을 기본 파일 시스템으로 사용하여 TFAT와 유사한 기능을 제공한다. 윈도우 임베디드 CE 6.0과 함께 도입되었으며, 때로는 TFAT라고도 불리는데, 이는 위에 설명된 원래 TFAT와 혼동을 일으킬 수 있다.
기본 파일 시스템으로 exFAT를 사용하면 더 큰 파일과 더 큰 파티션을 허용한다. TexFAT는 TexFAT 볼륨이 있는 미디어 유형에 맞게 설계된 하드웨어 특정 드라이버가 필요하다. TexFAT는 Windows 데스크톱/서버 버전에서 지원되지 않는다.
데스크톱 운영체제의 지원 부족으로 인해 TFAT와 TexFAT 모두 이동식 미디어에 권장되지 않는다. 데스크톱 OS는 드라이브를 여전히 읽을 수 있지만, 트랜잭션 안전 기능을 사용할 수 없으므로 예기치 않은 제거 또는 정전으로 인해 데이터 손실이 발생할 수 있다. 또한, 데스크톱 OS에서 생성된 디렉토리는 나중에 TFAT/TexFAT 인식 운영체제에 드라이브가 연결되더라도 트랜잭션 안전하지 않을 수 있다.
cramfs(compressed ROM/RAM 파일 시스템의 약자)는 단순함과 공간 효율성을 위해 설계된 자유(GPL로 배포되는) 읽기 전용 리눅스 파일 시스템이다. 주로 임베디드 및 작은 설치 공간의 시스템에서 사용된다.
기존 파일 시스템의 압축 이미지와 달리 cramfs 이미지는 먼저 압축을 해제하지 않고도 그대로 사용할 수 있다. 이러한 이유로 일부 리눅스 배포판은 메모리 및 이미지 크기 제약이 있는 initrd 이미지(특히 데비안 3.1) 및 설치 이미지(특히 수세 리눅스)에 cramfs를 사용한다.
2013년에 리눅스 관리자들은 cramfs가 SquashFS에 의해 구식화되었다고 밝혔지만, 2017년에는 SquashFS 사용이 불가능할 수 있는 저용량 메모리 장치에서 사용하기 위해 이 파일 시스템이 복원되었다.
cramfs 파일 시스템의 파일은 무작위 읽기 접근을 허용하기 위해 한 페이지씩 Zlib으로 압축된다. 메타데이터는 압축되지 않지만, 기존 파일 시스템보다 공간 효율적인 간결한 표현으로 되어 있다.
파일 시스템은 의도적으로 읽기 전용으로 설계되어 디자인을 단순화했다. 압축된 파일에 대한 무작위 쓰기 접근은 구현하기 어렵다. cramfs는 새 cramfs 이미지로 파일을 압축하는 유틸리티(codice_1)를 함께 제공한다.
파일 크기는 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는 자유 (LGPL) FUSE 기반의 암호화 파일 시스템이다. 임의의 디렉터리를 암호화된 파일을 위한 저장 공간으로 사용하여 파일을 투명하게 암호화한다.
EncFS 파일 시스템을 마운트하는 데 두 개의 디렉터리가 관여한다: 원본 디렉터리와 마운트 지점. 마운트 지점의 각 파일은 원본 디렉터리에 해당하는 특정 파일을 갖는다. 마운트 지점의 파일은 원본 디렉터리에 있는 파일의 암호화되지 않은 보기를 제공한다. 파일 이름은 원본 디렉터리에서 암호화된다.
파일은 볼륨 키를 사용하여 암호화되며, 이 키는 암호화된 원본 디렉터리 내부에 또는 외부에 저장된다. 이 키를 해독하는 데 비밀번호가 사용된다.
EncFS는 개발자인 발리앙 고흐가 2024년 5월 GitHub 페이지에서 더 이상 업데이트 없이 휴면 상태라고 선언했다. 그는 대신 gocryptfs를 사용하는 것을 권장한다.
EncFS는 각 파일이 호스트의 디렉터리 트리의 다른 곳에 암호화된 파일로 개별적으로 저장된다는 이유만으로 다른 디스크 암호화 소프트웨어에 비해 몇 가지 장점을 제공한다.
교차 플랫폼.
EncFS는 여러 플랫폼에서 사용할 수 있는 반면, eCryptfs는 리눅스 커널에 종속된다.
비트 부패 감지.
EncFS는 기본 파일 시스템 위에 비트 부패 감지 기능을 구현한다.
확장 가능한 저장 공간.
EncFS는 고정된 크기를 차지하는 "볼륨"이 없으며, 마운트 지점에 파일이 추가되거나 제거됨에 따라 암호화된 디렉터리가 늘어나고 줄어든다.
일반 파일 서버.
EncFS의 암호화된 디렉터리는 일반 파일 서버(NFS, SSHFS 등)에 위치할 수 있으며, Rsync와 같은 일반 파일 시스템 도구를 사용하여 효율적으로 미러링 및 백업할 수 있다.
다른 물리적 장치.
원본 디렉터리의 하위 디렉터리 중 하나에 파일 시스템이 마운트된 경우, 마운트 지점의 일부 디렉터리가 다른 물리적 장치에 존재할 수 있다.
더 빠른 백업.
백업 유틸리티는 원본 디렉터리에서 변경된 파일만 백업할 수 있다(파일 동기화, 클라우드 스토리지).
손상 감소.
데이터 손상이 더욱 격리된다. 파일 데이터 손상은 단일 파일에 국한되며, 파일 시스템의 데이터 손상은 fsck와 같은 신뢰할 수 있는 파일 시스템 복구 유틸리티로 수정할 수 있다. 일부 전체 디스크 암호화 시스템은 이러한 속성 중 하나 또는 둘 다를 가지고 있지 않다.
파일 수정 사항이 기본 파일 시스템에 반영되므로, 전체 디스크 암호화와 달리 운영 체제의 다양한 최적화가 여전히 가능하다. 예를 들어, 해제된 공간에 대한 정보(TRIM)를 전달하면 SSD 드라이브의 성능을 향상시킬 수 있다. 하지만 이는 dm-crypt에서도 지원된다.
임의 파일 접근.
파일에 임의로 접근할 수 있다. 예를 들어, 매우 큰 암호화된 비디오 파일 전체를 해독하지 않고도 중간으로 건너뛸 수 있다.
EncFS를 사용하는 데에는 몇 가지 단점이 있다.
마운트된 EncFS 디렉터리는 원본 디렉터리를 포함하는 파일 시스템과 동일한 기능 및 제한 사항을 공유한다.
매우 긴 파일 이름에 대한 지원 없음.
암호화 때문에 EncFS가 생성하는 암호화된 파일의 파일 이름은 원래 파일 이름보다 길다. 따라서 파일 시스템이 지원하는 최대 길이에 가까운 파일 이름은 암호화 후 길이 제한을 초과하므로 EncFS에 저장할 수 없다. 대부분의 파일 시스템은 파일 이름을 255바이트로 제한한다. 이 경우 EncFS는 최대 190바이트의 파일 이름만 지원한다.
일반적인 보안 문제.
원본 디렉터리에 접근할 수 있는 사람은 누구든지 암호화된 파일 시스템에 파일이 몇 개 있는지, 파일 권한, 대략적인 크기, 마지막 접근 또는 수정 시간을 볼 수 있지만, 파일 이름과 파일 데이터는 암호화되어 있다.
EncFS 1.7 보안 문제.
2014년 2월에 유료 보안 감사가 수행되었으며, 몇 가지 잠재적 취약점이 발견되었다. 결론은 다음과 같다.
EncFS 1.8 보안 문제.
EncFS 1.8 발표에는 이전 감사에서 제기된 보안 문제를 인정한 몇 가지 근본적인 설계 변경 사항이 포함되었다. 그러나 이러한 취약점에 대한 특정 우려 사항은 여전히 남아 있다.
파일 시스템 옵션.
새 EncFS 볼륨을 생성할 때, 다양한 요구에 맞게 파일 시스템을 사용자 정의할 수 있는 여러 옵션이 제공된다.
EncFS는 시스템의 다양한 암호화 라이브러리에서 찾을 수 있는 모든 암호를 사용한다. 블로피시와 AES가 일반적으로 사용 가능하다.
가변 키 길이를 지원하는 암호에 대해 암호화 키 길이(keySize)를 선택할 수 있다.
블록 크기.
각 파일은 블록 단위로 암호화되며, 이 옵션은 블록의 크기를 제어한다. 단일 바이트가 읽힐 때마다 해당 블록 전체가 해독되어야 한다. 마찬가지로, 각 쓰기 작업에 대해 블록은 해독되고, 변경되고, 다시 암호화되어야 한다.
대부분의 목적에는 기본 블록 크기인 1024가 충분하다.
파일 이름 인코딩.
원본 디렉터리의 파일 이름은 일반 또는 블록 또는 스트림 모드로 암호화될 수 있다. 블록 모드는 파일 이름 길이를 다소 가리지만, 스트림 모드는 가능한 한 짧게 유지하므로 파일 시스템이 디렉터리 트리를 관리하는 방식에 따라 원본 디렉터리의 파일 시스템에서 공간을 절약할 수 있다.
파일 이름 IV 체이닝.
활성화되면 파일 이름 암호화를 위한 초기화 벡터가 파일의 상위 디렉터리에서 파생되어, 같은 이름을 가진 두 파일(다른 디렉터리에 있지만)이 다른 암호화된 파일 이름을 갖게 된다.
디렉터리 이름이 변경되면 그 안에 포함된 모든 파일과 디렉터리의 암호화된 파일 이름을 다시 암호화해야 하며, 이는 비용이 많이 드는 작업이 될 수 있다. 이 옵션은 매우 많은 파일이 있는 디렉터리가 자주 이름이 변경될 경우 비활성화해야 한다.
파일당 IV 초기화 벡터.
활성화되면 각 파일은 무작위 8바이트 초기화 벡터로 암호화되며, 이는 원본 디렉터리의 암호화된 파일 내부에 저장된다. 이 옵션이 비활성화되면 각 파일은 동일한 초기화 벡터로 암호화되어 볼륨 키를 해독하기 더 쉽게 만들 수 있다.
이 옵션을 활성화하면 파일당 추가 8바이트의 비용으로 파일 시스템이 더 안전해진다.
외부 IV 체이닝.
파일 데이터 초기화 벡터가 파일 이름의 초기화 벡터 체인에서 파생되도록 한다. 동일한 데이터는 다른 파일 이름이나 디렉터리가 주어지면 다르게 암호화된다.
결과적으로, 이 모드가 활성화된 상태에서 파일 이름을 변경하려면 파일의 무작위 초기화 벡터가 파일 이름 초기화 벡터 체인의 변경 사항에 따라 오프셋되거나 데이터가 다시 인코딩되어야 한다. EncFS 개발자들은 후자가 특히 큰 파일의 경우 훨씬 빠르기 때문에 전자를 선택했다.
파일 이름에서 IV 헤더 체이닝.
인코딩이 전체 경로 이름에 의존하도록 한다. 따라서 이름 변경이나 이동은 다시 인코딩을 의미한다. 하드 링크는 지원되지 않는다.
블록 MAC 헤더.
각 암호화된 블록과 함께 체크섬을 저장하여 암호화된 파일의 손상 또는 수정을 EncFS가 감지하도록 한다. 체크섬(blockMACBytes)은 8바이트이며, 선택적으로 최대 8바이트의 추가 임의 데이터(blockMACRandBytes)를 각 블록에 추가하여 동일한 암호화되지 않은 데이터를 가진 두 블록이 동일한 체크섬을 갖는 것을 방지할 수 있다. 이 옵션은 CPU 오버헤드가 많이 발생하는데, 데이터가 읽히거나(무결성 확인) 쓰일 때마다(체크섬 업데이트) 각 블록의 체크섬을 계산해야 하기 때문이다.
오토모티브 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라는 이름은 상표법으로 보호되며 VDA의 자산이다.
역량 수준.
역량 수준은 총 6단계가 있으며, 레벨(Levels)이라고 불린다. 레벨 0은 가장 낮은 역량 수준이고, 레벨 5는 가장 높은 역량 수준이다. 각 프로세스의 역량 수준은 다음과 같이 명명되고 특징 지어진다.
오토모티브 SPICE 평가.