GNU Public License를 따릅니다.

koseph at gmail.com: 2002년 1월에 정리했던 자료인데 문득 이런게 없다는 생각에 올려보기로 했습니다.

저는 2002년 이후로 제가 맡았던 모든 프로젝트의 주 파일시스템을 XFS로 교체하여 사용하였고 수년이 지난 지금도 참 잘한 선택이다고 믿고 있습니다.

XFS는 원래 Silicon Graphics, Inc가 1990년대 초기에 개발한 파일 시스템이다. 당시 SGI는 자사에서 사용하고 있던 EFS라는 파일 시스템이 대형 프로젝트를 수행하는데 많은 한계점이 있다는 것을 알게 된다. 이 문제를 해결하기 위해 SGI에서는 기존의 파일 시스템을 수정하는 것 보다는 완전히 새로운 고성능 64비트 파일 시스템을 만드는 것이 낫다는 판단을 하게 된다. 웍스테이션에서 수퍼 컴퓨터에 이르기까지 모든 컴퓨팅 환경을 망라할 수 있는 파일 시스템의 개발 작업에 들어간 것이다. 이런 배경으로 인해 나온 것이 바로 XFS이다. 최초로 이용한 시스템은 1994년 IRIX 5.3을 발표하면서부터다. 그 뒤로 SGI의 IRIX 기반의 후속 제품은 모두 XFS를 기반으로 발표한다. 그리고 마침내 XFS는 리눅스에서 쓸 수 있도록 이식하여 오늘에 이른다. 상업용 파일 시스템이었든만큼 기존의 리눅스용 파일 시스템과는 비교할 수 없는 정교함, 안정성, 확장성 등이 그 특징이다.

XFS 저널링 기술은 갑작스런 인터럽션 후에 아주 빠르게 재시작 할 수 있다. 이때 관리하고 있는 파일의 갯수와는 상관이 없다. 전통적인 파일시스팀은 인터럽션이 발생한 이후에 파일시스템을 점검해야만 했다. 대용량의 경우 이 시간은 적게는 몇 시간에서 몇일까지 걸리기도 한다. XFS 저널링 파일 시스템은 이러한 많은 시간을 필요로 하는 파일 시스템 점검을 피한다.

XFS 파일시스템은 데이터 트랜잭션을 읽고 쓰는 데 있어서 저널링의 성능 충격을 최소화 함으로써 저널링의 장점을 최대한 살렸다. 이것의 저널링 구조와 알고리즘은 트랜잭션을 신속하게 기록하도록 튜닝했다.

XFS는 빠른 검색과 신속한 공간 할당을 위해 효율적인 tree 구조를 이용한다. XFS는 1만개가 넘는 디렉토리 목록이 있는 디렉토리라 하더라도 항상 빠르게 응답한다.

• 이것은 ext2, ext3와 비교하였을때 엄청난 매력이다. 간단한 비교는 http://kldp.org/node/100163 를 참조하길.

XFS는 완전한 64비트 파일시스템이다. 그러므로 수백만 테라바이트에 해당하는 파일시스템을 관리할 수 있다.

백만 테라바이트는 오늘날 사용하고 있는 가장 큰 파일시스템 보다 수천배 크다. 이것은 극단적으로 큰 주소공간처럼 보이지만 근간의 저장장치 산업에서 기하급수적으로 늘어나고 있는 디스크의 밀도 향상에 대비해 필요한 것이다. 디스크 용량이 증가함에 따라, 충분히 큰 주소 공간만이 필요한 것이 아니라 대용량 주소공간에 어울리는 구조와 알고리즘 역시 확장이 필요하다. XFS는 이러한 확장성에 대해 필요한 오늘날 필요한 기술이다.

XFS는 또한 계속해서 시장에 풀리고 있는 하드웨어 기능에 맞도록 발전을 거듭하고 있다. 대용량의(수테라바이트 정도의) 주메모리를 다룰때의 효율과 사용중인 많은 수의 파일 그리고 엄청난 숫자의 캐시한 파일 데이터를 다루는 경우가 지속적인 기술발전을 요구하는 분야다. 대형 NUMA 기종에서도 성능을 높이도록 XFS의 기능을 확장하는 것 또한 활발한 연구와 개발 분야이기도 하다.

• 참고로 Sun에서 출시한 새로운 파일시스템인 ZFS는 128비트 파일시스템이다. 이 글은 ZFS가 출시되기 이전에 나온 글이라는 것을 참조하길.

