中央流通センターに異動するために、私は定期的に、主にサンクトペテルブルクとモスクワにあるさまざまな大企業で DevOps 職の面接を受けています。 多くの企業 (Yandex などの多くの優良企業) が XNUMX つの同様の質問をしていることに気付きました。
- i ノードとは何ですか。
- ディスク書き込みエラーが発生する理由は何ですか (または、たとえば、ディスク容量が不足する可能性があります。本質は同じです)。
よくあることですが、私はこのトピックについてよく知っていると思っていましたが、説明を始めるとすぐに知識のギャップが明らかになりました。 自分の知識を体系化し、ギャップを埋め、もう恥ずかしくないように、この記事を書いています。もしかしたら他の人の役に立つかもしれません。
つまり、下から始めます。 ハードドライブから（フラッシュドライブ、SSD、その他の最新のものは破棄します。たとえば、ブロックサイズが20バイトであるため、80ギガまたは512ギガの古いドライブを考えてみましょう）。
ハードドライブはそのスペースをバイトごとにアドレス指定する方法を認識せず、条件付きでブロックに分割されます。 ブロックの番号付けは 0 から始まります。(これは LBA と呼ばれます。詳細は次のとおりです。 )
図からわかるように、LBA ブロックを HDD レベルとして指定しました。 ちなみに、ディスクのブロックサイズは次のようにして確認できます。
root@ubuntu:/home/serp# blockdev --getpbsz /dev/sdb
512上のレベルはパーティションであり、ディスク全体に対応します (これも簡単にするため)。 ほとんどの場合、msdos と gpt の 2 種類のパーティション マークアップが使用されます。 したがって、msdos は最大 1Tb のディスクをサポートする古い形式であり、gpt は 512 バイト ブロックの最大 1 ゼタバイトをアドレス指定できる新しい形式です。 この例では、msdos タイプのパーティションがあり、図からわかるように、パーティションはブロック番号 XNUMX から始まり、MBR にはゼロが使用されます。
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 ファイルをどのように読み取るかということです。 ファイルは、データが保存される XNUMX つ以上のファイル システム ブロックで構成されます。 ファイル名はわかっているのですが、どうやって見つけますか? どのブロックを読めばよいでしょうか?
ここで i ノードが役に立ちます。 ext2fs ファイル システムには、すべての i ノードの情報を含む「テーブル」があります。 ext2fsの場合のinode数はファイルシステム作成時に設定します。 tune2fs 出力の「Inode count」パラメーターで必要な数値を調べます。 65536個あります。 i ノードには、必要な情報 (探しているファイルのファイル システム ブロックのリスト) が含まれています。 特定のファイルの i ノード番号を見つけるにはどうすればよいですか?
対応する名前と i ノード番号がディレクトリに含まれており、ext2fs 内のディレクトリは特殊なタイプのファイルです。 独自の i ノード番号もあります。 この悪循環を断ち切るために、「固定」の i ノード番号「2」がルート ディレクトリに割り当てられました。 i ノード 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 ファイル システムには「予約ブロック数」のようなものがあることを覚えておく必要があります。 上のリストを見ると、そのようなブロックが「XNUMX」あります。 これらは、root ユーザーのみが書き込み可能なブロックです。 ただし、問題をすぐに解決する必要がある場合は、一時的な解決策として、全員がそれらを利用できるようにして、空き領域を確保することができます。
root@ubuntu:/mnt# tune2fs -m 0 /dev/sdb1
tune2fs 1.42.9 (4-Feb-2014)
Setting reserved blocks percentage to 0% (0 blocks)それらの。 デフォルトでは、書き込みに利用できないディスク領域が 5% あり、最新のディスクの容量を考慮すると、これは数百 GB になる可能性があります。
他に何があるでしょうか？ 空きブロックはあるものの、ノードがもうないという可能性もあります。 これは通常、ファイル システム上にファイル システムのブロック サイズより小さいファイルが多数ある場合に発生します。 1 つの i ノードが 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 パーティションではっきりとわかるように、ファイル システム内の空きブロックの数と空きノードの数は大きく異なります。
i ノードが不足した場合に備えて、呪文は説明しません。なぜなら... 何もありません（間違っていたらお知らせください）。 したがって、小さなファイルが複数存在するパーティションの場合は、ファイル システムを賢明に選択する必要があります。 たとえば、btrfs i ノードは終了できません。 必要に応じて、新しいものが動的に作成されます。
出所： habr.com