EXT4 매우 큰(>1GB) 파일의 경우: 블록 크기를 늘리거나, 블록 클러스터를 사용하거나, 아니면 둘 다 사용하시겠습니까?

Question 1

귀하가 연결한 문서에는 다음과 같이 나와 있습니다(강조).

현재 기본 블록 크기는 4KiB이며, 이는 대부분의 MMU 지원 하드웨어에서 일반적으로 지원되는 페이지 크기입니다. 이건 행운이니까ext4 코드는 페이지 크기를 초과하는 블록 크기를 처리할 준비가 되어 있지 않습니다..

Linux를 실행할 수 있는 잘 알려진 프로세서 아키텍처 중에서 ARM, Alpha AXP, Itanium 또는 PowerPC만이 일반적인 4KiB 이상의 페이지 크기를 사용할 수 있습니다.

AMD64/x86_64 프로세서는 hugepages를 사용할 수 있지만 완전히 동일하지는 않습니다. 기본 시스템 페이지 크기는 여전히 4KiB이지만 hugepages는 대용량 메모리 시스템 효율성에서 메모리 관리를 개선하기 위해 더 큰 번들에 할당할 수 있도록 허용합니다. 이는 "ext4 블록 크기 <= 시스템 메모리 페이지 크기"의 기본 요구 사항을 변경하지 않습니다.

PowerPC 또는 64비트 ARM 프로세서를 사용하면 페이지 크기(시스템 메모리 관리의 기본 "블록 크기")를 64KiB로 늘릴 수 있으므로 ext4 파일 시스템이 내부 작업도 확장할 수 있습니다. AMD64/x86_64에서는 이 옵션을 사용할 수 없으므로 블록 클러스터링은 파일 시스템 메타데이터에 필요한 공간과 작업을 줄이는 데 사용할 수 있는 유일한 방법입니다.

제가 작업 중인 시스템에는 10TB 이상 범위로 확장되는 ext4 파일 시스템이 있으며, 여기서 파일 시스템 검사를 실행하는 것은 즐거운 경험이 아닙니다. 물론 이것은 파일 시스템이 신중한 조정 없이 시스템의 원래 설계 용량의 한계를 훨씬 넘어 확장된 오래된 시스템입니다. (동영상 서버이기도 합니다.)

그러나 이를 바탕으로 ext4가 수십 테라바이트의 파일 시스템을 성공적으로 처리하려면 특정 튜닝이 반드시 필요하다고 말하고 싶습니다. 댓글의 Romeo Ninov처럼 (가능한 경우) 다른 파일 시스템 유형을 재고해 보시기 바랍니다.할 수 있는10TB보다 큰 파일 시스템에서 사용할 경우 현재 일반적인 한도는 수십TB 이하인 것 같습니다.실제그것과 관련이 있습니다.

그러나 기본적으로 파일 시스템의 내용을 한 번 작성한 다음 읽기 전용으로 유지하면 파일 시스템 검사를 실행할 필요가 거의 없으므로 큰 어려움을 피할 수 있습니다.

Answer

귀하가 연결한 문서에는 다음과 같이 나와 있습니다(강조).

현재 기본 블록 크기는 4KiB이며, 이는 대부분의 MMU 지원 하드웨어에서 일반적으로 지원되는 페이지 크기입니다. 이건 행운이니까ext4 코드는 페이지 크기를 초과하는 블록 크기를 처리할 준비가 되어 있지 않습니다..

Linux를 실행할 수 있는 잘 알려진 프로세서 아키텍처 중에서 ARM, Alpha AXP, Itanium 또는 PowerPC만이 일반적인 4KiB 이상의 페이지 크기를 사용할 수 있습니다.

AMD64/x86_64 프로세서는 hugepages를 사용할 수 있지만 완전히 동일하지는 않습니다. 기본 시스템 페이지 크기는 여전히 4KiB이지만 hugepages는 대용량 메모리 시스템 효율성에서 메모리 관리를 개선하기 위해 더 큰 번들에 할당할 수 있도록 허용합니다. 이는 "ext4 블록 크기 <= 시스템 메모리 페이지 크기"의 기본 요구 사항을 변경하지 않습니다.

PowerPC 또는 64비트 ARM 프로세서를 사용하면 페이지 크기(시스템 메모리 관리의 기본 "블록 크기")를 64KiB로 늘릴 수 있으므로 ext4 파일 시스템이 내부 작업도 확장할 수 있습니다. AMD64/x86_64에서는 이 옵션을 사용할 수 없으므로 블록 클러스터링은 파일 시스템 메타데이터에 필요한 공간과 작업을 줄이는 데 사용할 수 있는 유일한 방법입니다.

