shopkeeper/kowiki-cleaned-020126 huggingface dataset:
친유성

친유성(lipophilicity)은 화합물이 지방, 기름, 지질 (생물학) 및 헥세인 또는 톨루엔과 같은 비극성 용매에 용해되는 능력이다.이라고 부른다. 이러한 비극성 용매는 그 자체로 친유성이다. 따라서 친유성 물질은 다른 친유성 물질에 용해되는 경향이 있는 반면, 친수성("물을 좋아하는") 물질은 물 및 다른 친수성 물질에 용해되는 경향이 있다.

친유성, 소수성 및 비극성은 종종 상호 교환적으로 사용되는 용어이므로 런던 분산력에 참여하는 동일한 경향을 설명할 수 있다. 그러나 "친유성"과 "소수성"이라는 용어는 동의어가 아니며, 실리콘 및 플루오로카본에서 볼 수 있듯이 이들은 소수성이지만 친유성은 아니다.

 계면활성제 
탄화수소 기반의 계면활성제는 양친매성 화합물로서, 친수성이며 물과 상호작용하는 "머리 그룹"과 친유성 "꼬리"로 불리는 긴 사슬 탄화수소 조각으로 구성된다. 이들은 공기-물 계면(낮은 표면장력) 및 기름/물 유화액에서 발견되는 물과 섞이지 않는 방울의 표면(낮은 계면장력)을 포함한 낮은 에너지 표면에 모인다. 이 표면에서 이들은 머리 그룹을 물 속에, 꼬리는 위로 뻗어 물 밖으로 나오거나 (공기-물 계면에서와 같이) 물과 접촉하는 물과 섞이지 않는 상(예: 유화된 기름 방울)에 용해된 상태로 자연스럽게 정렬된다. 이 두 구성 모두에서 머리 그룹은 물과 강력하게 상호작용하는 반면 꼬리는 물과의 모든 접촉을 피한다. 계면활성제 분자들은 또한 마이셀을 형성하여 물 속에서 머리 그룹이 바깥으로 향하고 꼬리는 함께 뭉쳐진다. 마이셀은 기름진 물질을 소수성 핵 안으로 끌어들여 개인 위생 및 세탁에 사용되는 비누와 세제의 기본 작용을 설명한다. 마이셀은 또한 소장에서 지방 물질의 운반에 생물학적으로 중요하며, 이는 지방 성분(주로 지방산 및 2-모노글리세리드)의 흡수로 이어지는 첫 번째 단계이다.

세포막은 주로 인지질로 형성된 이중층 구조이며, 이 인지질 분자는 두 개의 긴 알킬 꼬리에 고도로 물과 상호작용하는 이온성 인산염 머리 그룹이 부착되어 있다.

이와 대조적으로, 불소계 계면활성제는 플루오로카본이 친유성이 아니기 때문에 양친매성이 아니며 세제도 아니다.

자외선 차단제에 흔히 사용되는 일반적인 화장품 성분인 옥시벤존은 친유성이 그다지 높지 않기 때문에 피부에 특히 잘 침투한다. 한 번의 국소 자외선 차단제 도포 후 옥시벤존의 0.4%에서 8.7%가 흡수될 수 있으며, 이는 소변 배설에서 측정된다.

 같이 보기 
 이온 분배 다이어그램
 ITIES
 친유성 박테리아
 소유성
 마이크로에멀젼

 각주 

분류:화학적 성질
헤테로고리 아민

thumb|right|175px|많은 생명체에 필수적인 나이아신은 헤테로고리 아민의 한 예이다.
헤테로고리 아민, 헤테로사이클릭 아민(Heterocyclic amine), 이종환식 아민 또는 HCA는 적어도 두 가지 다른 원소의 원자를 포함하는 헤테로고리 고리 하나 이상과 아민(질소 함유) 그룹 하나 이상을 포함하는 화합물이다. 일반적으로 고리를 헤테로고리로 만드는 것은 아민 그룹의 질소 원자이다(피리딘 등). 하지만 그렇지 않은 화합물도 존재한다(질류톤 등). 헤테로고리 아민의 생물학적 기능은 비타민과 발암물질을 포함하여 다양하다. 발암성 헤테로고리 아민은 고온으로 고기를 요리하고 담배와 같은 식물 물질을 흡연할 때 생성된다. 잘 알려진 헤테로고리 아민으로는 나이아신(비타민 B3), 니코틴(정신활성 알칼로이드 및 기분 전환 약물), 그리고 DNA에서 유전 정보를 암호화하는 핵염기가 있다.

 5원자 헤테로고리 아민 
