LinuxQuestions.org
Download your favorite Linux distribution at LQ ISO.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie
User Name
Password
Linux - Newbie This Linux forum is for members that are new to Linux.
Just starting out and have a question? If it is not in the man pages or the how-to's this is the place!

Notices


Reply
  Search this Thread
Old 06-28-2016, 05:24 PM   #16
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,654

Rep: Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255

Quote:
Originally Posted by rknichols View Post
Inodes that appear in the orphan inode list are those that were deliberately disconnected from the directory tree while the inode was still in use. Inodes that get lost because the directory entry that should point to them is missing are a different matter. Those get put in lost+found by fsck. A problem with the orphan inode list is a much simpler matter, and one recommendation for fixing that is simply to mount the filesystem, since the orphan inode list is automtically cleared when the filesystem is mounted.
Not always.

They can be inodes allocated, with data recorded, but not all the metadata gets updated. This happens if the directory buffer in memory contains the name... but that buffer has not yet been written to disk.

If a crash occurs, the inode is orphaned.

It can also happen if a directory gets corrupted and cannot be fully read... The entries that cannot be read are also orphaned.

As I said earlier, this tends NOT to happen on ext3/4 or btrfs due to the filesystem journal. But with these filesystems you won't find an orphan in the first place.

The "automtically cleared when the filesystem is mounted" only occurs with journaling filesystems where the journal is used replay any outstanding transactions - and you won't see the "filesystem requires fsck" message at all.

Last edited by jpollard; 06-28-2016 at 05:26 PM.
 
Old 06-28-2016, 06:33 PM   #17
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 3,118

Rep: Reputation: 1339Reputation: 1339Reputation: 1339Reputation: 1339Reputation: 1339Reputation: 1339Reputation: 1339Reputation: 1339Reputation: 1339Reputation: 1339
Quote:
Originally Posted by jpollard View Post
If a crash occurs, the inode is orphaned.
Is an orphan, yes. Gets linked into the list of orphan inodes, no. The list of orphaned inodes is a singly-linked list beginning with the inode identified by the s_last_orphan field in the super block. The i_dtime field is overloaded to point to the next inode in the list. An inode that becomes orphaned because of a crash is not going to get linked into that list.

Note that in the current case fsck did not complain about any unattached inodes.
 
Old 06-28-2016, 08:49 PM   #18
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,654

Rep: Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255
Quote:
Originally Posted by rknichols View Post
Is an orphan, yes. Gets linked into the list of orphan inodes, no. The list of orphaned inodes is a singly-linked list beginning with the inode identified by the s_last_orphan field in the super block. The i_dtime field is overloaded to point to the next inode in the list. An inode that becomes orphaned because of a crash is not going to get linked into that list.

Note that in the current case fsck did not complain about any unattached inodes.
True. But those you indicate are not really orphaned - they are in the process to be deleted.

The actual report in the current case is "UNEXPECTED INCONSISTENCY". This is strictly determined by the state of the superblock. There may or may not be orphaned inodes in the filesystem. If there are, they will be found by the fsck run and USUALLY get put in the lost+found directory. Usually, I just find that the free block list has become damaged due to power failures. The ext4 journal usually covers those without a problem, but really dirty power failures...
 
Old 06-28-2016, 11:11 PM   #19
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 3,118

Rep: Reputation: 1339Reputation: 1339Reputation: 1339Reputation: 1339Reputation: 1339Reputation: 1339Reputation: 1339Reputation: 1339Reputation: 1339Reputation: 1339
Quote:
Originally Posted by jpollard View Post
True. But those you indicate are not really orphaned - they are in the process to be deleted.
I'm not sure what you refer to by "those." The linked list under discussion is called the "orphaned inode list". There is just one way an inode gets added to that list, and that is when the last directory link to an open file is deleted.

Quote:
The actual report in the current case is "UNEXPECTED INCONSISTENCY". This is strictly determined by the state of the superblock.
Not true. That message comes from fsck.ext{2/3/4} during the course of examining the whole filesystem if it was invoked with the "-p" ("preen") option to automatically repair minor problems and runs across something beyond what that option was intended to correct. From the super block, it just gets the "needs_recovery" flag that indicates the filesystem was not unmounted cleanly.