제가 작업 중인 시스템에는 10TB 이상 범위로 확장되는 ext4 파일 시스템이 있으며, 여기서 파일 시스템 검사를 실행하는 것은 즐거운 경험이 아닙니다. 물론 이것은 파일 시스템이 신중한 조정 없이 시스템의 원래 설계 용량의 한계를 훨씬 넘어 확장된 오래된 시스템입니다. (동영상 서버이기도 합니다.)

그러나 이를 바탕으로 ext4가 수십 테라바이트의 파일 시스템을 성공적으로 처리하려면 특정 튜닝이 반드시 필요하다고 말하고 싶습니다. 댓글의 Romeo Ninov처럼 (가능한 경우) 다른 파일 시스템 유형을 재고해 보시기 바랍니다.할 수 있는10TB보다 큰 파일 시스템에서 사용할 경우 현재 일반적인 한도는 수십TB 이하인 것 같습니다.실제그것과 관련이 있습니다.

그러나 기본적으로 파일 시스템의 내용을 한 번 작성한 다음 읽기 전용으로 유지하면 파일 시스템 검사를 실행할 필요가 거의 없으므로 큰 어려움을 피할 수 있습니다.

Question 2

Ext4는 최대 16TiB의 파일과 최대 1PiB의 파일 시스템을 합리적으로 처리할 수 있으며 세계에서 가장 큰 일부 병렬 파일 시스템에서 이러한 크기로 자주 사용됩니다(참조:https://en.wikipedia.org/wiki/Lustre_(파일 시스템)더 알아보기). 1GiB 파일과 12TiB HDD는 문제를 일으키지 않습니다.

내 홈 파일 서버에는 ext4를 사용하는 여러 개의 10TiB 드라이브가 있습니다. 범위 및 기타 기능을 활성화하는 기본 mke2fs 옵션은 우수한 성능을 제공해야 합니다.

largefile옵션 의 경우 ,알다대부분의 파일은 매우 큽니다. 그러나 전체적인 절감 효과는 그다지 크지 않으며 아마도 그만한 가치가 없을 것입니다. 또한 백업을 위해 미디어 서버를 사용하게 되었는데, 이로 인해 작은 파일이 많이 생성되었습니다.

Answer

Ext4는 최대 16TiB의 파일과 최대 1PiB의 파일 시스템을 합리적으로 처리할 수 있으며 세계에서 가장 큰 일부 병렬 파일 시스템에서 이러한 크기로 자주 사용됩니다(참조:https://en.wikipedia.org/wiki/Lustre_(파일 시스템)더 알아보기). 1GiB 파일과 12TiB HDD는 문제를 일으키지 않습니다.

내 홈 파일 서버에는 ext4를 사용하는 여러 개의 10TiB 드라이브가 있습니다. 범위 및 기타 기능을 활성화하는 기본 mke2fs 옵션은 우수한 성능을 제공해야 합니다.

largefile옵션 의 경우 ,알다대부분의 파일은 매우 큽니다. 그러나 전체적인 절감 효과는 그다지 크지 않으며 아마도 그만한 가치가 없을 것입니다. 또한 백업을 위해 미디어 서버를 사용하게 되었는데, 이로 인해 작은 파일이 많이 생성되었습니다.

Question 3

TelcoM의 답변 확장... x86[-64]에서 4Kb 이외의 블록 크기를 사용하려면 커널을 다시 컴파일해야 합니다. 이것은 32비트 커널을 사용하는 대규모 파일 시스템을 지원하는 유일한 방법이었습니다. 그러나 대용량 파일 지원과 64비트 inode가 등장했습니다. 요즘에는(아직 32비트에서 실행하지 않는 한) 파일 시스템이 64비트를 사용한다고 mount/fstab에 알릴 필요조차 없습니다. 하지만 인터넷에는 여전히 오래된 정보가 많이 있습니다(예: 현재 aws 설명서 -https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/volume_constraints.html).

ext4의 블록 클러스터는 32비트 inode/4k 블록 크기에 대한 해결 방법을 제공합니다.

그러나 이것은 더 이상 관련이 없을 뿐만 아니라 32비트 inode + 4K 블록 크기는 전체 블록 장치 크기를 16Tb로 제한하며 12개만 갖습니다.

다양한 크기의 블록(또는 블록 클러스터)을 사용하는 이유가 있습니다. IIRC, Oracle 및 MySQL은 모두 내부적으로 8k 블록 크기를 사용하며 파일 시스템에서 이 크기를 일치시키면 처리량이 크게 향상됩니다.

따라서... 아니요, 영리한 작업을 수행할 필요가 없습니다(파티션할 때 MBR 대신 GPT를 사용하는 경우 제외).

Answer