저널링 파일 시스템

Journaling file system
IBM 문서철 파일 시스템에 대한 내용은 JFS(파일 시스템)를 참조하십시오.

저널링 파일 시스템은 일반적으로 순환 로그인 "저널"이라고 알려진 데이터 구조에 이러한 변경의 목표를 기록함으로써 파일 시스템의 주요 부분에 아직 커밋되지 않은 변경 사항을 추적하는 파일 시스템이다.시스템 충돌 또는 전원 장애의 경우, 그러한 파일 시스템은 손상될 가능성이 낮으면서 더 빨리 온라인으로 전환될 수 있다.[1][2]

실제 구현에 따라 저널링 파일 시스템은 저장된 메타데이터만 추적할 수 있으므로 데이터 손상 가능성을 증가시키는 희생으로 성능이 향상된다.또는 저널링 파일 시스템은 저장된 데이터와 관련 메타데이터를 추적할 수 있으며, 일부 구현에서는 이와 관련하여 선택 가능한 동작을 허용한다.[3]

역사

1990년에 IBM은 저널링을 구현한 최초의 UNIX 상용 파일 시스템 중 하나로 AIX 3.1의 JFS를 소개했다.[4]그 다음 해 이 아이디어는 로그 구조 파일 시스템에 관한 널리 인용된 논문에서 대중화되었다.[5]이것은 1993년에 마이크로소프트의 윈도 NTFS 파일 시스템에서 그리고 2001년에 리눅스의 엑스트라 3 파일 시스템에서 구현되었다.[6]

이론적 근거

파일 및 디렉토리의 변경사항을 반영하기 위해 파일 시스템을 업데이트하려면 일반적으로 많은 개별 쓰기 작업이 필요하다.이로 인해 쓰기 사이의 중단(전원 장애 또는 시스템 충돌 등)이 데이터 구조를 유효하지 않은 중간 상태에 둘 수 있다.[1]

예를 들어, Unix 파일 시스템에서 파일을 삭제하려면 다음 세 단계를 수행하십시오.[7]

  1. 디렉토리 항목을 제거하는 중.
  2. 무료 inode 풀로 inode 해제.
  3. 사용 가능한 디스크 블록 풀로 모든 디스크 블록 반환

1단계 이후와 2단계 이전에 충돌이 발생하면 링크가 끊어진 inode가 발생하여 스토리지 누수가 발생하고, 2단계와 3단계 사이에 충돌이 발생하면 이전에 파일에서 사용한 블록을 새 파일에 사용할 수 없어 파일 시스템의 스토리지 용량이 사실상 감소한다.스텝을 다시 밟는 것도 도움이 되지 않는다.3단계가 1단계를 선행하는 경우, 이들 사이의 충돌로 파일의 블록이 새 파일에 재사용될 수 있으며, 이는 부분적으로 삭제된 파일이 다른 파일의 내용 중 일부를 포함하게 되며, 두 파일 모두에 대한 수정 내용이 표시된다는 것을 의미한다.반면, 2단계가 1단계보다 먼저 진행된다면, 그들 사이의 충돌은 존재하는 것처럼 보여도 파일에 접근할 수 없게 된다.

그러한 불일치를 탐지하고 복구하려면 일반적으로 fsck(파일 시스템 검사기)와 같은 툴로 데이터 구조를 완전히 파악해야 한다.[2]이는 일반적으로 읽기-쓰기 액세스를 위해 파일 시스템을 다음에 마운트하기 전에 수행해야 한다.파일 시스템이 크고 I/O 대역폭이 상대적으로 적은 경우, 이는 시간이 오래 걸리고 시스템의 나머지가 다시 온라인 상태가 되는 것을 차단하면 다운타임이 더 길어질 수 있다.

이를 방지하기 위해 저널링된 파일 시스템은 저널링된 파일 시스템이 변경사항을 미리 기록하는 특수 영역인 저널을 할당한다.충돌 후 복구는 단순히 파일 시스템에서 저널을 읽고 파일 시스템이 다시 일관될 때까지 저널의 변경 사항을 재생하는 것이다.따라서 이러한 변화는 성공(원래에 계승되거나 회복 중에 완전히 재생)되거나 전혀 재생되지 않는다는 점에서 원자(분할할할 수 없다)라고 한다(충돌되기 전에 아직 저널에 완전히 쓰여지지 않았기 때문에 생략한다).

