Write Barrier

본 문서는 Linux 파일시스템의 오류 상황과 파일시스템에서 지원하는 Write Barrier 기능에 대해 기술하고
있습니다.

파일시스템 에러

 Linux 파일시스템은 Unix 시스템과 마찬가지로 마운트 작업을 거친 후에 접근이 가능한 형태로 이루어져있다. 마운트 작업을 거쳐
OS에 인식이 되면 파일시스템 드라이버를 통해서 물리적인 디스크에 매핑되는 논리적 구조로 사용이 가능하게 된다.

 파일시스템은 일반적인 경우에는 별 다른 문제 없이 정해진 파일시스템 구조에 맞추어 데이터를 저장하게 되는데 이러한 파일시스템에 문제가
발생하는 경우가 몇 가지 존재 하지만 종합해보면 궁극적인 원인은 실제 물리적인 디스크의 장애로 인한 경우로 결론 지을 수 있다.

 먼저, 물리적인 디스크의 배드섹터(Bad Sector)에 대한 부분을 생각할 수 있다. 물리적인 디스크의 플래터에 배드섹터가 발생하였고
이 영역에 파일시스템이 매핑하여 데이터를 기록하려고 하면 오류가 나게 된다. 하지만, 최근 디스크 들은 이러한 배드 섹터를 자동으로 처리하기
위해서 디스크가 제공하는 가용공간 이외에도 추가적인 영역을 가지고 있어 배드섹터가 발생하면 해당 영역을 미리 준비된 추가 영역으로 대체해서
I/O를 처리하게 된다.

 그리고, 물리적인 디스크가 인식불가 또는 전원 공급이 끊긴 상태를 생각해 볼 수 있다. 물리적인 디스크가 죽은 장치(Dead
Device)로 인식이 되면 I/O를 처리할 수 없는 상황이 발생하게 되는데 이 경우에 파일시스템의 결함(Corruption)이 발생할 수
있다. 이는 저널링 파일시스템의 특성하고도 관련성이 있다. 저널링 파일시스템은 일반적으로 세 가지 방식으로 동작하는데
쓰기저장(WriteBack), 순서(Ordered), 데이터(Data) 방식으로 나눌 수 있다.

 간단히 살펴보면

• 쓰기저장 모드에서는 메타데이터만을 저널에 기록하고 실제 데이터 블록은 디스크의 해당 위치에 직접 기록하는 방식
• 순서 모드에서는 실제 데이터 블록을 기록하고 나서야 메타데이터를 저널에 기록한다.
• 데이터 방식의 경우는 메타데이터와 데이터블록을 저널에 모두 기록하고 그 후에 디스크에 다시 기록하는 방식

 일반적으로 많이 사용되는 ext3 파일시스템의 경우 순서 방식이 기본으로 되어있으며 앞서 물리적디스크가 인식이 되지 않게 되면
데이터블록은 기록하였으나 저널에 메타데이터가 제대로 기록되지 않아 파일시스템의 불일치(inconsistency) 또는 결함이 생기게 된다.
참고로, 통상적인 쓰기저장 방식이라면 메타데이터만 남고 실제 데이터블록은 유실되게 된다. (저널링 관련된 부분은 인터넷에 많이 있는 저널링 관련
문서를 참고하면 된다)

 또 하나 생각해 볼 수 있는 부분이 대규모의 I/O 요청이 발생하였고 이 요청이 물리적인 디스크가 (심지어 캐시를 가지고 있음에도
불구하고) 감당하지 못할 정도로 많을 경우이다. 이 경우에는 오랜 시간이 걸리더라도 I/O 요청을 다 처리했다면 파일시스템이
조각현상(fragmentation)이 심할지언정 불일치나 결함까지 발생하지는 않는다. 다만, 이러한 I/O 요청을 견디다 못해 디스크
컨트롤러에서 취소(Abort)를 발생 시키거나 디스크 자체가 행업(Hang-up)되면 앞서 살펴보았던 디스크 인식불가 상태와 마찬가지로
파일시스템에 문제가 발생할 수 있다.

 그 외에 전원차단 등의 문제를 생각해 볼 수 있는데 전원이 차단되는 것은 디스크 인식불가 상태와 마찬가지로 생각해도 큰 문제가 없으며
예외적인 요소에 대해서는 후에 Write Barrier를 살펴볼 때 설명하도록 하겠다. 그리고, 드문 경우이긴 하지만 커널 자체의 버그(또는
파일시스템 드라이버 모듈의 버그)로 인해서 발생하는 경우가 있다. 이러한 버그의 예로 다량의 I/O 처리에 대해서 제대로 처리하지 못하고
Zero-length 파일을 양산해서 발생하는 문제도 있다.

 앞서 살펴본 파일시스템에 결함(Corruption)에 영향을 줄 만한 상황에 대해서 종합해보면 궁극적인 요인은 물리적인 디스크 자체의
문제로 볼 수 있으며 운영중인 파일시스템의 불일치(inconsistency) 부분은 파일시스템의 조각화 현상에 능동적으로 대처하지 못하는
파일시스템에서도 종종 볼 수 있다. (예, ext2/3)

Write
Barrier

 Write Barrier는 파일시스템의 메타데이터가 올바르게 기록되고 디스크에 제대로(심지어 디스크 전원이 나갈지라도) 반영되게 하기위한
