tune2fs -l /dev/sda on my production server today and got the following output:
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
What stood out to me was this line:
First orphan inode: 17301533
I've always understood orphan inodes to mean inodes that are left over after a crash. However the file system in question has always been cleanly unmounted and the system is on a UPS and has never shutdown uncleanly.
Is there a reason why there are orphaned inodes and does it indicate a problem?