피롤리딘 화합물은 5개의 원자로 구성된 포화 고리를 포함하는 분자로 이루어져 있다. 이 고리 구조는 질소 원자 하나와 탄소 원자 네 개로 구성된다.
니코틴은 피리딘 고리(다른 헤테로고리 아민)에 피롤리딘 고리가 붙어 있는 분자이다. 니코틴은 질소를 포함하는 자연 발생 유기 화합물인 알칼로이드로 알려진 화합물 그룹에 속한다.
피롤은 5원자 헤테로고리 고리를 가진 분자로 이루어진 또 다른 화합물이다. 이 분자들은 불포화 상태이며 고리 안에 질소 원자를 포함한다. 네 개의 피롤 고리가 포르피린이라는 고리 구조로 결합되어 있다.
포르피린 고리는 헤모글로빈, 미오글로빈, 비타민 B12, 엽록소, 그리고 사이토크롬의 구성 요소이다. 헤모글로빈, 미오글로빈, 사이토크롬의 헴 중심에는 철이 이온 형태로 존재하며, 처음 두 가지에서는 철 이온이 산소와 결합한다.

 6원자 헤테로고리 아민 
피리딘의 구조는 질소 원자 하나가 탄소 원자 하나를 대체한다는 점을 제외하면 벤젠과 유사하다. 피리딘은 향미제로 사용된다. 피리딘 고리는 두 가지 비타민 B인 나이아신과 피리독신의 일부이다.
니코틴산이라고도 불리는 나이아신은 대부분의 유기체에서 발견된다. 대사를 통해 니코틴아미드 아데닌 다이뉴클레오타이드(NAD)가 되는데, 이는 대사 세포에서 산화 및 환원에 관여하는 조효소이다. 나이아신 결핍은 펠라그라라는 질병을 유발한다.
피리독신 또는 비타민 B6는 아미노산 대사에서 주요 화합물이 된다.

피리미딘은 불포화 6원자 고리에 두 개의 질소 원자를 포함하는 헤테로고리 아민이다. 피리미딘을 포함하는 분자의 예는 티아민으로, 비타민 B1으로도 알려져 있다. 티아민 결핍은 각기병을 유발한다.
피리미딘은 핵염기인 사이토신, 우라실, 티민의 구성 요소이다. 다른 두 핵염기인 아데닌과 구아닌도 퓨린이라고 불리는 헤테로고리 아민이다. 이들은 융합된 피리미딘과 이미다졸로 구성된다.

 헤테로고리 아민과 암 
thumb|right|250px|고온 조리(특히 그슬림)된 고기는 일부 암 유발 헤테로고리 아민을 생성한다.
조리된 고기, 특히 타버린 고기에서 발견되는 일부 HCA는 알려진 발암물질이다. 연구에 따르면 고기에서 헤테로고리 아민 생성은 높은 조리 온도에서 발생한다. 헤테로고리 아민은 쇠고기, 양고기, 돼지고기, 생선, 가금류와 같은 근육 고기를 조리할 때 형성되는 발암성 화학물질이다. HCA는 높은 조리 온도에서 아미노산과 크레아틴(근육에서 발견되는 화학물질)이 반응할 때 형성된다.

대장암은 고온으로 조리된 고기에서 발견되는 HCA를 많이 섭취하는 것과 관련이 있다.

맥주나 레드 와인에 6시간 동안 재운 소고기 스테이크는 양념하지 않은 스테이크에 비해 두 가지 유형의 HCA 수치를 최대 90%까지 감소시켰다.

 헤테로고리 아민과 신경계 질환 
육류에서 발견되는 β-카르볼린 알칼로이드인 하르만은 "매우 떨림 유발적"이다. 하르만이 본태성진전 환자에서 대조군보다 약 50% 더 높은 농도로 발견되었지만, 혈중 농도와 일일 육류 섭취량 간에 직접적인 상관관계는 없으며, 이는 이 화학물질의 대사 차이가 더 큰 역할을 한다는 것을 시사한다. 이 화학물질들은 고기 조리 과정에서 형성되며, 특히 더 오래 조리되고 조리 중 높은 온도에 더 많이 노출될수록 더 많이 형성된다.

 같이 보기 
 고기 헤테로고리 아민 생성
 다환 방향족 탄화수소

 각주 

 외부 링크 

분류:헤테로고리 화합물
분류:발암 물질
캘리포니아 교통부

캘리포니아 교통부(California Department of Transportation, Caltrans)는 미국 캘리포니아주의 교통·운송 담당 행정 부처로, 내각급 캘리포니아주 교통국 산하 기관이다. 청사는 새크라멘토에 있다.

캘리포니아주 내 고속도로 및 주 전역의 대중교통 체계를 관리한다.

 각주 

분류:캘리포니아 교통국
요리학교

섬네일|잉글랜드 옥스퍼드에 있는 레이먼드 블랑 요리학교의 한 수업