커널 매커니즘이다. 이 매커니즘은 전원에 문제가 생겨도 fsync()를 통해서 전송된 데이터가 올바르게 지속되록 해주지만 특정 프로그램에
대해서는 성능 저하를 가져오는 영향을 줄 수 있다. 특히, fsync() 시스템콜을 많이 사용하거나 작은 파일의 생성과 삭제를 빈번하게 하는
어플리케이션에 성능적인 저하를 많이 일으키게 된다.

 앞서 언급했던 파일시스템과 관련된 부분을 다시 짚어보자. 현재 대부분의 디스크 장치는 내부적으로 캐시를 가지고 있으며 RAID
컨트롤러에도 캐시가 존재한다. 이러한 Write Cache가 존재하는 저장장치들은 데이터가 캐시에 전달이 되면 물리적인 디스크에서 I/O가
완료되었다고 응답한다. 만약 이 상황에서 전원이 유실되면 캐시에 존재하는 데이터도 사라지게 되는데 하나의 데이터 저장 트랜젝션이 일부만 수행된
경우라면 상황은 더 복잡하게 된다. 제대로 완료되지 않은 데이터블록들만 디스크에 존재하게 될 것이고 전원이 복구되면 저널은 초기화 되지 않은
트랜젝션 블록들을 파일시스템에 다시 반영하려고 시도하며 결과적으로 데이터의 일관성과 무결성에 영향을 미치게 된다.

Write Barrier의
동작

 Write Barrier는 I/O 처리의 전과 후에 저장장치(디스크)의 캐시를 비우는 동작을 통해서 Linux 커널에 구현되어있다.
데이터를 저장하기 위해서 트랜젝션이 기록되면 저장장치의 캐시를 비우고(flush) 데이터블록이 기록되면 다시한번 저장장치의 캐시를 비우게 된다.
여기에서 캐시를 비운다는 것은 디스크 캐시에 존재하는 데이터를 실제 물리적인 저장장치에 기록한다는 것을 의미한다. 이러한 동작은 디스크에 모든
데이터를 보유하게 되므로 메타데이터의 순서를 다시 맞출 필요가 없어지게 된다.

 하지만, 앞서 언급했던 것 처럼 Write Barrier를 사용하게 되면 디스크 성능 향상을 위해 장착된 디스크 캐시에 대해서 2번에
걸쳐 비우는 작업을 진행하므로 성능에 단점으로 작용할 수 밖에 없다.

Write Barrier for
ext3/ext4

 당연한 이야기일지 모르지만 저널링 파일시스템인 ext3에도 Write Barrier 기능의 사용이 가능하다. 하지만, ext3는
ext2에 저널링 기능을 추가해서 나온 파일시스템으로 태생적인 한계로 인해 Write Barrier를 활성화하게 되면 성능저하가 매우 심한
편이다. ext3도 계속 개선되고 있기 때문에 어느 정도 좋아졌는지는 모르겠지만 일전에 테스트 했던 경험으로는 약 1/10 수준의 I/O
성능밖에 내지 못하는 문제가 있었다.

 비교적 최근 등장한 ext4 파일시스템도 Write Barrier를 지원하며 ext3와는 다르게 Write Barrier 기능이
기본적으로 활성화 되어있다. 즉, /etc/fstab에 barrier=1로 설정하여 마운트 하지 않아도 Write Barrier 기능이
동작한다. 따라서, ext4의 안정성은 ext3 기본(Write Barrier 비활성)보다 낫다고 보아도 무방하다. ext4 외에도 대용량
스토리지 시스템에 널리 사용되어왔던 XFS 파일시스템도 Write Barrier가 기본적으로 활성화 되어있다.

 이러한 ext4 파일시스템의 Write Barrier의 활성화는 해당 기능을 활성화해도 충분한 성능을 얻을 수 있기 때문인데 이에 대한
벤치마크 자료를 확인해 보자.

 

위 자료는 Bonnie++로 테스트한 순차적(sequential)인 I/O 대역폭과 랜덤한 데이터 접근에 대한 결과 값이다. ext4,
XFS 파일시스템의 경우 Write Barrier가 활성화 되어있음에도 좋은 성능을 보이고 있다.

이 그래프는 Write Barrier와 직접적인 관련이 없는 번외적인 것으로 커널소스를 풀었을 때의 조각화 정도를 비교한 그래프이다.
이는, 지연할당(Delayed Allocation) 기능이 없는 ext3가 가장 조각화가 심하게 되는 것을 보여주고 있다.

Write Barrier의
유효성

 Write Barrier는 파일시스템의 일관성/무결성을 위해서 존재하는 기능이지만 BBC(Battery-backend Cache)가
존재하는 RAID 컨트롤러에서는 없어도 되는 기능이다. BBC가 존재하는 경우는 파워가 유실되어도 Write Cache 데이터가 날아가지 않고
그대로 보존되며 다시 정상적으로 시스템에 전원이 공급되면 전원 복구 후 작업(Post-power-loss recovery)의 일환으로 Write
Cache가 가지고 있는 데이터를 물리적인 디스크에 반영시켜주기 때문이다.

 Write Barrier가 기본적으로 활성화 된 파일시스템이더라도 위와 같이 물리적인 안정성을 가지고 있는 경우에는 Write
Barrier를 끄고 성능 향상을 꾀하는게 더 나을 수 있다. 단, 전원 문제가 아닌 디스크 컨트롤러 자체의 장애에 대해서도 안정성을 확보하고자
한다면 Write Barrier를 활성화 할 필요가 있다.

 
참고문헌 : http://www.ilsistemista.net/index.php/linux-a-unix/6-linux-filesystems-benchmarked-ext3-vs-ext4-vs-xfs-vs-btrfs.html