Linux의 inode에 대해 알고 싶었던 모든 것

Linux 파일 시스템은 inode에 의존합니다. 파일 시스템의 내부 작동 중 이러한 중요한 부분은 종종 오해를받습니다. 정확히 무엇인지, 무엇을하는지 살펴 보겠습니다.

파일 시스템의 요소

정의에 따라 파일 시스템은 파일을 저장해야하며 디렉토리도 포함합니다. 파일은 디렉토리 내에 저장되며 이러한 디렉토리에는 하위 디렉토리가있을 수 있습니다. 어딘가에 파일 시스템 내에서 모든 파일이있는 위치, 파일 이름, 파일이 속한 계정, 권한 등을 기록해야합니다. 이 정보는 다른 데이터를 설명하는 데이터이기 때문에 메타 데이터라고합니다.

Linux ext4 파일 시스템에서 inode 및 디렉토리 구조는 함께 작동하여 모든 파일 및 디렉토리에 대한 모든 메타 데이터를 저장하는 기반 프레임 워크를 제공합니다. 커널, 사용자 응용 프로그램 또는 Linux 유틸리티 (예 : ls,, stat) 등 메타 데이터가 필요한 모든 사람이 메타 데이터를 사용할 수 있습니다 df.

Inode 및 파일 시스템 크기

사실 한 쌍의 구조가 있지만 파일 시스템에는 그 이상이 필요합니다. 각 구조에는 수천, 수천이 있습니다. 모든 파일과 디렉토리에는 inode가 필요하며 모든 파일이 디렉토리에 있으므로 모든 파일에도 디렉토리 구조가 필요합니다. 디렉토리 구조는 디렉토리 항목 또는 "dentries"라고도합니다.

각 inode에는 파일 시스템 내에서 고유 한 inode 번호가 있습니다. 동일한 inode 번호가 둘 이상의 파일 시스템에 나타날 수 있습니다. 그러나 파일 시스템 ID와 inode 번호가 결합되어 Linux 시스템에 마운트 된 파일 시스템 수에 관계없이 고유 한 식별자를 만듭니다.

Linux에서는 하드 드라이브 나 파티션을 마운트하지 않습니다. 파티션에있는 파일 시스템을 마운트하므로 인식하지 않고도 여러 파일 시스템을 쉽게 가질 수 있습니다. 단일 드라이브에 여러 하드 드라이브 또는 파티션이있는 경우 파일 시스템이 두 개 이상있는 것입니다. 예를 들어 모든 ext4와 같이 동일한 유형일 수 있지만 여전히 별개의 파일 시스템입니다.

모든 inode는 하나의 테이블에 보관됩니다. inode 번호를 사용하여 파일 시스템은 해당 inode가있는 inode 테이블의 오프셋을 쉽게 계산합니다. inode의 "i"가 인덱스를 나타내는 이유를 알 수 있습니다.

inode 번호를 포함하는 변수는 소스 코드에서 부호없는 32 비트 정수로 선언됩니다. 즉, inode 번호는 최대 크기가 2 ^ 32 인 정수 값으로, 4,294,967,295로 계산됩니다. 이는 40 억 inode가 훨씬 넘습니다.

그것은 이론적 최대치입니다. 실제로 ext4 파일 시스템의 inode 수는 파일 시스템 용량 16KB 당 inode 하나의 기본 비율로 파일 시스템이 생성 될 때 결정됩니다. 디렉토리 구조는 파일 시스템 내에서 파일과 디렉토리가 생성되므로 파일 시스템이 사용 중일 때 즉석에서 생성됩니다.

컴퓨터의 파일 시스템에있는 inode의 수를 확인하는 데 사용할 수있는 명령이 있습니다. 명령 의 -i(inodes) 옵션은 df출력을 inode 수로 표시하도록 지시합니다.

첫 번째 하드 드라이브의 첫 번째 파티션에있는 파일 시스템을 살펴 보려고하므로 다음을 입력합니다.

df -i / dev / sda1

결과는 다음과 같습니다.

• 파일 시스템 :보고되는 파일 시스템입니다.
• Inodes :이 파일 시스템에있는 총 inode 수입니다.
• IUsed : 사용중인 inode의 수입니다.
• IFree : 사용할 수있는 나머지 inode 수입니다.
• IUse % : 사용 된 inode의 백분율.
• 마운트 위치 :이 파일 시스템의 마운트 지점입니다.