요리학교, 쿠킹 스쿨(cooking school)는 요리와 음식 준비 기술 및 과학 교육에 전념하는 기관이다. 전 세계에는 다양한 종류의 요리학교가 있으며, 일부는 전문 요리사 양성에, 일부는 아마추어 애호가를 대상으로 하며, 일부는 이 둘의 혼합이다. 아마추어 요리학교는 많은 나라에서 음식 관광과 종종 얽혀 있다. 프로그램은 반나절에서 수년까지 다양할 수 있다. 일부 프로그램은 학위 또는 공인된 직업 자격으로 이어지는 반면, 다른 프로그램은 그렇지 않다. 많은 프로그램에는 학교에 딸린 음식점 주방에서의 실습 경험 또는 개인 소유 음식점에서의 일정 기간의 직업 경험이 포함된다.

역사
섬네일|right|upright|마거리트 마틴의 이 스케치에서 1913년 미주리주 세인트루이스에서 아나 배로우스가 성인 요리 강좌를 가르치고 있다.
미국의 요리 교육은 유럽의 요리 교육에 비해 비교적 새로운 개념이다. 초기 파인 다이닝 음식점인 델모니코스의 셰프였던 찰스 랜호퍼는 1898년에 "Chef"라는 전국 잡지를 발행했으며, 여기에는 미국에서 요리사 훈련 학교를 설립하라는 최초의 요청 중 하나가 포함되어 있었다. 이때까지 랜호퍼는 직원 문제 해결을 위해 유럽을 찾고 있었지만, 너무 비싸고 힘든 일이 되기 시작했다. 1911년 미국은 견습생이 요리사 자격을 얻기 위해 6,000시간의 근로 의무를 이수해야 하는 유럽과 유사한 시스템을 추진했다.

미국 최초의 중요한 사립 요리학교는 1878년에 설립된 보스턴 쿠킹 스쿨이었지만, 가장 주목할 만한 학교 중 하나는 1946년에 설립된 더 컬리너리 인스티튜트 오브 아메리카였다. 더 컬리너리 인스티튜트 오브 아메리카는 학생들이 미래의 작업 이론을 배우고, 승인된 음식점에서 18주간의 유급 인턴제를 이수하며, 제품의 51% 이상을 처음부터 만들어야 하는 새로운 방식으로 요리 전문가를 교육했다. 이 학교는 주로 실습 위주의 교육 방식을 사용하여 학생들이 경험을 통해 배우도록 한다.

커리큘럼
섬네일|인도 첸나이 벨스 대학교 호텔 경영대학의 요리 실습
르 꼬르동 블루와 같은 일부 학교는 요리사가 자신의 지식과 기술을 시연하고 자격증을 받을 수 있는 프로그램을 제공한다. 볼티모어 국제 대학, 스트랫퍼드 대학교, 존슨 앤 웨일즈 대학교, 더 컬리너리 인스티튜트 오브 아메리카와 같은 다른 학교는 학생들이 전문학사 또는 학사 학위를 취득하는 프로그램을 제공한다. 인디애나의 아이비 테크 커뮤니티 칼리지, 코네티컷의 맨체스터 커뮤니티 칼리지 (코네티컷), 캘리포니아의 로스앤젤레스 무역 기술 대학과 같이 졸업 시 준학사 학위뿐만 아니라 북아메리카에서 가장 큰 전문 요리사 단체인 미국 요리 연맹의 인증을 받는 곳도 있다.

주목할 만한 요리 대학

 아트 인스티튜트 요리학교
 오귀스트 에스코피에 요리 예술 학교
 볼티모어 국제 대학
 케임브리지 요리 예술 학교
 시카고 요리 및 호텔 경영 연구소
 컬리나드, 버지니아 칼리지 요리 연구소
 더 컬리너리 인스티튜트 오브 아메리카
 컬리너리 인스티튜트 르노트르
 DCT 대학교 센터 - 스위스
 에콜 그레구아르 페랑디
 요리 교육 연구소
 국제 요리 센터
 국제 요리 예술 센터-ICCA
 존슨 앤 웨일즈 대학교
 켄달 칼리지 - 요리 예술 학교
 르 꼬르동 블루
 로스앤젤레스 무역 기술 대학
 뉴잉글랜드 요리 연구소
 나이아가라 폭포 요리 연구소
 폴 스미스 칼리지
 스쿨크래프트 칼리지
 스트랫퍼드 대학교
 설리번 대학교
 서부 요리 연구소

 같이 보기 

 음식 관광
 직업교육
 직업능력개발훈련시설

 내용주 

 각주 

 외부 링크 

 미국 요리 연맹 - 학교

 
분류:학교 유형
석핵