XFS는 극도로 세련된 공간 관리 기술을 구현했다. 공간 관리에 있어서의 효율은 많은 여타의 파일시스템이 사용하는 메카니즘인 한번에 한 블럭이 아닌, 가변 크기의 extents를 기반으로 한다. XFS는 버퍼 쓰기(buffered writes)에 대해 지연 공간 할당, 직접 I/O지원, 선택할 수 있는 실시간 할당자(optional realtime allocator)를 구현한 첫번째 파일시스템이자 저장장치를 구성하고 있는 기하학적 요소(geometry of the underlying storage device)를 기반으로 하여 할당을 배열할 수 있다. XFS 할당자는 여러 대의 병렬 쓰기(parallel writers)를 이용하여 훌륭한 성능을 보이며 그러한 조건에 하에서 공간 조각화 현상에 대해 저항할 수 있는 것으로 유명하다.

• 참고: 찾아본 자료에 따르면, 기존의 블럭할당 방식의 고전적인 파일시스템(예: Solaris의 UFS2)과 비교했을 때 엄청나게 성능의 차이를 보이는 것은 XFS의 경우 extents 기반의 할당 방식을 채용하고 있다는 것이다. Extents 기반의 파일시스템은 데이터를 저장하기 위해 필요한 메타데이터의 오버헤드가 블럭기반의 파일시스템보다 상대적으로 낮고 파일 조각화의 가능성이 줄어든다. 그리고, XFS는 고전적인 유닉스 파일시스템에 비해 최신의 파일시스템이었기 때문에 기존의 문제점을 획기적으로 고치려 했던 개발자의 노력을 피부로 느낄 수 있다.

XFS는 기반 하드웨어가 제공할 수 있는 원래의 I/O 성능에 가장 근접한 성능을 제공할 수 있다. XFS는 여러대의 테라바이트 파일시스템에서 초당 수기가바이트가 넘는 성능을 보인 SGI Altix상에서 증명된 바 있다.

파일시스템의 일관성을 보증할 수 있는 64비트 저널링 파일시스템이다.

XFS는 리눅스 커널 2.4 이상에서 사용할 수 있다. 개인적으로 커널 2.6이상에서 사용하길 권장.

XFS는 마운트된 볼륨을 확장을 지원하고 볼륨수준의 스냅샷을 지원하기 위해 파일시스템의 "freeze"와 "thaw" 기능을 사용할 수 있으며, 온라인 파일 모으기 유틸리티를 제공한다.

XFS는 사용자와 그룹에 대해 할당량(quotas) 기능을 지원한다. XFS는 quota 정보를 파일시스템의 메타데이터로 취급하고 시스템 크래시 이후에 시간이 걸리는 quota 일관성 유지에 필요한 시간을 피하기 위해 저널링 기능을 이용한다. 이제는 Project quota도 지원하고, 디렉토리 트리 quota의 형태로 기능을 제공한다.

XFS는 완벽한 저널링 + 확장속성을 구현했다. 여기서 확장속성이란 name/value쌍으로 된 파일과 관련한 정보다. 이러한 속성은 모든 형태의 inode, 즉 정규파일, 디렉토리, 심볼릭 링크, 장치 노드 등에 첨부할 수 있다.

속성 값(value)은 최고 64KB의 임의의 이진 데이터를 넣을 수 있다. XFS는 세가지 속성 namespaces를 구현했다. 모든 사용자에 가용한 user namespace, 허가받은 사용자만 액세스할 수 있는 system namespace, 보안 모듈(SELinux)가 사용하는 security namespace가 그것들이다. system namespace는 access control list(ACLs)와 같은 보호된 파일시스템 메타데이터와 계층적 저장매체 관리자(HSM) 파일 이전 상태를 관리할 용도로 사용할 수 있다.

XFS는 ACL 시맨틱과 POSIX 1003.1e 표준 문안에 기술된 인터페이스를 지원한다.

리눅스 2.4의 경우 최대 액세스 가능한 파일의 옵셋은 페이지 크기가 4K의 경우 16TB이고 페이지 크기가 16K인 경우에는 64TB이다. 리눅스 2.6 이후에서는 블럭 디바이스 레이어(CONFIG_LBD)에서 64비트 주소지정 방식을 이용하는 경우, 파일크기 제한은 9백만 테라바이트까지 증가한다.

리눅스 커널 2.4의 경우 2TB이다. 리눅스 커널 2.6 이후에서는 64비트 플랫폼에서 블럭 디바이스 레이어(CONFIG_LBD)에서 64비트 주소지정 방식을 이용하는 경우, 파일시스템 크기 제한은 9백만 테라바이트까지 증가한다. 32비트 플랫폼 상에서의 커널의 경우에는, 64비트 주소지정 기능을 사용하더라도 16TB가 현재의 제한 크기이다.

최소 파일시스템 블럭 사이즈는 512바이트이다. 최대 파일시스템 블럭 사이즈는 커널의 페이지 크기이다. 즉, x86에서는 4K이고 IA64에서는 커널에 컴파일해 넣은 옵션에 따른다(최대 64Kb 가능). 그러므로 XFS는 커널의 페이지 크기가 지원하는 한 최소 512 bytes에서 최대 64Kb까지 블럭 크기를 지원한다.