이 파일 시스템에서 10 %의 inode를 사용했습니다. 파일은 하드 드라이브에 디스크 블록으로 저장됩니다. 각 inode는 그들이 나타내는 파일의 내용을 저장하는 디스크 블록을 가리 킵니다. 수백만 개의 작은 파일이있는 경우 하드 드라이브 공간이 부족하기 전에 inode가 부족할 수 있습니다. 그러나 그것은 실행하기 매우 어려운 문제입니다.

과거에는 이메일 메시지를 개별 파일로 저장 한 일부 메일 서버 (작은 파일의 대규모 컬렉션으로 빠르게 이어지는)에이 문제가있었습니다. 이러한 응용 프로그램이 백엔드를 데이터베이스로 변경했을 때 문제가 해결되었습니다. 일반적인 홈 시스템에는 inode가 부족하지 않습니다. ext4 파일 시스템을 사용하면 파일 시스템을 다시 설치하지 않고는 더 많은 inode를 추가 할 수 없기 때문입니다.

파일 시스템의 디스크 블록 크기를 보려면 (get block size) 옵션 blockdev과 함께 명령을 사용할 수 있습니다 --getbsz.

sudo blockdev --getbsz / dev / sda

블록 크기는 4096 바이트입니다.

-B(block size) 옵션을 사용하여 4096 바이트의 블록 크기를 지정하고 일반 디스크 사용량을 확인 하겠습니다 .

df -B 4096 / dev / sda1

이 출력은 다음을 보여줍니다.

• 파일 시스템 :보고하는 파일 시스템입니다.
• 4K 블록 :이 파일 시스템에있는 총 4KB 블록 수입니다.
• 사용됨 : 사용중인 4K 블록 수.
• 사용 가능 : 사용 가능한 나머지 4KB 블록 수입니다.
• Use % : 사용 된 4KB 블록의 백분율입니다.
• 마운트 위치 :이 파일 시스템의 마운트 지점입니다.

이 예에서 파일 저장소 (및 inode 및 디렉토리 구조의 저장소)는이 파일 시스템 공간의 28 %를 inode의 10 % 비용으로 사용 했으므로 상태가 양호합니다.

Inode 메타 데이터

파일의 inode 번호를 보려면 (inode) 옵션 ls과 함께 사용할 수 있습니다 -i.

ls -i geek.txt

이 파일의 inode 번호는 1441801이므로이 inode는이 파일에 대한 메타 데이터와 일반적으로 하드 드라이브에서 파일이있는 디스크 블록에 대한 포인터를 보유합니다. 파일이 조각화되거나 매우 크거나 둘 다인 경우 inode가 가리키는 일부 블록은 다른 디스크 블록에 대한 추가 포인터를 보유 할 수 있습니다. 그리고 다른 디스크 블록 중 일부는 다른 디스크 블록 세트에 대한 포인터를 보유 할 수도 있습니다. 이것은 고정 된 크기의 inode 문제를 극복하고 디스크 블록에 대한 제한된 수의 포인터를 보유 할 수 있습니다.

이 방법은 "범위"를 사용하는 새로운 체계로 대체되었습니다. 이들은 파일을 저장하는 데 사용되는 각 연속 블록 세트의 시작 및 끝 블록을 기록합니다. 파일이 조각화되지 않은 경우 첫 번째 블록과 파일 길이 만 저장하면됩니다. 파일이 조각난 경우 파일 각 부분의 첫 번째와 마지막 블록을 저장해야합니다. 이 방법은 (분명히) 더 효율적입니다.

파일 시스템이 디스크 블록 포인터 또는 익스텐트를 사용하는지 확인하려면 inode 내부를 살펴볼 수 있습니다. 이를 위해 (request) 옵션 debugfs과 함께 명령을 사용하고 -R관심있는 파일의 inode를 전달합니다. 이것은 debugfs 내부 "stat"명령을 사용하여 inode의 내용을 표시 하도록 요청  합니다. inode 번호는 파일 시스템 내에서만 고유하므로 inode가있는 파일 시스템에도 알려야 debugfs 합니다.

이 예제 명령은 다음과 같습니다.

sudo debugfs -R "stat"/ dev / sda1

