"inode size"와 "inode 당 바이트"의 차이점은 무엇입니까?


18

아래 정보는 맨 페이지에서 가져온 것입니다. 노드 당 바이트와 Inode 크기의 차이점을 알고 싶습니다.

-i bytes-per-inode

바이트 / 노이드 비율을 지정하십시오. mke2fs는 디스크의 모든 바이트 당 바이트 당 공간에 대해 inode를 만듭니다. 바이트 당 바이트 비율이 클수록 더 적은 inode가 생성됩니다. 이 값은 일반적으로 파일 시스템의 블록 크기보다 작아서는 안됩니다. 너무 많은 inode가 만들어지기 때문에 파일 시스템에서 inode 수를 확장 한 후에는 파일 시스템을 만들 수 없으므로 올바른 결정에 신중해야합니다. 이 매개 변수의 값.

-I inode-size

각 inode의 크기를 바이트 단위로 지정합니다. mke2fs는 기본적으로 256 바이트 inode를 만듭니다. 2.6.10 이후의 커널 및 일부 이전 공급 업체 커널에서는 성능 향상을 위해 확장 된 속성을 저장하기 위해 128 바이트보다 큰 inode를 사용할 수 있습니다. inode 크기 값은 2보다 크거나 같은 128의 전력이어야합니다. -inode 테이블이 사용하는 공간이 많을수록 파일 시스템에서 사용 가능한 공간이 줄어들고 성능에 부정적인 영향을 줄 수 있습니다. 큰 inode에 저장된 확장 된 속성은 이전 커널에서는 보이지 않으며 이러한 파일 시스템은 2.4 커널에서는 마운트 할 수 없습니다 파일 시스템이 작성된 후에는이 값을 변경할 수 없습니다.

답변:


13

우선, inode 란 무엇입니까? 유닉스 세계에서 inode는 일종의 파일 항목입니다. 디렉토리의 파일 이름은 inode에 대한 레이블 (링크!)입니다. inode는 여러 위치에서 참조 할 수 있습니다 (하드 링크!).

-i- 노드 당 바이트 (일명 inode_ratio)

알려지지 않은 이유로이 매개 변수는 언젠가 바이트 당 바이트로 , 때로는 inode_ratio문서화 됩니다. 설명서에 따르면 바이트 / 노이드 비율 입니다. 대부분의 인간은 다음 중 하나라고 말할 때 더 잘 이해할 것입니다.

  • 스토리지의 모든 X 바이트에 대해 1 개의 inode (여기서 X는 바이트 당 바이트 임)
  • 가장 적합한 평균 파일 크기입니다.

공식 ( mke2fs 소스 코드 에서 가져옴 ) :

inode_count = (blocks_count * blocksize) / inode_ratio

또는 단순화 된 경우 ( "파티션 크기"가 대략적으로 같다고 가정 blocks_count * blocksize하면 할당을 확인하지 않았습니다) :

inode_count = (partition_size_in_bytes) / inode_ratio

참고 1 : FS 작성 시간 ( mkfs -N ...)에 고정 된 수의 inode를 제공하더라도 값이 비율로 변환되므로 파일 시스템의 크기를 확장 할 때 더 많은 inode를 맞출 수 있습니다.

참고 2 :이 비율을 조정하면 사용하려는 것보다 훨씬 더 많은 inode를 할당해야합니다. 파일 시스템을 다시 포맷하고 싶지는 않습니다.

-아이 노드 크기

파일 시스템이 가질 수있는 각 inode에 대해 파일 시스템이 할당 / 예약 할 바이트 수입니다. 이 공간은 inode의 속성을 저장하는 데 사용됩니다 ( Intro to Inodes 읽기 ). Ext3에서 기본 크기는 128입니다. Ext4에서 기본 크기는 256입니다 ( extra_isize인라인 확장 속성을위한 공간 을 저장 하고 제공합니다). Linux 읽기 : 왜 inode 크기를 변경해야합니까?

참고 : 사용 가능한지 여부에 관계없이 할당 된 각 inode에 대해 disjkspace의 X 바이트가 할당됩니다 (여기서 X = inode-size).


5

바이트 당 바이트 수는 해당 파일 시스템에 대해 얼마나 많은 inode가 작성되는지 결정합니다. inode-size는 각 inode의 크기를 결정합니다.

파일 시스템에 작은 파일 (및 / 또는 많은 디렉토리)을 많이 넣으려면 많은 inode가 필요합니다 .

