2

I ran 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?

3

An orphaned inode is one that has been unlinked but is still open in another process. For example running tail -f {file} in one shell followed by rm {file} in another. The filesystem keeps track of these so they can be cleaned up when the process quits.

See this note on Ext4 Disk Layout.

  • Thanks. Out of interest, is there a way to see which processes are holding on to these orphaned inodes? – Tim Jan 5 '15 at 22:07
  • 1
    Output of lsof will show the file as /path/to/file (deleted) – Robert Calhoun Jan 5 '15 at 22:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.