아이노드에 관한 것

주기적으로 중앙유통센터로 이동하기 위해 상트페테르부르크와 모스크바를 중심으로 여러 대기업에서 DevOps 포지션으로 면접을 봅니다. 나는 많은 회사(Yandex와 같은 많은 좋은 회사)가 두 가지 유사한 질문을 하는 것을 발견했습니다.

• 아이노드가 무엇인가요?
• 어떤 이유로 디스크 쓰기 오류가 발생할 수 있습니까(예: 디스크 공간이 부족한 이유는 본질은 동일합니다).

흔히 그렇듯이 나는 이 주제를 잘 알고 있다고 확신했지만, 설명을 시작하자마자 지식의 격차가 드러났습니다. 내 지식을 체계화하고, 부족한 부분을 메우고, 더 이상 당황하지 않기 위해 이 글을 쓰고 있습니다. 아마도 다른 사람에게도 도움이 될 것입니다.

맨 아래부터 시작하겠습니다. 하드 드라이브에서(플래시 드라이브, SSD 및 기타 최신 장치는 폐기합니다. 예를 들어 블록 크기가 20바이트이므로 80GB 또는 512GB의 오래된 드라이브를 고려해 보겠습니다.)

하드 드라이브는 해당 공간을 바이트 단위로 주소 지정하는 방법을 모르며 조건에 따라 블록으로 나뉩니다. 블록 번호 지정은 0부터 시작합니다. (이를 LBA라고 합니다. 자세한 내용은 다음을 참조하세요. ru.wikipedia.org/wiki/LBA)

그림에서 볼 수 있듯이 LBA 블록을 HDD 레벨로 지정했습니다. 그런데 다음과 같이 디스크의 블록 크기를 확인할 수 있습니다.

root@ubuntu:/home/serp# blockdev --getpbsz /dev/sdb
512

위 수준은 전체 디스크에 대한 파티션입니다(간단함을 위해 다시 한 번 언급함). 대부분의 경우 msdos와 gpt라는 두 가지 유형의 파티션 마크업이 사용됩니다. 따라서 msdos는 최대 2Tb의 디스크를 지원하는 기존 형식이고, gpt는 1바이트 블록 중 최대 512제타바이트까지 주소를 지정할 수 있는 새로운 형식입니다. 우리의 경우 그림에서 볼 수 있듯이 msdos 유형의 파티션이 있습니다. 파티션은 블록 번호 1로 시작하고 MBR에는 XNUMX이 사용됩니다.

첫 번째 파티션에서 ext2 파일 시스템을 생성했는데 기본 블록 크기는 4096바이트이며 이는 그림에도 반영되어 있습니다. 다음과 같이 파일 시스템 블록 크기를 볼 수 있습니다.

root@ubuntu:/home/serp# tune2fs -l /dev/sdb1
tune2fs 1.42.9 (4-Feb-2014)
Filesystem volume name:   <none>
Last mounted on:          <not available>
Filesystem UUID:          a600bf40-f660-41f6-a3e6-96c303995479
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      ext_attr resize_inode dir_index filetype sparse_super large_file
Filesystem flags:         signed_directory_hash
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              65536
Block count:              261888
Reserved block count:     13094
Free blocks:              257445
Free inodes:              65525
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      63
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Filesystem created:       Fri Aug  2 15:02:13 2019
Last mount time:          n/a
Last write time:          Fri Aug  2 15:02:14 2019
Mount count:              0
Maximum mount count:      -1
Last checked:             Fri Aug  2 15:02:13 2019
Check interval:           0 (<none>)
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Required extra isize:     28
Desired extra isize:      28
Default directory hash:   half_md4
Directory Hash Seed:      c0155456-ad7d-421f-afd1-c898746ccd76

필요한 매개변수는 "블록 크기"입니다.

이제 흥미로운 부분은 /home/serp/testfile 파일을 읽는 방법입니다. 파일은 데이터가 저장되는 하나 이상의 파일 시스템 블록으로 구성됩니다. 파일 이름을 알면 어떻게 찾을 수 있나요? 어떤 블록을 읽어야 하나요?

이것은 inode가 유용한 곳입니다. ext2fs 파일 시스템에는 모든 inode에 대한 정보가 포함된 "테이블"이 있습니다. ext2fs의 경우 inode 수는 파일 시스템 생성 시 설정됩니다. tune2fs 출력의 "Inode count" 매개변수에서 필요한 숫자를 살펴봅니다. 즉, 65536개의 조각이 있습니다. inode에는 우리가 찾고 있는 파일에 대한 파일 시스템 블록 목록과 같은 필요한 정보가 포함되어 있습니다. 특정 파일의 inode 번호를 찾는 방법은 무엇입니까?

해당 이름과 inode 번호는 디렉토리에 포함되어 있으며 ext2fs의 디렉토리는 특별한 유형의 파일입니다. 또한 자체 inode 번호도 있습니다. 이 악순환을 깨기 위해 "고정된" inode 번호 "2"가 루트 디렉터리에 할당되었습니다. inode 번호 2의 내용을 살펴보겠습니다.

root@ubuntu:/# debugfs /dev/sdb1
debugfs 1.42.9 (4-Feb-2014)
debugfs:  stat <2>