기술

일부 파일 시스템은 저널을 일반 파일처럼 확장, 축소 및 재할당을 허용하는 반면, 다른 파일 시스템은 파일 시스템이 탑재되는 동안 저널을 이동하거나 크기를 변경하지 않도록 보장되는 인접 영역이나 숨겨진 파일에 넣는다.일부 파일 시스템은 솔리드 스테이트 드라이브 또는 배터리 지원 비휘발성 RAM과 같은 별도의 장치에 외부 저널을 허용할 수도 있다.저널에 대한 변경사항은 추가적인 중복성을 위해 저널링될 수 있으며, 저널은 기기 고장에 대비하여 여러 물리적 볼륨에 분산될 수 있다.

저널의 내부 형식은 저널이 작성되는 동안 충돌하지 않도록 보호해야 한다.많은 저널 구현(예: ext4의 JBD2 레이어)은 충돌로 인해 부분적으로 작성된 변경사항이 다음 재마운트 시 저널을 재생할 때 간단히 무시할 수 있는 누락(또는 일치하지 않는) 체크섬으로 남게 된다는 이해에 따라 체크섬으로 기록된 모든 변경사항을 분류한다.

물리 저널

물리적 저널은 나중에 메인 파일 시스템에 기록될 모든 블록의 사전 복사본을 기록한다.메인 파일 시스템을 쓸 때 충돌이 발생하는 경우, 파일 시스템을 다음에 장착할 때 쓰기 작업을 다시 재생하여 완료할 수 있다.저널에 쓰기가 기록될 때 충돌이 발생하는 경우 부분 쓰기는 누락되거나 일치하지 않는 체크섬을 가지며 다음 마운트에서 무시할 수 있다.

물리적 저널은 모든 변경된 블록을 스토리지에 두 번 커밋해야 하기 때문에 상당한 성능 저하가 발생하지만 절대적 결함 보호가 필요할 경우 허용될 수 있다.[8]

논리적 저널

논리 저널은 파일 메타데이터에 대한 변경 사항만 저널에 저장하고 훨씬 더 나은 쓰기 성능을 위해 내결함성을 거래한다.[9]논리적 저널이 있는 파일 시스템은 충돌 후 여전히 빠르게 복구되지만 저널링되지 않은 파일 데이터와 저널링된 메타데이터가 서로 동기화되지 않아 데이터 손상이 발생할 수 있다.

예를 들어 파일에 추가하면 다음과 같은 세 가지 개별 쓰기가 포함될 수 있다.

  1. 파일의 메타데이터에 파일의 크기가 증가했음을 기록하기 위해 파일의 inode.
  2. 추가할 데이터에 대한 공간 할당을 표시하기 위한 자유 공간 맵.
  3. 추가된 데이터를 실제로 쓰기 위해 새로 할당된 공간.

메타데이터 전용 저널에서는 3단계가 기록되지 않는다.3단계가 수행되지 않았지만 복구 중에 1단계와 2단계가 재생되면 파일에 가비지가 추가된다.

쓰기 위해성

대부분의 운영 체제에서 쓰기 캐시는 처리량을 극대화하기 위해 쓰기(엘리베이터 알고리즘 또는 유사한 구성표 사용)를 정렬한다.메타데이터 전용 저널과 함께 순서가 맞지 않는 쓰기 위험을 방지하려면 파일 데이터에 대한 쓰기가 관련 메타데이터보다 먼저 스토리지에 커밋되도록 정렬되어야 한다.이는 파일 시스템 드라이버와 쓰기 캐시 사이의 운영 체제 커널 내의 조정이 필요하기 때문에 구현이 어려울 수 있다.기기가 기본 스토리지에 즉시 쓰기 블록을 쓸 수 없는 경우, 즉 쓰기 지연이 활성화되어 쓰기 캐시를 디스크로 플러시할 수 없는 경우에도 순서 초과 쓰기 위험이 발생할 수 있다.