thumb|right|250px|뗀석기를 위한 석핵 - 후기 구석기 시대 (그라베트 문화) (–29,000 ; –22,000) -프랑스 랑드 데파르트망 브라상푸이 - 툴루즈 박물관
고고학에서 석핵(石核, lithic core)은 뗀석기 과정의 결과로 생성된 독특한 유물이다. 이 의미에서 석핵은 일반적으로 망치돌과 같은 단단한 망치 선구자를 사용하여 원재료 또는 석기 덩어리에서 하나 이상의 뗀석기 조각이 떨어져 나간 흔적이 있는 중심부를 말한다. 석핵에는 이러한 조각들의 음각 흔적이 남아 있다. 조각들을 떼어내기 위해 타격을 가했던 석핵의 표면 영역을 타격면이라고 한다. 석핵은 버려지거나 일부 유형의 주먹도끼에서 볼 수 있듯이 '석핵 도구'로 추가로 가공될 수 있다.

 정의 
"석핵"은 고고학자의 이론적, 방법론적 접근 방식에 따라 여러 가지 방식으로 정의될 수 있다. 석핵을 분류하는 유형학적 접근 방식은 일반적으로 유물의 기술적 속성과 추정되는 기능을 결합하여 기반을 두는 반면, 기술적 접근 방식은 일반적으로 기술적 속성과 전체 뗀석기 과정에서 유물의 위치에만 기반을 둔다. 석핵에 사용되는 다른 용어로는 "핵" 또는 "객체"가 있다.

 기능 
thumb|left|upright=0.7|스페인 아스투리아스주 라비냐 동굴 근처에서 발견된 부싯돌 돌날 석핵
석핵을 가공하는 목적은 나중에 투사체 촉, 나이프 또는 기타 석기로 정교하게 다듬을 공백을 거칠게 만드는 것일 수도 있고, 다양한 단순 도구를 만들 수 있는 날카로운 뗀석기 조각을 얻기 위해 수행될 수도 있다. 일반적으로 석핵의 존재는 후자의 과정을 나타내는데, 전자의 과정은 보통 석핵을 남기지 않기 때문이다. 석핵의 형태는 조각의 모양에 영향을 미치므로, 석핵 표면 형태를 연구함으로써 길이와 두께를 포함한 차원 조각 속성에 대한 더 많은 정보를 알 수 있다.

 석핵의 유형 
석핵은 석기 분석가에 의해 특정 유형으로 세분화될 수 있다. 유형 빈도와 유적에서 발견되는 일반적인 재료 유형은 석기 분석가에게 해당 유적에서 발생하는 뗀석기 과정에 대한 더 나은 이해를 제공할 수 있다.

석핵은 조각 제거 방향, 음각 조각 흔적이 있는 면의 수 또는 석핵의 일반적인 형태를 기반으로 설명될 수 있다. 여기에는 다방향성, 원뿔형, 원통형, 양원뿔형 또는 양면 석핵이 포함된다. 다방향성 석핵은 임의의 암석에서 조각이 제거된 결과물이며, 더 이상 조각을 제거할 수 없을 때까지 암석의 기하학적 형태에 따라 조각이 제거되었다. 종종 다방향성 석핵은 명확한 타격면이 없을 때까지 이런 방식으로 사용된 다음, 석핵 자체가 유용한 조각을 생산하기에는 너무 작아질 때까지 양극성 뗀석기 과정을 통해 줄어든다. 원뿔형 석핵은 명확한 패턴을 가지고 있다. 석기의 좁은 끝에서 하나의 조각이 제거되었고, 이는 암석의 가장자리 전체에서 단면 방식으로 조각을 제거하는 타격면으로 사용되었다. 최종 결과는 원뿔형 모양이다. 원통형 석핵은 비슷한 방식으로 만들어지지만, 석기의 양쪽 끝에 타격면이 있으며, 양쪽 방향에서 원통 측면을 따라 조각이 위아래로 이어진다.
thumb|이스라엘 남부 막테시 가돌의 무스티에 문화 석핵.
thumb|right|alt=원통형 돌날 석핵의 선화. 이미지는 여섯 가지 시야 각도를 보여준다. 버크 박물관 고고학 컬렉션의 표본을 바탕으로 그렸다.|후기 구석기 시대 원통형 돌날 석핵, 프랑스. 버크 박물관 제공. 양원뿔형 석핵은 석기 가장자리 주변에 여러 개의 타격면이 있으며, 양쪽에서 번갈아 조각을 제거하여 바닥이 붙어 있는 한 쌍의 원뿔처럼 보인다. 양면 석핵은 양원뿔형 석핵과 유사하지만, 한 쌍의 원뿔을 형성하는 대신 조각이 석핵 자체가 더 얇아지도록 제거되며, 가장자리는 크게 줄어들지 않는다. 양면 석핵은 일반적으로 거래용 양면 석기, 양면 석기 공백 또는 양면 도구로 추가로 가공된다. 양면 석핵은 효율적인 재료 사용(특히 스크레이퍼 제작)을 가능하게 하는 기술이자, 고품질 석기 재료로 만든 도구를 필요로 하는 이동성이 높은 수렵채집 집단에 적합한 것으로 인식되었다.

 각주 

 외부 링크 
 

