In linux file system, when file system error happens, the first choice is to do an fsck of the unmounted file system.
Usually,
fsck -y /dev/sdxx
at boot time should be able to fix everything, if the FS has not been severely damaged.
Occasionally, as reported as
Debian bug list #478546 at
http://groups.google.com/group/linux.debian.bugs.dist/browse_thread/thread/dc48335d2ca42b66
fsck returns error like:
fsck 1.40.8 (13-Mar-2008)
e2fsck 1.40.8 (13-Mar-2008)
Backup contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
'..' in /lost+found/#122068977 (122068977) is <The NULL inode> (0),
should be /lost+found (11).
Fix? yes
Couldn't fix parent of inode 122068977: Couldn't find parent directory entry
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Backup: ********** WARNING: Filesystem still has errors **********
Backup: 14398872/122077184 files (1.4% non-contiguous),
188901088/244137600 blocks
And, what ever you repeat fsck, or use e2fsprogs won’t help about this.
Here I explain the cause of this and prresent a solution as following:
[REASON]
In the messed up FS, an orphaned inode with ZERO data length was labelled as a directory, and was restored into lost+found/ on the alleged file system.
However, for a valid directory entry, it cannot be ZERO length. It has to have at least two entries namely ‘.’ linking to itself and ‘..’ linking to its parent directory. However, since this directory entry has zero length, fsck failed creating ‘..’ thus resulted the error
“Couldn't fix parent of inode 122068977: Couldn't find parent directory entry"
and resulted a fail of the fsck.
[SOLUTION]
When fsck is done, mount the FS. Then cd the lost+found/ directory:
mount #<your mount point>
cd #<your mount point>
cd lost+found
If you do ‘ls -al’, you will see a directory with zero length named #<the affected inode>, like here #122068977.
It usually has a weird owner and group number.
You then do the following:
chown root:root #<the affected inode>
chmod 755 #<the affected inode>
This will make it look normal.
Then
cd #<the affected inode>
touch test
rm test
cd #<your mount point>
Note you cannot do
cd ..
still here since ‘..’ does not exist yet.
Then if you do
ls -al
again, the length of the directory #<the affected inode> is no longer 0, but the default minimum length of your file system, say 4096, 8192, or 16384, etc.
At this point, you can cd off the mounted filesystem, and umount it:
cd ~
umount #<your mount point>
and fsck it:
fsck -y /dev/<your device>
It then will result:
fsck 1.40.2 (12-Jul-2007)
e2fsck 1.40.2 (12-Jul-2007)
<your FS> was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Missing '.' in directory inode <bad inode number>.
Fix? yes
Setting filetype for entry '.' in ... (<bad inode number>) to 2.
Missing '..' in directory inode <bad inode number>.
Fix? yes
Setting filetype for entry '..' in ... (<bad inode number>) to 2.
Pass 3: Checking directory connectivity
'..' in /lost+found/<bad inode number> (<bad inode number>) is
(0), should be /lost+found (11).
Fix? yes
Pass 4: Checking reference counts
Inode 2 ref count is 6, should be 7. Fix? yes
Inode 11 ref count is 4, should be 3. Fix? yes
Inode <bad inode number> ref count is 1, should be 2. Fix? yes
Pass 5: Checking group summary information
<your FS>: ***** FILE SYSTEM WAS MODIFIED *****
<your FS>: 1882918/91193344 files (0.3% non-contiguous), 111803861/182339584 blocks
This will save you from the risk of running a FS with errors or fully copy the file system elsewhere to recreate it.