파일시스템의 extents(즉, 연속하는 데이터)는 파일을 생생할 때 xfsctl(3)를 이용하여 설정할 수 있고 파일 블럭 사이즈의 배수가 된다. 각각의 extents는 최대 4GB이다.

512 바이트부터 최고 32 Kb까지 지원, 주의할 것은 물리적인 디스크 섹터 사이즈는 파일시스템의 블럭사이즈 이하여야 한다는 것이다.

NFS version 3부터, 64비트 파일 시스템도 NFS v3 프로토콜을 지원하는 다른 시스템으로 export 할 수 있게 되었다. NFS v2를 이용하는 시스템의 경우에는 프로토콜의 한계로 32비트 한계 내에서만 XFS 파일시스템을 액세스할 수 있을 수도 있다.

SGI는 XFS 파일시스템을 MS Windows 시스템으로 export 하기 위해 오픈 소스로 진행하고 있는 Samba 서버를 이용한다. Samba의 경우 SMB(Server Message Block)과 CIFS(Common Internet File System) 프로토콜을 이용한다.

xfsdump와 xfsrestore를 이용하면 XFS 파일시스템을 로컬이나 원격지의 SCSI 테잎이나 파일로 백업하거나 복구할 수 있다. 확장 속성과 quota 정보의 덤핑도 지원한다. xfsdump format이 유지되면서 이제 endian에 구애받지 않는다. 어떤 플랫폼에서 생성한 덤프 데이터를 다른 서버(다른 아키텍처, 운영체제가 다른 경우라도, 즉 IRIX에서 리눅스로 혹은 그 반대로) 상에 있는 XFS 파일 시스템으로 복구할 수 있다.

Data Management API(DMAPI/XDSM)는 커널 수정 없이도 그리고 디스크에 대한 "raw" 액세스를 요구하지 않는 고성능 덤프 프로그램과 파일시스템 구조에 대한 지식이 없이도 계층적인 저장매체 관리의 구현을 가능케 한다.

XFS는 "실시간 서브볼륨"이라는 개념을 지원하는데 이것은 오로지 파일의 데이터만 저장하는 디스크의 별도 영역을 뜻한다. 이 서브볼륨 상의 공간은 실시간 할당자(realtime allocator)가 관리한다. 이는 기본값인 B+ 트리 공간 할당자와는 전혀 다른 것이다. 실시간 서브볼륨을 설계한 이유는 미디어 스트리밍 응용프로그램에 어울리는 아주 결정적인 데이터 전송능력을 제공하기 위해서이다.

• 이 기능은 실제로 구현해 써보았는데 LVM을 사용하지 않고 파티션만으로 이를 구현했던 기억이 있다. 손이 많이 갔지만 파일시스템 성능을 최대한 끌어 올릴 수 있었다.
  
  

2002년 1월 1일, 당시 Gentoo 프로젝트를 이끌고 있던 대니얼 로빈슨의 글을 읽었던 기억이 난다. 물론 이 글에서 대니얼은 자신이 설명하고 있는 것이 절대적인 기준은 아니기 때문에 참고 자료로 활용하라는 당부를 잊지 않았다.

현재까지, 리눅스에서 사용할 수 있는 적절한 차세대 파일 시스템을 선택하는 것은 상당히 직관적이었다. 단순히 성능 향상을 위해서는 reiserfs를 선택한 반면, 나머지는 ext3를 선택했다. 하지만, XFS가 등장함에 따라 선택은 더욱 더 혼란스러워졌다. 특히, reiserfs가 여전히 성능면에서 차세대를 이끌 수 있는 파일 시스템인지는 더 이상 명확하지 않은 일이다.

이하 생략...

자체 시험 결과, XFS가 일반적으로 상당히 빠르다는 것을 알았다. XFS는 대형 파일 조작 항목이 들어간 시험에서 거의 대부분 가장 우수한 결과를 내었다. 이는 XFS가 본래 대형 시스템을 염두에 두고 개발한 파일 시스템이라는 것과 그동안 수많은 튜닝 작업을 통해 최적화 되었다는 것을 알 수 있다. 딱 한가지 신경쓰이는 것이라면 파일을 삭제하는 경우 그다지 빠르지 않다는 것이다. 파일을 삭제하는 시험에서는 ReiserFS와 ext3가 앞서는 경우가 많았다. 하지만, 이런 문제에 대한 패치가 곧 나올 예정이고 금새 해결 되리라 기대한다.