분류:유물 형태
분류:석기
분류:석기 시대
유베쓰 기법

은 1961년 일본의 학자 요시자키가 제안한 좀돌날을 만드는 특별한 기법으로, 홋카이도의 일부 후기 구석기 시대 유적지에서 발견된 유물들을 바탕으로 한다. 이 유적지들은 기원전 13,000년경으로 거슬러 올라간다.

이 이름은 유베쓰강에서 유래했는데, 그 강 우측 강변에서 시라타키 구석기 유적지가 발견되었다.

이 기법으로 좀돌날을 만들기 위해서는 큰 양면 가공 석기를 높은 용골형 스크레이퍼와 유사한 몸돌로 만든다. 그런 다음 양면 몸돌의 한쪽 측면 모서리를 제거하여 처음에는 삼각형의 박편을 만든다. 이어서 더 많은 모서리 제거를 통해 평행한 표면을 가진 스키 박편을 만들어낸다.

이 기법은 후기 홍적세 동안 몽골에서 캄차카 반도에 이르기까지 사용되었다.

 각주 
 江坂輝爾, 芹沢長介, 坂詰秀一, 『新日本考古学小辞典』（2005）p416
 千葉英一, 吉崎昌一, 横山英介, 「湧別技法」 『考古学ジャーナル』（1984）p229

분류:석기
분류:일본의 고고학
분류:후기 구석기 시대
바위그늘유적

섬네일|바위그늘유적
섬네일|소카르파티아산맥의 바위그늘

바위그늘유적(rock shelter, rockhouse, crepuscular cave, bluff shelter 또는 abri)은 절벽이나 낭떠러지 기슭에 있는 얕은 동굴 형태의 입구이다. 종종 몇 마일 길이 또는 폭에 달하는 석회암 동굴(카르스트)과 달리, 바위그늘은 거의 항상 크기와 범위가 작다.

형성
바위그늘은 침식과 풍화에 강한 사암과 같은 암석층이 절벽이나 낭떠러지를 형성했지만, 그 아래에 침식과 풍화에 더 취약한 부드러운 층이 놓여 절벽 아래를 깎아내면서 형성된다.

건조 지역에서는 바람 침식(풍식)이 바위그늘 형성에 중요한 요인이 될 수 있다. 대부분의 습한 지역에서는 바위그늘 형성의 가장 중요한 요소는 빙결 풍화 작용인데, 이는 아래의 더 부드럽고 다공성 암석이 공극에 얼어붙은 물의 얼음 팽창으로 인해 작은 조각으로 떨어져 나가는 현상이다. 흐르는 물에 의한 침식은 거의 중요한 요소가 아니다.

많은 바위그늘은 폭포 아래에서 발견된다.

인간 거주지
섬네일|라하울의 양치기 바위그늘
섬네일|left|upright|2017년 4월 이란 자그로스의 구석기 유적지 바와 야완 바위그늘에서 발굴된 퇴적물 체질
upright|섬네일|스트라우즈 런 주립공원의 바위그늘
바위그늘은 종종 고고학적으로 중요하다. 바위그늘이 날씨로부터 자연적인 피난처를 제공했기 때문에 선사시대 인류는 종종 이곳을 주거지로 사용했으며, 잔해, 도구 및 기타 유물을 남겼다. 산악 지역에서 바위그늘은 등산가들에게도 중요할 수 있다.

가축과 함께 이동하는 이동식 유목 생활 유목민, 즉 종종 계곡의 낮은 영구 겨울 거주지에서 더 높은 여름 목초지로 이동하는 사람들은 종종 바위로 된 준영구적인 캠프를 짓는다.

서부 코네티컷주와 동부 뉴욕주에서는 많은 바위그늘이 "레더맨 동굴"이라는 구어로 알려져 있는데, 이는 19세기 후반에 레더맨 (방랑자)가 30년 이상 이곳에 거주했기 때문이다.

독특한 식생
쿰벌랜드 스티치워트 (Minuartia cumberlandensis)는 켄터키와 테네시의 바위그늘에서만 발견되는 멸종 위기 식물 종이다.

 같이 보기 
 
 
 
 
 
 
 
 
 
 
 

 각주 

 추가 자료 
 Acosta et al., 2018. "Climate change and peopling of the Neotropics during the Pleistocene-Holocene transition". Boletín de la Sociedad Geológica Mexicana.

 외부 링크
