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}다른 셸에서 실행합니다. 파일 시스템은 프로세스가 종료될 때 지울 수 있도록 이를 추적합니다.