tune2fs -l /dev/sda本日、本番サーバーでこれを実行し、次の結果を得ました。
tune2fs 1.42.9 (4-Feb-2014)
Filesystem volume name: <none>
Last mounted on: /
Filesystem UUID: a5b1c696-aa59-43db-a252-88b2e6d8212c
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: signed_directory_hash
Default mount options: journal_data user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 60923904
Block count: 243670272
Reserved block count: 12183513
Free blocks: 223441953
Free inodes: 60799595
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 965
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
Flex block group size: 16
Filesystem created: Fri May 9 19:48:11 2014
Last mount time: Fri Jun 6 20:17:28 2014
Last write time: Fri Jun 6 20:17:01 2014
Mount count: 1
Maximum mount count: -1
Last checked: Fri Jun 6 20:17:01 2014
Check interval: 0 (<none>)
Lifetime writes: 194 GB
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
Journal inode: 8
First orphan inode: 17301533
Default directory hash: half_md4
Directory Hash Seed: 1fbb5b3a-79fe-42b3-b69d-0f8073618d27
Journal backup: inode blocks
私の目立つのはこの文章です。
First orphan inode: 17301533
私は常に孤立したinodeをクラッシュした後に残されたinodeとして理解しました。しかし、問題のファイルシステムは常にきれいにマウント解除されており、システムはUPSにあり、不純に終了したことはありません。
孤児のinodeが存在する理由はありますか？これは問題を示していますか？
答え1
孤立したinodeは、接続が解除されたが他のプロセスでまだ開いているinodeです。たとえば、tail -f {file}あるシェルで実行し、rm {file}別のシェルで実行します。ファイルシステムは、プロセスが終了したときにクリアできるようにそれを追跡します。