28S 리보솜 RNA

섬네일|왈도속에 속하는 3종의 연체동물의 미토콘드리아 16S rDNA와 핵 28S rDNA의 계통수

28S 리보솜 RNA(, 28S rRNA)는 진핵생물에서 세포질 리보솜의 큰 소단위체(LSU)를 구성하는 리보솜 RNA(rRNA)로, 모든 진핵세포의 기본 구성 요소 중 하나이다. 식물에서는 크기가 25S이고 포유류에서는 크기가 28S이므로 25S–28S rRNA라는 별칭이 붙어 있다.

5' 쪽에 5.8S rRNA가 결합되어 있으며, 원핵생물의 23S rRNA 및 미토콘드리아의 16S rRNA와 유사한 진핵생물의 핵 상동체이다.

 계통학에서의 사용 
28S rRNA를 암호화하고 있는 유전자를 28S rDNA라고 한다. 이들 유전자의 서열을 비교하는 것은 때때로 분자 분석에 사용되며, 예를 들어 원생생물, 균류, 곤충류, 거미류, 완보동물, 척추동물의 계통수를 구축하는데 사용된다.

 구조 
28S rRNA는 일반적으로 4000–5000 nt 길이이다.

일부 진핵생물은 28S rRNA를 두 부분으로 절단한 후 리보솜에 조립하는데, 이 현상을 "숨겨진 절단(hidden break)"이라고 한다.

 데이터베이스 
다음의 몇몇 데이터베이스는 비교 목적으로 LSU rRNA 서열의 정렬과 주석을 제공한다.

 RDP: (리보솜 데이터베이스 프로젝트, Ribosomal Database Project)
 SILVA: 리보솜 RNA 유전자 데이터베이스 프로젝트이다.

 같이 보기 
 18S 리보솜 RNA (18S rRNA)
 23S 리보솜 RNA (23S rRNA)

 각주 

분류:리보솜 RNA
네트워크 제어 프로토콜

네트워크 제어 프로토콜 또는 네트워크 컨트롤 프로토콜(Network Control Protocol, NCP)은 1970년대에서 1980년대 초까지 사용된 컴퓨터 망의 통신 프로토콜이었다. 현대 인터넷의 전신인 아파넷의 호스트 컴퓨터에서 실행되는 프로토콜 스택의 전송 계층을 제공했다.

NCP는 초기 아파넷에서 사용된 전송 계층 프로토콜인 전송 제어 프로토콜(TCP)에 앞섰다. NCP는 두 개의 포트 번호를 활용하는 단방향 프로토콜로, 양방향 통신을 위해 두 개의 연결을 설정했다. 각 응용 계층 애플리케이션 또는 프로토콜에는 홀수 및 짝수 포트가 예약되었다. TCP와 UDP의 표준화로 인해 애플리케이션당 두 개의 단방향 포트를 사용하는 대신 하나의 이중 포트를 사용하게 되었다.

이름에 대한 혼란은 아파넷에서 작업했던 엔지니어들 사이에서도 존재했다. 원래는 프로토콜 스택 전체에 대한 이름이 필요 없었으므로 존재하지 않았다. TCP 개발이 시작되었을 때, 그 전신에 대한 이름이 필요했고, 기존의 약어 'NCP'(원래 이 스택을 구현한 소프트웨어인 네트워크 제어 프로그램을 지칭)가 유기적으로 채택되었다. 결국, 그 약어의 원래 확장이 새로운 의미에 부적절하다는 것을 깨달았고, '네트워크 제어 프로토콜'이라는 새로운 의사-역두문자어가 다시 유기적으로, 공식적인 결정 없이 만들어졌다.

역사
아파넷에서 네트워크 내에서 사용되는 물리 계층, 데이터 링크 계층, 네트워크 계층의 프로토콜은 별도의 인터페이스 메시지 프로세서(IMP)에 구현되었다. 호스트는 일반적으로 다른 종류의 인터페이스를 사용하여 IMP에 연결했으며, 다른 물리적, 데이터 링크 및 네트워크 계층 사양을 가졌다. IMP의 기능은 로버트 칸이 작성한 BBN Report 1822의 호스트/IMP 프로토콜에 의해 명시되었다.