Inode: 2   Type: directory    Mode:  0755   Flags: 0x0
Generation: 0    Version: 0x00000000:00000002
User:     0   Group:     0   Size: 4096
File ACL: 0    Directory ACL: 0
Links: 3   Blockcount: 8
Fragment:  Address: 0    Number: 0    Size: 0
 ctime: 0x5d43cb51:16b61bcc -- Fri Aug  2 16:34:09 2019
 atime: 0x5d43c247:b704301c -- Fri Aug  2 15:55:35 2019
 mtime: 0x5d43cb51:16b61bcc -- Fri Aug  2 16:34:09 2019
crtime: 0x5d43b5c6:00000000 -- Fri Aug  2 15:02:14 2019
Size of extra inode fields: 28
BLOCKS:
(0):579
TOTAL: 1

보시다시피, 필요한 디렉토리는 블록 번호 579에 포함되어 있습니다. 여기서는 홈 폴더의 노드 번호를 찾고 serp 디렉토리에서 요청된 파일의 노드 번호를 볼 때까지 체인을 따라갑니다. 갑자기 누군가가 번호가 맞는지, 필요한 정보가 있는지 확인하고 싶다면 어렵지 않습니다. 우리는하다:

root@ubuntu:/# dd if=/dev/sdb1 of=/home/serp/dd_image bs=4096 count=1 skip=579
1+0 records in
1+0 records out
4096 bytes (4,1 kB) copied, 0,000184088 s, 22,3 MB/s
root@ubuntu:/# hexdump -c /home/serp/dd_image

출력에서 디렉터리에 있는 파일 이름을 읽을 수 있습니다.

그래서 저는 "어떤 이유로 녹음 오류가 발생할 수 있습니까?"라는 주요 질문에 도달했습니다.

당연히 파일 시스템에 여유 블록이 남아 있지 않으면 이런 일이 발생합니다. 이 경우 무엇을 할 수 있습니까? 명백한 "불필요한 것을 제거"하는 것 외에도 ext2,3, 4 파일 시스템에는 "예약된 블록 수"와 같은 것이 있다는 것을 기억해야 합니다. 위 목록을 보면 해당 블록이 "13094"개 있습니다. 루트 사용자만 쓸 수 있는 블록입니다. 하지만 문제를 신속하게 해결해야 하는 경우 임시 솔루션으로 모든 사람이 사용할 수 있도록 하여 여유 공간을 확보할 수 있습니다.

root@ubuntu:/mnt# tune2fs -m 0 /dev/sdb1
tune2fs 1.42.9 (4-Feb-2014)
Setting reserved blocks percentage to 0% (0 blocks)

저것들. 기본적으로 쓰기에 사용할 수 없는 디스크 공간은 5%이며, 최신 디스크 볼륨을 고려하면 이는 수백 기가바이트에 이를 수 있습니다.

또 무엇이 있을까요? 사용 가능한 블록이 있지만 더 이상 노드가 없을 수도 있습니다. 이는 일반적으로 파일 시스템 블록 크기보다 작은 파일 묶음이 파일 시스템에 있는 경우에 발생합니다. 1개의 inode가 1개의 파일 또는 디렉토리에 소비되고 총계(주어진 파일 시스템에 대해) 65536이 있다는 점을 고려하면 상황은 현실적 이상입니다. 이는 df 명령의 출력에서 ​​명확하게 볼 수 있습니다.

serp@ubuntu:~$ df -hi
Filesystem     Inodes IUsed IFree IUse% Mounted on
udev             493K   480  492K    1% /dev
tmpfs            493K   425  493K    1% /run
/dev/xvda1       512K  240K  273K   47% /
none             493K     2  493K    1% /sys/fs/cgroup
none             493K     2  493K    1% /run/lock
none             493K     1  493K    1% /run/shm
none             493K     2  493K    1% /run/user
/dev/xvdc1       320K  4,1K  316K    2% /var
/dev/xvdb1        64K   195   64K    1% /home
/dev/xvdh1       4,0M  3,1M  940K   78% /var/www
serp@ubuntu:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            2,0G  4,0K  2,0G   1% /dev
tmpfs           395M  620K  394M   1% /run
/dev/xvda1      7,8G  2,9G  4,6G  39% /
none            4,0K     0  4,0K   0% /sys/fs/cgroup
none            5,0M     0  5,0M   0% /run/lock
none            2,0G     0  2,0G   0% /run/shm
none            100M     0  100M   0% /run/user
/dev/xvdc1      4,8G  2,6G  2,0G  57% /var
/dev/xvdb1      990M  4,0M  919M   1% /home
/dev/xvdh1       63G   35G   25G  59% /var/www

/var/www 파티션에서 명확하게 볼 수 있듯이 파일 시스템의 사용 가능한 블록 수와 사용 가능한 노드 수는 크게 다릅니다.

아이노드가 부족할 경우에는 어떤 주문도 알려주지 않을 것입니다. 왜냐하면... (내가 틀렸다면 알려주세요). 따라서 작은 파일이 많아지는 파티션의 경우 파일 시스템을 현명하게 선택해야 합니다. 예를 들어, btrfs inode는 종료될 수 없습니다. 필요한 경우 새 항목이 동적으로 생성됩니다.

출처 : habr.com