아래에 표시된 debugfs대로이 명령은 inode에서 정보를 추출하여 다음 위치에 표시합니다 less.

다음 정보가 표시됩니다.

• Inode : 우리 가보고 있는 inode의 수.
• 유형 : 디렉토리 나 심볼릭 링크가 아닌 일반 파일입니다.
• 모드 : 8 진수 파일 권한.
• 플래그 : 다양한 기능을 나타내는 표시기입니다. 0x80000은 "extents"플래그입니다 (아래에서 자세히 설명).
• 생성 : 네트워크 파일 시스템 (NFS)은 누군가가 마치 로컬 시스템에 마운트 된 것처럼 네트워크 연결을 통해 원격 파일 시스템에 액세스 할 때 이것을 사용합니다. inode 및 세대 번호는 파일 핸들의 한 형태로 사용됩니다.
• 버전 : inode 버전입니다.
• 사용자 : 파일 소유자입니다.
• 그룹 : 파일의 그룹 소유자입니다.
• 프로젝트 : 항상 0이어야합니다.
• 크기 : 파일의 크기입니다.
• 파일 ACL : 파일 액세스 제어 목록입니다. 소유자 그룹에없는 사람들에게 제어 된 액세스 권한을 부여 할 수 있도록 설계되었습니다.
• 링크 : 파일에 대한 하드 링크의 수입니다.
• Blockcount : 512 바이트 청크로 주어진이 파일에 할당 된 하드 드라이브 공간의 양. 우리 파일에는 4,096 바이트 인이 중 8 개가 할당되었습니다. 따라서 98 바이트 파일은 단일 4,096 바이트 디스크 블록 내에 있습니다.
• 조각 :이 파일은 조각화되지 않았습니다. (사용되지 않는 플래그입니다.)
• Ctime : 파일이 생성 된 시간입니다.
• Atime :이 파일이 마지막으로 액세스 된 시간입니다.
• Mtime :이 파일이 마지막으로 수정 된 시간입니다.
• Crtime : 파일이 생성 된 시간입니다.
• 추가 inode 필드의 크기 : ext4 파일 시스템은 포맷시 더 큰 온 디스크 inode를 할당하는 기능을 도입했습니다. 이 값은 inode가 사용하는 추가 바이트 수입니다. 이 추가 공간은 새 커널에 대한 향후 요구 사항을 수용하거나 확장 된 속성을 저장하는데도 사용할 수 있습니다.
• Inode 체크섬 :이 inode에 대한 체크섬으로, inode가 손상되었는지 감지 할 수 있습니다.
• 익스텐트 : 익스텐트가 사용되는 경우 (ext4에서는 기본적으로 사용됨) 파일의 디스크 블록 사용과 관련된 메타 데이터에는 조각난 파일의 각 부분의 시작 및 끝 블록을 나타내는 두 개의 숫자가 있습니다. 이것은 파일의 각 부분이 차지하는 모든 디스크 블록을 저장하는 것보다 효율적입니다. 이 블록 오프셋에서 작은 파일이 하나의 디스크 블록에 있기 때문에 익스텐트가 하나 있습니다.

파일 이름은 어디에 있습니까?

이제 파일에 대한 많은 정보를 얻었지만 아시다시피 파일 이름을 얻지 못했습니다. 이것이 디렉토리 구조가 작용하는 곳입니다. Linux에서는 파일과 마찬가지로 디렉토리에 inode가 있습니다. 그러나 디렉토리 inode는 파일 데이터를 포함하는 디스크 블록을 가리키는 대신 디렉토리 구조를 포함하는 디스크 블록을 가리 킵니다.

inode와 비교하여 디렉토리 구조에는 파일에 대한 제한된 양의 정보가 포함됩니다. 파일의 inode 번호, 이름 및 이름의 길이 만 보유합니다.

inode 및 디렉토리 구조에는 파일 또는 디렉토리에 대해 알아야하는 모든 것이 포함됩니다. 디렉토리 구조는 디렉토리 디스크 블록에 있으므로 파일이있는 디렉토리를 알고 있습니다. 디렉토리 구조는 파일 이름과 inode 번호를 제공합니다. inode는 타임 스탬프, 권한 및 파일 시스템에서 파일 데이터를 찾을 위치를 포함하여 파일에 대한 다른 모든 것을 알려줍니다.