캘리포니아 대학교 로스앤젤레스(UCLA)의 레너드 클라인록의 후원 아래, 당시 UCLA 컴퓨터 과학 대학원생이었던 스티브 크로커는 네트워크 워킹 그룹(NWG)을 결성하고 이끌었다. 그는 존 포스텔 등과 함께 네트워크 제어 프로그램으로 알려진 호스트 간 프로토콜을 설계했으며, 이는 UCLA, 유타 대학교, SRI 인터내셔널의 엔지니어들과의 일련의 회의 끝에 1969년 아파넷의 초기 RFC 문서에서 개발되었다. 크로커는 "대부분의 개발은 웅장한 계획에 따라 진행되었지만, 프로토콜 설계와 RFC 생성은 대체로 우발적이었다"고 말했다. ARPA의 배리 웨슬러의 승인 후, 그는 특정 이국적인 요소들을 제외하도록 명령했다, 1970년 초에 로 최종 확정되었으며, 1970년 12월 15일에 아파넷의 모든 노드에 배포되었다.

NCP는 아파넷 네트워크 인터페이스를 체계화하여 쉽게 구축하고 더 많은 사이트가 네트워크에 참여할 수 있도록 했다. 이는 다른 아파넷 호스트 컴퓨터에서 실행되는 프로세스 간의 연결 및 흐름 제어를 제공했다. 원격 로그인 및 파일 전송과 같은 애플리케이션 서비스는 NCP 위에 구축되어 다른 호스트 컴퓨터와의 연결을 처리하는 데 사용되었다. NWG의 다른 참여자들은 이러한 애플리케이션 계층 프로토콜인 텔넷과 FTP를 개발했다.

하위 프로토콜 계층은 IMP-호스트 인터페이스에 의해 제공되었으므로, NCP는 본질적으로 아파넷 호스트 간 프로토콜(AHHP)과 초기 연결 프로토콜(ICP)로 구성된 전송 계층을 제공했다. AHHP는 두 호스트 간에 단방향, 흐름 제어 데이터 스트림을 전송하는 절차를 정의했다. ICP는 한 쌍의 호스트 프로세스 간에 이러한 스트림의 양방향 쌍을 설정하는 절차를 정의했다. 애플리케이션 프로토콜(예: FTP)은 NCP의 최상위 계층 인터페이스를 통해 네트워크 서비스에 접근했다. 이는 버클리 소켓 인터페이스의 선구자였다.

네트워크 제어 프로그램
네트워크 제어 프로그램(Network Control Program, 보통 NCP로 표기)은 아파넷의 네트워크 제어 프로토콜을 구현한 호스트의 소프트웨어 이름이었다.

거의 보편적으로 약어 NCP로 불렸다. 이는 나중에 프로토콜 스위트 자체를 지칭하는 데 사용되었다.

NCP는 멀틱스, TENEX, 유닉스, TOPS-10을 포함한 많은 운영체제용으로 작성되었으며, 일부 NCP는 현재에도 남아있다(물론 지금은 빈티지 컴퓨터 애호가들만이 사용한다).

TCP/IP로의 전환
TCP/IP 구현은 1970년대 후반에 시작되었다.
아파넷 전반에 걸친 광범위한 배포는 1981년에 본격적으로 시작되었고, 1982년 말 며칠 동안 백본 라우터는 대부분의 호스트에 대해 NCP 트래픽을 비활성화하여 전환 준비 상태를 테스트했다.

1983년 1월 1일, 플래그 데이로 알려진 이 날에 아파넷이 핵심 네트워킹 프로토콜을 NCP에서 더 유연하고 강력한 TCP/IP 프로토콜 스위트로 변경하면서 NCP는 공식적으로 폐기되었으며, 이는 현대 인터넷의 시작을 알리는 계기가 되었다.

"강제적인" 플래그 데이 전환에도 불구하고, 1983년 중반까지 일부 사이트에서는 NCP를 계속 사용했지만, 이는 백본 운영자의 허가를 받은 특별한 경우였고, 결국 모든 호스트는 TCP/IP로 전환되거나 제거되었다.

 같이 보기 

 프로토콜 전쟁

 내용주 

 각주 

출처
 

 더 읽어보기 

 
 
 (now offline, but a later version, which is almost identical to the original version, can be found here)
 (this does not seem to be online, but an early version, which is almost identical to the final version, can be found here)
 
 

 외부 링크 
 Network Control Program - 컴퓨터 역사 위키의 NCP 세부 정보
 SRI-NOSC - 완전한 V6 유닉스 NCP 소스
 일리노이 NCP 문서

분류:네트워크 프로토콜
SquashFS

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는 확장 파일 속성을 지원했다.

 같이 보기 

 앱이미지
 Btrfs
 Cloop
 파일 시스템 비교
 크램FS
 e2compr
 EROFS
 Initramfs
 파일 시스템 목록
 재부팅하여 소프트웨어 복원
 윈도우 이미징 포맷
 DwarFS

 각주 

 외부 링크 
 
 Squashfs 이진 형식