AFAIK, 파일의 확장 된 속성 을 저장하려면 기본 크기 인 256 바이트보다 큰 inode 만 필요 합니다. psusi는 의견에서 그것이 올바르지 않다고 말합니다.


4
실제로 확장 된 속성은 inode가 아닌 자체 블록에 저장되므로 더 큰 inode가 필요하지 않습니다. 메일 링리스트에 최근에 떠 다니는 패치가 있었기 때문에 확장 된 속성을 아이 노드에 저장할 수있는 기능을 추가 할 수있게되었습니다.
psusi

1

매우 거친 파일 시스템 회로도 :

|_|__inodes__|_______________________DATA_________________________________|
  • 아이 노드 비율 / 노이즈 당 바이트 = DATA 영역에 대한 아이 노드
  • inode-size = inode 영역 의 각 inode 크기

0

나는 sjas의 대답을 정말로 좋아했습니다. 차이의 본질을 제공합니다.

이것은 단지 내 자신의 확장이며 (이 스택 교환으로 시작하여 의견을 말하거나 투표 할 수 없기 때문에) 데이터 볼륨 중에 결정을 내려야하는 사용자가 이해할 수있는 비 기술적 용어로 균형 잡힌 방식으로 나 자신에 대한 답변을 원했습니다. 설치하지만 반드시 구현 뒤에있는 모든 세부 사항을 알 필요는 없습니다.

개인 / 개체 :-저장 장치에있는 데이터의 볼륨-볼륨에있는 파일-저장 장치, 포맷 및 바이트 블록과 주소를 제공합니다.-저장 장치에있는 파일의 위치

작업 : 저장소의 운영 체제, 파일 읽기 / 쓰기 / 이동, 권한 변경 등으로 파일 및 폴더 만들기 / 삭제 / 이름 바꾸기

N 바이트 크기의 파일은 "청크"(블록)로 작성해야합니다. 이론적으로 파일을 단일 바이트 시퀀스 (논리적으로 가능)로 관리 할 수 ​​있다고 생각할 수 있지만 공간에서 파일을 관리하는 데 필요한 모든 파일 속성 (이름 등)과 각 파일이 시작되는 위치를 나타내는 지정된 인덱스 저장. 그러나 하드웨어가 "버스"및 "블록"으로 설계된 방식과 성능 고려 사항 "청크"는 특정 크기이며 매체의 블록 크기 (예 : 512 바이트, 4096 바이트)의 배수입니다. 다음 레이어에 파일 위치와 청크를 찾아 메모리에로드하는 등의 방법을 알려줍니다.

하나의 큰 종이 스크롤 (볼륨)을 가지고 있고 여러 페이지 문서를 저장하기 위해 페이지로 구성된 문서 (문자 또는 정보의 비트)로 정보 저장을 설계 해야하는 경우 필요한 것은 색인 (문서 찾기), 저장 공간 페이지 (단순한 페이지 위치). 유닉스 콜 레이션 메커니즘 (아이 노드)과 실제 페이지 절단. inode-size는 색인 항목 크기 (더 많거나 적음)-바이트 당 페이지 크기입니다.

해당 두 설정을 변경 한 결과 :

changin inode-size-일반적으로 변경할 필요가 없으며 기본값을 고수하십시오 (이전에 토론에 게시 된 링크 당)

바이트 당 바이트 수-볼륨에서 만들 수있는 최대 파일 수에 영향을 미칩니다 (사용하지 않는 바이트의 성능 및 "폐기")

종이 롤 비유로 돌아 가기 : "쓰기 및 저장 시스템 중에 예상되는 페이지 크기 인 경우, 그러한 시스템 (또는 다양한 크기의 많은 문서)에서 특정 크기의 문서 (파일)를 작성하여 저장해야한다고 상상해보십시오. "시스템"페이지 크기가 매우 크고 문서 크기가 작 으면 한 페이지에 공백이 있고 작은 파일이 있으면 많은 용지가 낭비 될 수 있습니다. 페이지 크기가 큰 경우-문서에 사용해야하는 페이지 수가 적지 만 마지막 페이지에 "빈 공간 낭비"가 많을 수 있습니다. 그래서 그것은 모두 사용될 파일의 ​​크기와 수에 달려 있습니다. 다른 고려 사항은 많은 페이지의 문서를 찾고 가져 오는 속도입니다.

그것이 의미가 있기를 바랍니다 (나를 위해) .ext 디자인이나 mkfs 옵션의 일부를 심각하게 남용했는지 언급하십시오.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.