디렉토리 Inode

파일에서 볼 수있는 것처럼 쉽게 디렉토리의 inode 번호를 볼 수 있습니다.

다음 예제에서, 우리는 사용합니다 ls 로 -l(긴 형식), -i(아이 노드), 및 -d상기 (디렉토리) 옵션,보기 work디렉토리 :

ls -lid 작업 /

-d(directory) 옵션  을 사용했기 때문에 ls내용이 아닌 디렉토리 자체에 대해보고합니다. 이 디렉토리의 inode는 1443016입니다.

home디렉토리에 대해 반복하려면 다음을 입력합니다.

ls -lid ~

home디렉토리 의 inode 는 1447510이고 work디렉토리는 홈 디렉토리에 있습니다. 이제 work디렉토리 의 내용을 살펴 보겠습니다 . -d(directory) 옵션 대신  -a(all) 옵션을 사용합니다 . 일반적으로 숨겨져있는 디렉토리 항목이 표시됩니다.

다음을 입력합니다.

ls -lia 작업 /

-a(all) 옵션 을 사용했기 때문에 단일 (.) 및 이중 점 (..) 항목이 표시됩니다. 이러한 항목은 디렉토리 자체 (단일 점) 및 상위 디렉토리 (이중 점)를 나타냅니다.

단일 점 항목의 inode 번호를 살펴보면 1443016 work입니다. 이는 디렉토리 의 inode 번호를 발견했을 때 얻은 것과 동일한 inode 번호 입니다. 또한 이중 점 항목의 inode 번호는 home디렉토리 의 inode 번호와 동일합니다 .

이것이 바로 cd ..명령을 사용 하여 디렉토리 트리에서 한 단계 위로 이동할 수있는 이유 입니다. 마찬가지로 응용 프로그램 또는 스크립트 이름 앞에를 붙이면 응용 프로그램 또는 스크립트   ./를 시작할 위치를 셸에 알립니다.

Inode 및 링크

지금까지 살펴본 것처럼 파일 시스템에서 제대로 구성되고 액세스 가능한 파일을 가지려면 파일, 디렉터리 구조 및 inode의 세 가지 구성 요소가 필요합니다. 파일은 하드 드라이브에 저장된 데이터이며 디렉토리 구조에는 파일 이름과 해당 inode 번호가 포함되며 inode에는 파일에 대한 모든 메타 데이터가 포함됩니다.

심볼릭 링크는 파일처럼 보이는 파일 시스템 항목이지만 실제로는 기존 파일이나 디렉토리를 가리키는 바로 가기입니다. 그들이 이것을 어떻게 관리하는지, 그리고 이것을 달성하기 위해 세 가지 요소가 어떻게 사용되는지 봅시다.

두 개의 파일이있는 디렉토리가 있다고 가정 해 봅시다. 하나는 스크립트이고 다른 하나는 응용 프로그램입니다.

ln 명령과 -s(기호) 옵션을 사용하여 다음과 같이 스크립트 파일에 대한 소프트 링크를 만들 수 있습니다.

ls -s my_script geek.sh

my_script.sh라는 링크를 만들었습니다 geek.sh. 다음을 입력하고 사용  ls 하여 두 개의 스크립트 파일을 볼 수 있습니다.

ls -li * .sh

에 대한 항목 geek.sh 은 파란색 으로 표시됩니다. 권한 플래그의 첫 번째 문자는 링크의 "l"이며을  ->가리 킵니다 my_script.sh. 이 모든 geek.sh것이 링크 임을 나타냅니다 .

예상대로 두 스크립트 파일의 inode 번호가 다릅니다. 하지만 더 놀라운 점은 소프트 링크 인 geek.sh에는 원본 스크립트 파일과 동일한 사용자 권한이 없다는 것입니다. 실제로에 대한 권한  geek.sh은 훨씬 더 자유 롭습니다. 모든 사용자는 전체 권한을 갖습니다.

에 대한 디렉토리 구조 geek.sh에는 링크 이름과 해당 inode가 포함됩니다. 링크를 사용하려고하면 일반 파일과 마찬가지로 inode가 참조됩니다. 링크 inode는 디스크 블록을 가리 키지 만 파일 콘텐츠 데이터를 포함하는 대신 디스크 블록에는 원본 파일의 이름이 포함됩니다. 파일 시스템이 원본 파일로 리디렉션됩니다.

