Unknown Files

Files with no inode, no owner and no group.

 Some of files in one of partition formatted with ext3 was showing ? in place of inode, owner and group position. Any Ideas why ? After doing a lot of research it can be said that it was as stated below

root# cd /tmp/vikas
root# ls -li
? ? ? ? ? abc.txt

I become confused. find command also report a number of files which has no owner
root# find /tmp/vikas -nouser

Investing through problem result in conclusion that there is file system error in that partition. I advised apply fsck  command immediately. Applying fsck solved the problem but i am searching in what condition file exist without inode number.

root# fsck -y /dev/vg1/lv1

I also ensured that that file system get applied fsck on  reboot

root# shutdown -Fr now
                                       One interesting point i learned in between is that maximum 16 consequent times a file system can get mounted without applying fsck after that a warning come to fsck although this setting can be override with tune2fs command.

  The best option to reduce file system error is to apply fsck at booting time. This can be easily done by making entry in /etc/fstab for example in my case the entry is

/dev/vg1/lv1  /data  ext3  defaults   1   2

Here 1 says apply fsck and 2 says after applying fsck on root.

FSCK AND SUPER-BLOCK

SUPER-BLOCK Recovery and FSCK Stages:

 

As we know fsck  is a great command to check and repair error on file system. Many times i found  filesystem in panic and fsck make it operation-able.  I used fsck many times but every time i ensured that filesystem on which i applying fsck be in unmount state.
But  the most important thing i was interested is fsck stages. Whenever i issued fsck command it output as

   Phase 1: Checking Inodes,blocks and sizes
   Phase 2: Checking directory structure
   Phase 3: Checking directory connectivity
   Phase 4: Checking Reference count
   Phase 5: Checking group summary information

fsck checks the integrity of several different features of the file system. Most important checking that fsck do is of super block. As we know super block is most important aspect of file system which stores summary information for the volume. super block is also most modified item in file system so chances of corruption of super block is always high.
Checks on the superblock include:

• A check of the file system size, which obviously must be greater than the size computed from the number of blocks identified in the superblock
  
• The total number of inodes, which must be less than the maximum number of inodes
  
• A tally of reported free blocks and inodes

On number of occasion I found super block of my file system get corruption. Although its a very difficult for me to dictates reasons of super block corruption. But the better part is that a backup super block is always present in our file system. To know that where is alternate super block we can use dumpe2fs command as follwing

    root# dumpe2fs /dev/sda1|more

Generally block number 32768 is backup super block, so to recover filesystem using backup super block fsck command can be used in following ways

 root# fsck -b 32768 /dev/sda1

 Other than super block corruption other error can be easily fixed by using  fsck in straight ways as following

 root# fsck -y /dev/sda1 (Here -y option save us from pressing y while asking for yes during recovery )

When inodes are examined by fsck, the process is sequential in nature and aims to identify inconsistencies in format and type, link count, duplicate blocks, bad block numbers, and inode size. Inodes should always be in one of three states: allocated (being used by a file), unallocated (not being used by a file), and partially allocated, meaning that during an allocation or unallocation procedure, data has been left behind that should have been deleted or completed.

 Alternatively, partial allocation could result from a physical hardware failure. In both of these cases, fsck will attempt to clear the inode. The link count is the number of directory entries that are linked to a particular inode. fsck always checks that the number of directory entries listed is correct, by examining the entire directory structure beginning with the root directory, and tallying the number of links for every inode. Clearly, the stored link count and the actual link count should agree, but the stored link count can occasionally be different than the actual link count.

This could result from a disk not being synchronized before a shutdown, for example, and while changes to the file system have been saved, the link count has not been correctly updated. If the stored count is not zero, but the actual count is zero, then disconnected files are placed in the lost+found directory found in the top level of the file system concerned. In other cases, the actual count replaces the stored count.