무엇보다도, XFS는 ReiserFS의 성능에 매우 근접했으며 ext3와는 비교도 되지 않는다. XFS의 가장 좋은점 한가지를 꼽는다면 그것은 바로 ReiserFS와 마찬가지로 불필요한 디스크 동작을 수반하지 않는다는 것이다. XFS의 경우 가능한 많은 양의 데이터를 메모리에 캐시하려고 하고, 일반적으로 메모리에 부담을 느끼는 경우에만 디스크에 데이터를 기록한다. 데이터를 디스크로 플러싱하는 경우, 다른 IO 동작은 크게 영향 받지 않는 것 같다. 반면, ext3의 경우(기본값인 "data=ordered" 모드에서) 디스크를 엄청나게 많이 건드리고, 심지어 디스크를 고문하는 듯한 느낌이 들었다.

성능과 튜닝 시험은 주로 램 디스크에 있는 커널 소스 파일을 풀어서 시험 대상 파일 시스템으로 복사하고 커널 소스 트리를 동일한 파일 시스템 상에서 다른 디렉토리로 통째로 복사하는 것이었다. 첫번째 시험에서 XFS의 경우 ReiserFS 보다 느렸다 하지만 XFS 파일 시스템을 mkfs.xfs 툴로 튜닝하고 mount 옵션을 바꾸어주니 결과는 달라졌다. 전체적인 성능은 XFS가 ReiserFS를 약간 앞섰고 커널 소스 파일 내에서도 평균적으로 중간 크기 이상의 파일을 작업할 때 ReiserFS보다 나은 성능을 보인다는 것을 알 수 있었다. 여기서 파일 삭제하는 과정은 제외한다.

지금 돌이켜보면 XFS는 Gentoo와 함께 그 빛을 더한 파일시스템이 아닌가 싶다. 그리고 64비트 플랫폼에서 성능은 더욱 빛을 발한다.

한 시스템은 극도로 시달리는 웹서버이자 마스터 서버인데 평균 uptime이 300일 정도다. 그래서 거의 5년이 넘게 재부팅은 10번 미만이다. 물론 파일시스템만 가지고 이렇게 되었다고 말하긴 무리가 있다. 그래도 다른 파일시스템으로 이걸 꾸몄다면 결과가 어땠을까 하고 생각해보면 지금도 난 운이 좋았다고 생각한다.

XFS가 모든 파일시스템에 있어 최고라고는 생각하지 않는다. 하지만, 이만한 파일시스템도 없다.

사실 XFS보다 더 나은 파일시스템을 찾아보려고 ReiserFS v4도 고려 했었다. 그리고 한동안 시험적으로 이를 사용해 보기도 했는데 디스크 어레이가 깨진다거나 파일시스템이 깨지는 심각한 문제를 경험하면서 성능도 성능이지만 서비스 머신의 안정성을 담보하지 않고서는 성능이 아무런 의미가 없음을 비싼 댓가를 치루며 알게 되었다.

개인적으로 XFS 시스템을 사용해서 파일시스템 크래시(filesystem crash) 혹은 시스템 행(system hang)이 일어난 적은 한번도 없었다. 하지만 어떤 사용자는 이런 걸 경험하나 보다. 결론적으로 세상에 완벽한 파일시스템은 없다. 이런 측면에서 백업은 아무리 강조해도 지나치지 않다.

딱 하나 지금도 기억에 남는 건 4K stack overflow 문제였다. 지금은 어떻게 해결이 났는지 확인해 보지 않았다. 이 때문에 실무에선 LVM이나 software RAID를 채용하지 않았다. 순수하게 파티션 테이블 만 이용해서 공간을 할당했었다. 그리고, LVM의 편리함을 포기하는 대신에 논리적 레이어가 하나 줄어들기 때문에 성능 면에서도 이게 더 유리하다.

혹시 실무에 이를 적용하고자 하는 이가 있다면 꼭 참조하기 바란다.

사실 XFS 파일시스템을 튜닝하는 부분은 파일시스템에 대한 많은 배경지식과 이해를 필요로 한다. 그리고 이 글에서는 구체적으로 어떻게 튜닝 했는지에 대해서는 적지 않았다. 왜냐면 그걸 설명하려면 이 글이 파일시스템 강좌가 되어 버릴테니깐....

한마디만 적자면, 튜닝하지 않은 XFS는 별 의미가 없는 경우가 있다. 특히 성능면에서. 아주 작더라도 제대로 된 튜닝은 파일시스템의 효율을 상당히 높일 수 있다. 경험상 동일한 환경에서 작게는 30%, 많게는 그 이상도 가능하다.

* http://oss.sgi.com/projects/xfs/

* http://www-128.ibm.com/developerworks/library/l-fs9.html

* http://www-128.ibm.com/developerworks/library/l-fs10.html

* 내 경험

CategoryTips