.png)
모호한 기억으로 인해 Linux 파티션을 생성할 때 기본 설정을 "개선"하고 inode 크기를 1024로 늘리고 또한 활성화할 것이라고 생각했습니다 -O bigalloc("이 ext4 기능은 클러스터 블록 할당을 활성화합니다").
그러나 지금은 온라인에 인용된 이러한 설정의 구체적인 이점을 찾을 수 없으며 디스크 사용량이 20%일 때 이미 inode의 15%를 사용하고 있음을 발견했습니다.
그러면 단순히 파티션을 다시 포맷해야 합니까, 아니면 긍정적인 견해를 가져야 합니까(또는 정당화로 사용해야 합니까)? 예를 들어, 파일 수가 많은 디렉토리의 경우?
답변1
메타데이터가 많은 파일이 많은 경우 더 큰 inode가 유용합니다. 클래식 메타데이터(권한, 타임스탬프 등)를 수용할 수 있는 최소 inode 크기여러 개의 주소 블록일반 파일이나 짧은 심볼릭 링크의 대상입니다.더 큰 인덱스 노드저장될 수 있다확장된 속성예를 들어액세스 제어 목록그리고SELinux 컨텍스트. 확장된 속성을 수용할 만큼 inode에 공간이 충분하지 않은 경우 별도의 블록에 저장해야 하므로 파일을 열거나 해당 메타데이터를 읽는 속도가 느려집니다.
따라서 많은 수의 inode를 보유하려는 경우 더 큰 inode 크기를 사용해야 합니다.확장된 속성예를 들어 복잡한 ACL 또는 SELinux를 사용하는 경우입니다. SELinux는 더 큰 inode를 만드는 주요 동기입니다.
답변2
inode 크기가 커지면 디스크 사용량이 늘어나는 대신 매우 큰 파일/디렉터리의 성능이 향상될 수 있습니다(작은 파일의 경우 성능이 저하될 수 있음).
inode 사용량이 너무 높다고 생각되면 inode당 바이트 비율을 자세히 살펴봐야 합니다. 다양한 StackExchange 사이트에 관련 Q&A가 많이 있습니다.
답변3
디스크 사용량 20%, inode 사용량 15%도 나쁘지 않습니다. 20% 디스크 사용량과 100% inode 사용량이 문제가 될 수 있습니다. 문제는 100% 디스크 사용량 이전에 100% inode 사용량에 도달했는지 여부입니다. 이는 더 많은 인덱스 노드가 필요한 때입니다.
이는 파일 시스템을 사용하는 방법에 따라 크게 달라집니다. 예를 들어, 사진이나 비디오 또는 일정한 크기의 유사한 파일만 보관하는 파티션인 경우에는 걱정할 필요가 없습니다.
사용법이 무작위이고 나중에 일부 커널 소스 tarball을 가져올 수 있는 경우 현재 비율이 유지되지 않을 수 있습니다...
성능 측면에서는 일반적인 상황에서는 차이를 느끼지 못할 것이며 연중무휴로 작동하는 데이터베이스와 같이 한계를 뛰어넘는 애플리케이션이 없는 한 작은 최적화라도 성과를 거둘 것입니다.
답변4
각 파일은 최소 1개의 inode를 소비 하며 , 파일이 충분히 크면 더 많은 inode를 소비합니다 . 이론적으로 파티션이 많은 대용량 파일로 구성되면 더 적은 수의 inode가 필요합니다. inode 수가 적다는 것은 데이터 디스크 공간이 더 많다는 것을 의미합니다. 특정 애플리케이션은 데이터베이스 파티셔닝으로, 데이터베이스는 대부분의 데이터를 몇 개의 대용량 파일(예: Oracle, MySQL 및 innodb)에 보관합니다. "bigalloc"이라고 말하면 "big"으로 /etc/mke2fs.conf설정된 것과 같은 CentOS7 의 사전 설정 중 하나를 의미한다고 가정합니까 ? 확실하지는 않지만 이것이 기본적으로 "inode당 바이트 수" 매개변수에 대한 매개변수인 것 같습니다 . 이러한 가정이 정확하다면 복사본의 형식을 다시 지정해야 합니다.inode_ratio32768mke2fs-i
inode당 바이트 비율이 높을수록 생성되는 inode 수가 줄어듭니다. 이 값은 일반적으로 파일 시스템의 블록 크기보다 작아서는 안 됩니다. 이 경우 사용할 수 있는 것보다 더 많은 inode가 생성되기 때문입니다. 파일 시스템이 생성된 후에는 이 비율을 변경할 수 없으므로 주의하여 이 매개변수의 올바른 값을 결정하세요. 파일 시스템 크기를 조정하면 이 비율을 유지하기 위해 inode 수가 변경됩니다.