나는 현재 사용하고 있습니다backintime내 파일 시스템의 "스냅샷"을 찍습니다. 그것은 비슷하다rsnapshot그 중 변경되지 않은 파일에 대한 하드 링크가 만들어집니다. 최근에 내 파일 시스템에 inode가 부족해졌습니다 EXT4. df -hi940만 개의 inode를 사용한 것으로 나타납니다. 현재 디렉터리 수에 스냅샷 수와 현재 파일 수를 곱하여 대략적으로 계산하면 실제로 940만 개의 inode를 사용하고 있는 것으로 나타났습니다.
내가 아는 바로는 EXT4파일 시스템은 약 2^32개의 inode를 지원할 수 있습니다. 40억 개 정도의 inode를 모두 사용하도록 파티션을 다시 포맷하는 것을 고려하고 있지만 유감스럽게도 그것은 나쁜 생각입니다. 파일 시스템에 너무 많은 inode를 갖는 것의 단점은 무엇입니까 EXT4? 이와 같은 애플리케이션에 더 나은 파일 시스템 옵션이 있습니까?
답변1
이것은 매우 나쁜 생각입니다. 각 inode는 256바이트를 소비합니다(128바이트로 구성 가능). 따라서 inode만으로도 1TiB의 공간을 소비하게 됩니다.
다른 파일 시스템(예: btrfs)은 inode를 동적으로 생성할 수 있습니다. 대신 다음 중 하나를 사용하세요.
답변2
이 점은 아무리 강조해도 지나치지 않습니다. 수많은 inode를 생성하지 마세요!
첫째, fsck이러한 문제 중 일부는 ext4에서 해결되었지만 런타임은 기하급수적으로 확장될 수 있습니다. 게다가, inode만이 파일 수를 제한하는 것이 아니며, 모두 사용하는 것이 불가능할 수도 있습니다. 이는 실용적일 뿐만 아니라 실제로 기술적으로 불가능합니다.
mkfs 매뉴얼 페이지에서 발췌,
-i inode당 바이트 바이트/inode 비율을 지정합니다. mke2fs는 디스크의 각 inode 바이트 공간에 대해 inode를 생성합니다. inode당 바이트 비율이 높을수록 생성되는 inode 수가 줄어듭니다. 이 값은 일반적으로 파일 시스템의 블록 크기보다 작아서는 안 됩니다. 이 경우 사용할 수 있는 것보다 더 많은 inode가 생성되기 때문입니다. 파일 시스템은 생성된 후에는 inode 수만큼 확장될 수 없으므로 주의하여 이 매개변수의 올바른 값을 결정해야 합니다.
OP의 새 파일 시스템을 생성할 때 OP는 실제로 inode당 최대 바이트 수 = 블록 크기를 계산하기 시작해야 합니다. 나중에 이 내용을 읽는 모든 사람에게 OP는 매우 특이한 상황에 처해 있으며 많은 문서를 가지고 있습니다.