개발자 빌드를위한 가장 빠른 파일 시스템은 무엇입니까?

지속적인 통합 빌드 서버 역할을 할 Linux 박스를 구성하고 있습니다. 우리는 대부분 자바를 만들지 만이 질문은 컴파일 된 언어에 적용된다고 생각합니다.

어떤 파일 시스템 및 구성 설정을 사용해야합니까? (예를 들어, 나는 이것을 위해 시간이 필요하지 않다는 것을 안다!) 빌드 서버는 작은 파일을 읽고 쓰고 디렉토리를 스캔하여 어떤 파일이 수정되었는지를 보는 데 많은 시간을 할애한다.

업데이트 :이 경우 데이터 무결성이 우선 순위가 낮습니다. 그것은 단지 빌드 머신입니다 ... 최종 아티팩트는 압축되어 다른 곳에 보관됩니다. 빌드 머신의 파일 시스템이 손상되어 모든 데이터를 잃어버린 경우, 지우고 이미지를 다시 만들 수 있습니다. 빌드는 이전과 같이 계속 실행됩니다.

다음과 같은 몇 가지 속도 향상 옵션이있는 ext4fs를 기본 파일 시스템으로 사용하십시오.

noatime,data=writeback,nobh,barrier=0,commit=300

그런 다음 빌드 중에 작성된 파일이 램 디스크의 이점을 얻을 수 있도록 tmpfs 램 디스크를 그 위에 통합 마운트하십시오. 빌드 종료시 결과 바이너리를 tmpfs에서 이동 시키거나 빌드를 해제하기 전에 tmpfs를 ext4fs로 다시 병합하도록 빌드 프로 시저를 변경하십시오.

가장 빠른 파일 시스템? tmpfs는 사용 가능한 RAM에서 마운트되어 noatime설정됩니다.

소스 트리를 빌드하는 데 필요한 모든 것을 체크 아웃하는 절차가있는 경우 (tmpfs 파일 시스템의 내용이 재부팅 할 때 사라지기 때문에) 소스와 객체가 사용 가능한 RAM의 적절한 모서리에 맞는 경우에만 가능합니다 ( 스왑없이 컴파일러 및 링커를 실행하기에 충분히 남았습니다. 그것은 당신이 속도를 위해 RAM에서 작동하는 것을 이길 수 없다고 말했다.

Michael Dillon의 답변에 몇 가지 옵션으로 ext4 파일 시스템을 만들 수 있다고 덧붙일 수 있습니다.

mkfs.ext4 -O dir_index,extent -i 8096 /dev/<disk>


dir_index
    Use hashed b-trees to speed up lookups in large directories.

extent 
    Instead of using the indirect block scheme for storing the location of data blocks in an inode, use extents instead.  This is a  much  more  efficient  encoding  which  speeds  up filesystem access, especially for large files.

-i 8096 은 크기 당 더 많은 inode를 제공하며, 빌딩 환경은 많은 파일을 생성하므로 유용합니다.

소스의 경우 Reiser4 또는 Btrfs 인 압축 즉시 지원을 사용하는 것이 좋습니다. 두 가지 FS를 많이 사용하는 사람들의 이야기를 들어 보았지만, 둘 다 아직 프로덕션 용이 아닙니다. :-)

다음 선택은 (나는 보통 할)입니다 Reiser3 하지 ext3로 . 현재 Ext3는 조금 더 빠를 수 있지만 Reiser3에는 i- 노드 형식 시간 제한이 없으며 "data ="옵션의 온라인 변경을 지원합니다. 더 작은 파일 압축을 허용하는 "꼬리"지원 기능이 있지만 속도가 염려된다면 "꼬리"파일입니다.

XFS와 JFS는 모두 "작은 파일이 많을"경우 특히 고통 스러울 수 있습니다.

(EXT4를 언급하는 것을 잊어 버렸습니다 : 예, 더 빠르면 EXT3입니다. 그러나 위에서 언급 한 모든 EXT3의 한계는 EXT4입니다.)

설명하는 작업은 이상적인 파일 시스템이 수행 할 수있는 작업에 대한 몇 가지 주요 힌트를 제공합니다.

• 빌드 프로세스 중 대규모 랜덤 액세스.
• 많은 파일이 짧은 순서로 업데이트되므로 빠른 메타 데이터 작업이 중요합니다.
• 파일 크기가 매우 큰 파일 시스템에서 많은 작은 파일을 효율적으로 처리합니다.
• 드물고 불명확 한 엣지 케이스에서 데이터가 손실 될 위험이 없습니다.

Btrfs와 Ext4는 위의 세 가지이며 네 번째는 의심 스럽다. Ext4는 아마도 충분히 성숙했지만 btrfs는 아직 베이킹되지 않았습니다. noatime메타 데이터 작업의 효율성을 높이는 데 도움이되지만 새 파일을 여러 개 만들 때 여전히 빠른 속도로 메타 데이터 작업이 필요합니다.

이때 기본 스토리지가 요인이되기 시작합니다. XFS 메타 데이터 작업은 몇 블록에 집중되는 경향이 있으며, 이로 인해 작업이 변형 될 수 있습니다. Ext 스타일 파일 시스템은 메타 데이터를 설명하는 데이터에 더 가깝게 만드는 데 더 좋습니다. 그러나 스토리지가 충분히 추상적 인 경우 (VPS에서 실행 중이거나 SAN에 연결되어있는 경우) 중요하지 않습니다 .

각 파일 시스템에는 약간의 속도 향상이 거의 없어서 몇 가지 더 많은 백분율 포인트를 얻을 수 있습니다. 기본 스토리지의 성능은 얼마나 많은 이익을 얻는 지에 크게 영향을 미칩니다.

스토리지 측면에서 볼 때 스토리지에 충분한 I / O 작업 오버 헤드가 있으면 파일 시스템 비 효율성이 그다지 중요하지 않습니다. 빌드 파티션에 SSD를 사용하는 경우 파일 시스템 선택은 작업하기에 편한 것보다 덜 중요합니다.

작은 파일이 많을 때는 ext3, xfs, jfs보다 Reiser를 권장하지만 ext4가 이전 액세스 방식보다 이전 화신보다 훨씬 우수하다는 것을 들었습니다.

Reiser는 많은 파일 구조를 아이 노드 트리 위로 푸시하므로 작은 파일을 다룰 때 정말 잘 작동합니다.

그러나 주요 파일 시스템 간의 동작 차이는 효과적으로 캐시 / 버퍼링하기에 충분한 물리적 메모리를 확보함으로써 얻을 수있는 이점에 비해 상대적으로 작습니다.

디렉토리를 스캔하여 어떤 파일이 수정되었는지 확인합니다.

비교적 간단하지만 문제를 해결할 수있는 방법입니다. 그것이 중요하다면 , 모드를 색인화하기 위해 inotify 핸들러를 작성하는 것을 고려하십시오.

OTOH, 플래시 SSD를 사용하는 경우 (검색 시간이 매우 짧음) 장수로 인해보다 효과적으로 쓰기를 배포하는 fs를 사용하는 것이 좋습니다. 예 : JFFS2