오늘 소개할 파일 시스템은 Log structred 파일 시스템의 일종인 NiLFS(2) 입니다.

그럼 LiLFS 는 없나?  아.. 물론 있습니다.

어찌되었건 NiLFS(2)는 SSD 에서 좋은 성능을 낸다고 합니다.

소개글을 보겠습니다.

NiLFS(2)는 일본의 NTT(Nippon Telegraph and Telephone)에서 두 번째로 개발한 Log-structured 파일 시스템이다. 
이 파일 시스템은 개발이 활발히 진행 중이며 최근에는 NetBSD 커널을 비롯한 주요 Linux 커널에 도입되었다.
NILFS 첫 번째 버전(버전 1)은 2005년에 개발되었지만 가비지 컬렉션 기능이 부족했다.
버전 2는 2007년 중반에 처음 릴리스되었으며 이 버전에는 가비지 콜렉터와 다수의 스냅샷을 작성하고 유지하는 기능이 포함되었다. 2009년에는 NiLFS(2) 파일 시스템이 주요 Linux 커널에 포함되었으며 Linux의 로더 가능형 모듈을 설치하면
이 파일 시스템을 간단히 사용할 수 있다.

NiLFS(2)에서 주목할만한 부분은 연속해서 스냅샷을 할 수 있는 기술이다.
NILFS는 로그 형태로 구조화되어 있기 때문에 새 데이터는 로그의 헤드에 쓰여지며 기존 데이터는
가비지 컬렉션되지 않는 한 계속 존재한다.
기존 데이터가 계속 존재하기 때문에 원하는 시점으로 돌아가서 해당 파일 시스템의 에포크(epoch)를 조사할 수 있다.
이러한 에포크는 NiLFS(2)에서 체크포인트라고 불리며 파일 시스템의 핵심 부분이 된다.
NiLFS(2)에서는 파일 시스템에 변화가 생길 때마다 이러한 체크포인트가 작성되지만
사용자가 강제로 체크포인트를 작성할 수도 있다.

특정 체크포인트를 시스템 상에 마운트 하여 볼수 있는 것은 굉장한 장점으로 보여집니다.
동작중에 리부팅을 하여도 마지막 복구 포인트로 복구할수 있다는 것은 fsck 를 상시적으로 실행하고
있다는 의미가 되니 굉장히 안정적인 운용이 가능해 보인다.

장점과 단점을 한번 보자.

장점으로는 스냅샷이 로그 형태로 구조화되어 있어 본질적으로 쓰기가 순차적으로 행해지고 이로 인해
실제 디스크의 찾기 기능이 최소화 되어 쓰기 속도가 매우 빠르다는 점이다.

단점은 스탭샷이 로그 형태이기 때문에 가비지 컬렉션을 수행하여 이전 데이타와 메타데이타를 정리해야
한다는 것인데 이런 경우 성능이 저하되는 문제가 나타난다.

뭐 둘다 로그 형태로 기록되는 것에 따른 문제가 장점으로도 단점으로도 나타난다고 볼수 있겠다.

NiFLS(2)를 시스템에서 사용하는데 필요한 유틸이 몇가지 있는데

mkck(체크포인트 만들기)와  lscp(체크포인트 보기) 로 특정 복구 포인트를 시스템상에 마운트하여 볼수 있다.

이외의 실제 응용은 궁금하신 분들은 직접 시도해 보실 거라 생각합니다.

To be continued.....

출처 : https://www.ibm.com/developerworks/kr/library/l-nilfs-exofs/