원본 파일을 삭제하고의 내용을보기 위해 다음을 입력하면 어떻게되는지 확인합니다  geek.sh.

rm my_script.sh

고양이 geek.sh

심볼릭 링크가 끊어지고 리디렉션이 실패합니다.

이제 다음을 입력하여 응용 프로그램 파일에 대한 하드 링크를 만듭니다.

특수 앱 괴짜 앱에서

이 두 파일의 inode를보기 위해 다음을 입력합니다.

ls -li

둘 다 일반 파일처럼 보입니다. 에 대한 내용 geek-app은 ls목록이 geek.sh그랬던 방식의 링크임을 나타냅니다 . 또한  geek-app 원본 파일과 동일한 사용자 권한을 갖습니다. 그러나 놀라운 것은 두 응용 프로그램이 동일한 inode 번호 인 1441797을 갖는다는 것입니다.

에 대한 디렉토리 항목은 geek-app"geek-app"이름과 inode 번호를 포함하지만 원본 파일의 inode 번호와 동일합니다. 따라서 동일한 inode를 가리키는 서로 다른 이름을 가진 두 개의 파일 시스템 항목이 있습니다. 실제로 여러 항목이 동일한 inode를 가리킬 수 있습니다.

다음을 입력하고 stat프로그램을 사용 하여 대상 파일을 살펴 보겠습니다.

통계 특수 앱

두 개의 하드 링크가이 파일을 가리키는 것을 볼 수 있습니다. 이것은 inode에 저장됩니다.

다음 예에서는 원본 파일을 삭제하고 보안 비밀 암호로 링크를 사용하려고합니다.

rm 특별 앱

./geek-app correcthorsebatterystaple

놀랍게도 애플리케이션은 예상대로 실행되지만 어떻게 실행됩니까? 파일을 삭제할 때 inode를 자유롭게 재사용 할 수 있기 때문에 작동합니다. 디렉토리 구조는 inode 번호가 0 인 것으로 표시되며 디스크 블록은 해당 공간에 저장 될 다른 파일에 사용할 수 있습니다.

그러나 inode에 대한 하드 링크 수가 1보다 크면 하드 링크 수가 1 씩 줄어들고 삭제 된 파일의 디렉토리 구조의 inode 번호가 0으로 설정됩니다. 하드 드라이브 및 inode의 파일 내용은 기존 하드 링크에서 계속 사용할 수 있습니다.

다음을 입력하고 stat를 한 번 더 사용하겠습니다. 이번에는 geek-app:

통계 괴짜 앱

이러한 세부 정보는 이전 stat명령 과 동일한 inode (1441797)에서 가져옵니다 . 링크 수가 1 개 감소했습니다.

이 inode에 대한 하나의 하드 링크로 내려 갔기 때문에을  geek-app삭제하면 파일이 실제로 삭제됩니다. 파일 시스템은 inode를 해제하고 디렉토리 구조를 0으로 표시합니다. 그러면 새 파일이 하드 드라이브의 데이터 저장소를 덮어 쓸 수 있습니다.

관련 : Linux에서 stat 명령을 사용하는 방법

Inode 오버 헤드

깔끔한 시스템이지만 오버 헤드가 있습니다. 파일을 읽으려면 파일 시스템이 다음을 모두 수행해야합니다.

• 올바른 디렉토리 구조 찾기
• inode 번호 읽기
• 올바른 inode 찾기
• inode 정보 읽기
• 관련 디스크 블록에 대한 inode 링크 또는 익스텐트를 따르십시오.
• 파일 데이터 읽기

데이터가 인접하지 않은 경우 조금 더 이동해야합니다.

ls 많은 파일의 긴 형식 파일 목록을 수행 하기 위해 수행 해야하는 작업을 상상해보십시오  . ls출력을 생성하는 데 필요한 정보를 얻기 위해 앞뒤로 많은 것이 있습니다.

물론 파일 시스템 액세스 속도를 높이는 것이 Linux가 가능한 한 많은 선점 형 파일 캐싱을 시도하는 이유입니다. 이는 큰 도움이되지만 때로는 모든 파일 시스템과 마찬가지로 오버 헤드가 분명해질 수 있습니다.

이제 그 이유를 알게 될 것입니다.