문제를 복잡하게 하기 위해, 많은 대용량 저장 장치에는 자체 쓰기 캐시가 있으며, 이 캐시가 더 나은 성능을 위해 쓰기 순서를 공격적으로 변경할 수 있다.(엘리베이터 정렬로 최소화할 수 있는 탐색 지연 시간이 큰 마그네틱 하드 드라이브에서 특히 일반적이다.)일부 저널링 파일 시스템은 보수적으로 그러한 쓰기 순서가 항상 발생한다고 가정하며, 장치가 저널의 특정 지점(ext3 및 ext4)에서 캐시를 플러시하도록 함으로써 정확성을 위해 성능을 희생한다.[10]

대안

소프트 업데이트

일부 UFS 구현은 저널링을 피하고 대신 소프트 업데이트를 구현한다. 즉, Disk 파일 시스템이 일관되지 않도록 쓰기를 명령하거나, 충돌 시 생성될 수 있는 유일한 불일치는 스토리지 누출이다.이러한 누수로부터 복구하기 위해, 다음 마운트에서 파일 시스템의 전체 이동에 대해 여유 공간 맵을 조정한다.이 쓰레기 수거는 보통 뒤에서 한다.[11]

로그 구조화된 파일 시스템

로그 구조화된 파일 시스템에서는 저널 자체가 파일 시스템이기 때문에 쓰기-두 배의 벌칙이 적용되지 않는다. 즉, 저널 자체가 전체 스토리지 장치를 차지하며 일반적인 파일 시스템과 마찬가지로 통과될 수 있도록 구성된다.

쓰기 시 복사 파일 시스템

전체 Copy-on-write 파일 시스템(예: ZFS 및 Btrfs)은 새로 할당된 블록에 데이터를 기록함으로써 파일 데이터에 대한 인플레이스 변경을 방지하고, 이어서 새로운 데이터를 가리키고 이전 데이터를 해제하는 업데이트된 메타데이터를 차례로 선택한 다음, 슈퍼 블록 또는 파일 시스템 계층의 루트까지를 가리킨다.이것은 두 배의 쓰기 오버헤드 없이 저널과 동일한 정확성 보존 속성을 가지고 있다.

참고 항목

참조

  1. ^ a b Jones, M Tim (June 4, 2008), Anatomy of Linux journaling file systems, IBM DeveloperWorks, archived from the original on February 21, 2009, retrieved April 13, 2009
  2. ^ a b Arpaci-Dusseau, Remzi H.; Arpaci-Dusseau, Andrea C. (January 21, 2014), Crash Consistency: FSCK and Journaling (PDF), Arpaci-Dusseau Books, archived (PDF) from the original on January 24, 2014, retrieved January 22, 2014
  3. ^ "tune2fs(8) – Linux man page". linux.die.net. Archived from the original on February 25, 2015. Retrieved February 20, 2015.
  4. ^ Chang, A.; Mergen, M.F.; Rader, R.K.; Roberts, J.A.; Porter, S.L. (January 1990), "Evolution of storage facilities in AIX Version 3 for RISC System/6000 processors" (PDF), IBM Journal of Research and Development, 34:1: 105–109
  5. ^ Rosembaum, Mendel; Ousterhout, John (February 1991). The Design and Implementation of a Log-Structure File System (PDF). ACM 13th Annual Symposium on Operating Systems Principles.
  6. ^ "'2.4.15-final' - MARC". marc.info. Retrieved March 24, 2018.
  7. ^ A.S. Tanenbaum의 파일 시스템(2008)최신 운영 체제(3차 개정, 페이지 287).어퍼 새들 리버, NJ: 프렌티스 홀.
  8. ^ Tweedie, Stephen (2000), "Ext3, journaling filesystem", Proceedings of the Ottawa Linux Symposium: 24–29
  9. ^ Prabhakaran, Vijayan; Arpaci-Dusseau, Andrea C; Arpaci-Dusseau, Remzi H, "Analysis and Evolution of Journaling File Systems" (PDF), 2005 USENIX Annual Technical Conference, USENIX Association, archived (PDF) from the original on September 26, 2007, retrieved July 27, 2007.
  10. ^ Corbet, Jonathan (May 21, 2008), Barriers and journaling filesystems, archived from the original on March 14, 2010, retrieved March 6, 2010
  11. ^ Seltzer, Margo I; Ganger, Gregory R; McKusick, M Kirk, "Journaling Versus Soft Updates: Asynchronous Meta-data Protection in File Systems", 2000 USENIX Annual Technical Conference, USENIX Association, archived from the original on October 26, 2007, retrieved July 27, 2007.