다음 정보는 매뉴얼 페이지에서 가져온 것입니다. inode당 바이트 수와 inode 크기의 차이를 알고 싶습니다.
-i bytes-per-inode
바이트/아이노드 비율을 지정합니다. mke2fs는 디스크의 각 inode 바이트 공간에 대해 inode를 생성합니다. inode당 바이트 비율이 높을수록 생성되는 inode 수가 줄어듭니다. 이 값은 일반적으로 파일 시스템의 블록 크기보다 작아서는 안 됩니다. 그렇지 않으면 너무 많은 inode가 생성됩니다. 파일 시스템이 생성된 후에는 파일 시스템의 inode 수를 확장할 수 없으므로 이 매개변수의 올바른 값을 결정할 때 주의해야 합니다.
-I inode-size
각 inode의 크기를 바이트 단위로 지정합니다. mke2fs는 기본적으로 256바이트 inode를 생성합니다. 2.6.10 이후의 커널과 일부 이전 공급업체 커널에서는 128바이트보다 큰 inode를 활용하여 확장된 속성을 저장하여 성능을 향상시킬 수 있습니다. inode-size 값은 128보다 크거나 같은 2의 거듭제곱이어야 합니다. inode 크기가 클수록 inode 테이블이 더 많은 공간을 소비하므로 파일 시스템에서 사용 가능한 공간이 줄어들고 성능에도 부정적인 영향을 미칩니다. 큰 inode에 저장된 확장 속성은 이전 커널에서 볼 수 없으며 이러한 파일 시스템은 2.4 커널 설치에서 작동하지 않습니다. 파일 시스템이 생성된 후에는 이 값을 변경할 수 없습니다.
답변1
좋아요, 우선, inode가 무엇인가요? Unix 세계에서 inode는 파일 항목입니다. 디렉터리의 파일 이름은 인덱스 노드(링크!)의 레이블일 뿐입니다. inode는 여러 위치에서 참조될 수 있습니다(하드 링크!).
-i inode당 바이트 수(inode_ratio라고도 함)
알 수 없는 이유로 이 매개변수는 때때로 다음과 같이 기록됩니다.inode당 바이트때로는아이노드 비율. 문서에 따르면 이것은바이트/Inode 비율. 대부분의 사람들은 다음 중 하나를 설명하면 더 잘 이해할 수 있습니다.
- X바이트의 저장 공간마다 1개의 inode가 있습니다(여기서 X는 inode당 바이트 수).
- 수용할 수 있는 가장 낮은 평균 파일 크기입니다.
공식 (에서 가져옴mke2fs 소스 코드):
inode_count = (blocks_count * blocksize) / inode_ratio
또는 단순화할 수도 있습니다("파티션 크기"가 대략 동일하다고 가정하고 blocks_count * blocksize할당을 확인하지 않았습니다).
inode_count = (partition_size_in_bytes) / inode_ratio
참고 1: FS 생성 시 고정된 수의 inode를 제공하더라도( mkfs -N ...) 파일 시스템 크기 확장 시 더 많은 inode를 수용할 수 있도록 해당 값이 비율로 변환됩니다.
참고 2: 이 비율을 조정하는 경우 사용하려는 것보다 훨씬 더 많은 inode를 할당해야 합니다. 파일 시스템을 다시 포맷하고 싶지는 않을 것입니다.
-I 인덱스 노드 크기
이는 파일 시스템이 가질 수 있는 각 inode에 대해 파일 시스템이 할당/예약할 바이트 수입니다. 이 공간은 inode 속성을 저장하는 데 사용됩니다(읽기인덱스 노드 소개). Ext3에서 기본 크기는 128입니다. Ext4에서 기본 크기는 256입니다( extra_isize인라인 확장 속성 저장소를 위한 공간을 저장하고 제공하는 데 사용됨). 읽다Linux: inode 크기를 변경하는 이유는 무엇입니까?
참고: X바이트의 disjkspace는 사용 가능 여부에 관계없이 할당된 각 inode에 대해 할당됩니다. 여기서 X는 inode-size입니다.
답변2
inode당 바이트 수는 파일 시스템에 생성되는 inode 수를 결정하고 inode-size는 각 inode의 크기를 결정합니다.
넣을 계획이라면 많은 inode가 필요합니다위치파일 시스템의 작은 파일(및/또는 큰 디렉터리)
AFAIK, 스토리지를 원할 경우 기본 크기인 256바이트보다 큰 inode만 필요합니다.확장된 속성당신의 파일을 위해.
psusi는 댓글에서 이것이 틀렸다고 말했습니다.
답변3
파일 시스템의 대략적인 다이어그램:
|_|__inodes__|_______________________DATA_________________________________|
- 노드 비율/inode당 바이트= 아이노드 수데이터영역
- 인덱스 노드 크기= 각 inode의 크기인덱스 노드영역
답변4
나는 sjas의 답변을 정말 좋아합니다. 차이점의 본질을 제공합니다.
이것은 단지 내 자신의 확장일 뿐이므로(이 스택 교환에서 시작하여 댓글을 달거나 투표할 수 없기 때문에) 필요한 사람들을 위해 균형 잡힌 방식으로 비기술적인 용어로 설명하는 답변을 제공하고 싶었습니다. 데이터 볼륨 중에 의사 결정 사용자는 설정을 이해할 수 있지만 반드시 구현 뒤의 모든 세부 사항을 이해할 수는 없습니다.
역할/객체: - 저장 장치의 데이터 볼륨 - 볼륨의 파일 - 포맷되고 바이트 블록과 해당 주소를 제공하는 저장 장치 - 저장 장치의 파일 위치
작업: 운영 체제를 통해 저장소의 파일 및 폴더 생성/삭제/이름 바꾸기, 파일 읽기/쓰기/이동, 권한 변경 등.
N바이트 크기의 파일은 "청크"(청크)로 생성되어야 합니다. 이론적으로는 파일을 단일 바이트 시퀀스로 관리할 수 있다고 생각할 수 있지만(논리적으로는 가능함), 공간에서 파일을 관리하는 데 필요한 것은 일부 파일 속성(이름 등)을 알려주는 지정된 인덱스뿐입니다. 각 파일의 시작 위치 저장됩니다. 그러나 하드웨어 설계 및 성능 고려 사항의 "버스" 및 "블록" 접근 방식으로 인해 이러한 "블록"은 미디어 블록 크기의 배수(예: 512바이트, 4096바이트)인 특정 크기를 가지며 inodes 레이어, 이 레이어는 다음 레이어에 파일의 위치와 청크를 조회하고 메모리에 로드해야 할 때 청크가 어떻게 연결되는지 알려줍니다.
큰 종이 롤(롤)이 있고 여러 페이지의 문서를 저장하기 위해 페이지(문자 또는 정보 비트)로 구성된 문서에 대한 정보 저장소를 설계해야 하는 경우 필요한 것은 인덱스입니다(문서를 찾기 위해). 문서)는 페이지의 공간을 저장합니다(간단한 페이지 배치 사용). Unix 정렬 메커니즘(인덱스 노드) 및 실제 페이지 항목. inode-size는 인덱스 항목 크기(다소)입니다. inode당 바이트는 페이지 크기입니다.
두 가지 관련 설정 변경의 효과:
inode 크기 변경 - 일반적으로 변경이 필요하지 않으며 기본값을 유지합니다(이전에 논의된 답변에 게시된 링크에 따라).
inode당 바이트 - 볼륨에서 생성할 수 있는 최대 파일 수에 영향을 미칩니다(잠재적으로 성능 및 사용되지 않은 바이트의 "낭비").
종이 롤 비유로 돌아가서: "쓰기 및 저장 시스템" 정의 중에 페이지 크기가 렌더링되는 경우 이러한 시스템에서 특정 크기(또는 크기가 다른 여러 문서)의 문서(파일)를 작성하고 저장해야 한다고 상상해 보십시오. 유연하지 않고, 동일한 문서에 많은 페이지가 필요할 수 있으며, "시스템" 페이지 크기가 매우 크고 문서 크기가 작을 경우 한 페이지에 공백을 남겨두고 그 안에 작은 파일을 넣어서 많은 종이가 낭비될 수 있습니다. 페이지가 더 큰 경우 - 문서는 더 적은 페이지를 사용해야 하지만 마지막에 사용되는 페이지에는 "낭비된 빈 공간"이 많을 수 있으므로 모두 크기와 파일 수에 따라 달라집니다. 또 다른 고려 사항은 여러 페이지로 구성된 문서를 찾고 검색하는 속도입니다.
(저에게) 이해가 되기를 바랍니다. 제가 확장 디자인이나 mkfs 옵션의 어떤 부분을 심하게 오용하고 있다면 댓글을 달아주세요.