분류:C로 작성된 자유 소프트웨어
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킬로바이트) 내의 각 페이지는 순차적으로 기록되어야 하며, 각 페이지는 한 번만 기록되어야 한다.

"한 번 쓰기 규칙"("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초의 마운트 시간이 보고된 바 있다.

 같이 보기 

 파일 시스템 목록
 JFFS
 JFFS2
 UBIFS
 LogFS
 NILFS, 새로운 로그 구조 파일 시스템 구현
 ONFI

 각주 

 http://www.yaffs.net/yaffs-history

 외부 링크 

 Introducing YAFFS, the first NAND-specific flash file system
 Unyaffs: YAFFS2 이미지를 압축 해제하는 간단한 프로그램.
 yaffs2utils: 리눅스에서 YAFFS2 이미지를 생성/추출하는 유틸리티.

분류:윈도우 CE
분류:임베디드 리눅스
Bcachefs

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 모듈로 배포될 것이라고 발표했다.

 각주 

참고 문헌

 
 
 
 
 
 
 
 

 외부 링크 
 

분류:2015년 소프트웨어
분류:리눅스 파일 시스템 관련 소프트웨어
트랜잭션-안전 FAT 파일 시스템

트랜잭션-안전 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 인식 운영체제에 드라이브가 연결되더라도 트랜잭션 안전하지 않을 수 있다.

 같이 보기 
 FAT 파일 시스템의 설계
 노벨 트랜잭션 추적 시스템

 각주 

 더 읽어보기 
 

 

분류:윈도우 CE
Cramfs

cramfs(compressed ROM/RAM 파일 시스템의 약자)는 단순함과 공간 효율성을 위해 설계된 자유(GPL로 배포되는) 읽기 전용 리눅스 파일 시스템이다. 주로 임베디드 및 작은 설치 공간의 시스템에서 사용된다.

기존 파일 시스템의 압축 이미지와 달리 cramfs 이미지는 먼저 압축을 해제하지 않고도 그대로 사용할 수 있다. 이러한 이유로 일부 리눅스 배포판은 메모리 및 이미지 크기 제약이 있는 initrd 이미지(특히 데비안 3.1) 및 설치 이미지(특히 수세 리눅스)에 cramfs를 사용한다.

2013년에 리눅스 관리자들은 cramfs가 SquashFS에 의해 구식화되었다고 밝혔지만, 2017년에는 SquashFS 사용이 불가능할 수 있는 저용량 메모리 장치에서 사용하기 위해 이 파일 시스템이 복원되었다.

설계
cramfs 파일 시스템의 파일은 무작위 읽기 접근을 허용하기 위해 한 페이지씩 Zlib으로 압축된다. 메타데이터는 압축되지 않지만, 기존 파일 시스템보다 공간 효율적인 간결한 표현으로 되어 있다.

파일 시스템은 의도적으로 읽기 전용으로 설계되어 디자인을 단순화했다. 압축된 파일에 대한 무작위 쓰기 접근은 구현하기 어렵다. cramfs는 새 cramfs 이미지로 파일을 압축하는 유틸리티(mkcramfs)를 함께 제공한다.

파일 크기는 16MB 미만으로 제한된다.

최대 파일 시스템 크기는 272MB보다 약간 작다. (파일 시스템의 마지막 파일은 256MB 블록 이전에 시작해야 하지만, 이를 넘어 확장될 수 있다.)

 같이 보기 

 파일 시스템 목록
 파일 시스템 비교
 SquashFS, 읽기 전용 압축 파일 시스템
 Util-linux는 cramfs 유틸리티를 포함한다.

 각주 

 외부 링크 
 
 

분류:파일 시스템
넷웨어 코어 프로토콜

넷웨어 코어 프로토콜(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 함수에 따라 달라진다.

 클라이언트 측 구현 
 노벨의 Windows Vista용 Novell 클라이언트.
 노벨의 Windows 2000/XP/2003용 Novell 클라이언트.
 노벨의 Windows 95/98용 Novell 클라이언트.
 노벨의 리눅스용 Novell 클라이언트.
 노벨의 DOS용 NetWare 클라이언트 - 더 이상 지원되지 않는다.
 프로소프트 엔지니어링의 Mac OS X용 NetWare 클라이언트.
 리눅스용 오픈 소스 NCP 클라이언트 구현인 ncpfs.
 마이크로소프트의 NetWare용 클라이언트 서비스.

 각주 

 외부 링크 
 NCP 사양 (기본 Netware RPC 프레임워크 설명 없음)
 Wireshark (오픈 소스 프로토콜 분석기) 문서 - NCP 패킷 필드
 Mac OS X를 Novell과 잘 작동하게 만들기

분류:네트워크 프로토콜
분류:네트워크 파일 시스템
분류:표현 계층 프로토콜
분류:노벨 넷웨어