Quote:
There may or may not be orphaned inodes in the filesystem. If there are, they will be found by the fsck run and USUALLY get put in the lost+found directory. Usually, I just find that the free block list has become damaged due to power failures. The ext4 journal usually covers those without a problem, but really dirty power failures...
That's using the term "orphaned" too generally. The more general term is "unlinked inodes", i.e., non-free inodes that have no link from any directory. "Orphaned inodes" are a subset of that category. Orphaned inodes occur when a process unlinks an inode while it is still open, and those inodes are linked into the orphaned inode list. The other type of unlinked inode happens when an error or crash leaves a non-free inode with no directory link. The two types are handled differently by fsck. Inodes in the orphaned inode list are known to be for temporary files that were intended to be deleted when the process using them terminated, normally or otherwise. Those inodes can safely be cleaned up and any data blocks allocated to them can be released. Unlinked inodes that are not in the orphaned inode list should not be so cavalierly discarded, and those get linked into the lost+found directory.

The situation is a little murkier when the orphaned inode list itself is corrupted. All I have to go on here are the messages from fsck indicating the the problem was "fixed" and no indication that anything was linked to lost+found. The inode might have been simply freed. I don't know what criteria might have served as the basis for that decision.
 
Old 06-29-2016, 06:40 AM   #20
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,654

Rep: Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255
As I understood it "repair minor problems" was to free the orphaned inode list and replay the journal.

In which case, the filesystem is now clean and is mounted - without the warning.

I grant that I use "orphan inodes" from the original definition (meaning any inode not in a directory and not marked free). Even the documentation on the orphan inode list indicates that it is moving to a "file" usage (one block per CPU) though I can't tell if it has been implemented (https://ext4.wiki.kernel.org/index.p...he_Super_Block). The inodes in the "orphan list" are deliberate, and not due to filesystem corruption as the filesystem is consistent just needing the list released and journal replayed which would happen during a mount anyway.
 
Old 06-29-2016, 12:33 PM   #21
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 3,118

Rep: Reputation: 1339Reputation: 1339Reputation: 1339Reputation: 1339Reputation: 1339Reputation: 1339Reputation: 1339Reputation: 1339Reputation: 1339Reputation: 1339
Quote:
Originally Posted by jpollard View Post
As I understood it "repair minor problems" was to free the orphaned inode list and replay the journal.
I just realized that it's been so long since I've seen "preen" have anything left to clean up after the journal replay that I can hardly remember all the stuff that it used to fix. I'm pretty sure that "returning unclaimed blocks to the free pool" was one of them. That says a lot about the power of the journal and the general reliability of systems these days.
 
Old 06-30-2016, 07:13 AM   #22
jpollard
Senior Member
 
Registered: Dec 2012
Location: Washington DC area
Distribution: Fedora, CentOS, Slackware
Posts: 4,654

Rep: Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255Reputation: 1255
I have seen some LKML messages (somewhere in there anyway - can't find it right now) from the developer of ext4 that there is no need for an fsck pass before mounting - only if the mount fails. The journal is SUPPOSED to catch all metadata updates (including those of the free inode list), and the filesystem code will process the journal and fix everything. fsck itself doesn't carry out a full fsck check anyway (on a 9TB filesystem it takes nearly a whole day) - you have to force it to do that (the -f option to e2fsck).

The only times I've needed fsck (since ext3) has been when something happened from OUTSIDE of the filesystem - such as using dd and writing to the wrong device... I do this when testing raid5 support. btrfs? failed. mdraid - no problem and recovery worked right off just by degrading the drive, and adding it back. I will have to test again after going to Fedora 24 as btrfs raid5 SHOULD recover this automatically (the btrfs checksum tests should have identified the bad data - but didn't in my test).
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] /dev/sda3: unexpected inconsistency; execute fsck manually. vienswuer Linux - Newbie 11 05-16-2014 02:02 PM
"unexpected inconsistency" (fsck) of the root file system failed artoebe Linux - Newbie 8 03-23-2013 12:40 AM
/dev/VolGroup01/u04: UNEXPECTED INCONSISTENCY Run fsck Manually juan_f_vidal Linux - General 4 06-09-2011 12:31 PM
Unexpected inconsistency, run fsck manually twangchuk Linux - Newbie 2 06-12-2009 10:51 AM
Error in partition. Unexpected Inconsistency, won't let me run fsck! mlsbraves Slackware 2 04-15-2005 10:03 PM


All times are GMT -5. The time now is 12:13 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration