1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Question about e2fsck errors

Discussion in 'Cisco/Linksys Network Storage Devices' started by jackito, Jan 24, 2010.

  1. jackito

    jackito LI Guru Member

    Any expert on e2fsck out there?
    Yesterday there was a power outage at home. The NAS200 of course was uncleanly shutdown.
    After starting it again I had a problem reading two files so I decided to go into "maintenance mode" (UFS200 feature) to run e2fsck on my data partition.
    e2fsck found some errors while examining the volume. Since I know almost nothing about FS errors and e2fsck messages I just keep answering yes to all the questions about fixing something.
    Can anybody explain me what was fixed and if apart of these two files something else could be lost? :frown:

    Code:
    root@NAS200 /root# e2fsck -v -f /dev/md0
    e2fsck 1.40.2 (12-Jul-2007)
    Pass 1: Checking inodes, blocks, and sizes
    Inode 44777574 has illegal block(s).  Clear<y>? yes
    
    Illegal block #12 (1633099877) in inode 44777574.  CLEARED.
    Illegal block #13 (1852402540) in inode 44777574.  CLEARED.
    Illegal block #14 (539697191) in inode 44777574.  CLEARED.
    Illegal block #15 (1701998165) in inode 44777574.  CLEARED.
    Illegal block #16 (1935762796) in inode 44777574.  CLEARED.
    Illegal block #17 (774792293) in inode 44777574.  CLEARED.
    Illegal block #18 (1986610702) in inode 44777574.  CLEARED.
    Illegal block #19 (1631789157) in inode 44777574.  CLEARED.
    Illegal block #20 (1394631794) in inode 44777574.  CLEARED.
    Illegal block #22 (1208551365) in inode 44777574.  CLEARED.
    Illegal block #23 (543453793) in inode 44777574.  CLEARED.
    Too many illegal blocks in inode 44777574.
    Clear inode<y>? yes
    
    Inode 44777573 has illegal block(s).  Clear<y>? yes
    
    Illegal block #13 (1717916180) in inode 44777573.  CLEARED.
    Illegal block #14 (1952671084) in inode 44777573.  CLEARED.
    Illegal block #15 (1936617321) in inode 44777573.  CLEARED.
    Illegal block #16 (543575840) in inode 44777573.  CLEARED.
    Illegal block #17 (1869440338) in inode 44777573.  CLEARED.
    Illegal block #20 (1717916172) in inode 44777573.  CLEARED.
    Illegal block #21 (1701276018) in inode 44777573.  CLEARED.
    Illegal block #22 (1868849522) in inode 44777573.  CLEARED.
    Illegal block #24 (314107410) in inode 44777573.  CLEARED.
    Illegal block #25 (268524789) in inode 44777573.  CLEARED.
    Illegal block #26 (1919313234) in inode 44777573.  CLEARED.
    Too many illegal blocks in inode 44777573.
    Clear inode<y>? yes
    
    Restarting e2fsck from the beginning...
    Pass 1: Checking inodes, blocks, and sizes
    Pass 2: Checking directory structure
    Entry 'music.MYI' in /mysql/radiojack (44777567) has deleted/unused inode 44777573.  Clear<y>? yes
    
    Entry 'music.MYD' in /mysql/radiojack (44777567) has deleted/unused inode 44777574.  Clear<y>? yes
    
    Pass 3: Checking directory connectivity
    Pass 3A: Optimizing directories
    Pass 4: Checking reference counts
    Pass 5: Checking group summary information
    Block bitmap differences:  -(89593068--89594006)y
     -89594008
    Fix<y>? yes
    
    Free blocks count wrong for group #2733 (4, counted=0).
    Fix<y>? yes
    
    Free blocks count wrong for group #2734 (11600, counted=12549).
    Fix<y>? yes
    
    Free blocks count wrong for group #2752 (9690, counted=9671).
    Fix<y>? yes
    
    Free blocks count wrong (60060884, counted=60061810).
    Fix<y>? yes
    
    Inode bitmap differences:  -(44777573--44777574)
    Fix<y>? yes
    
    Free inodes count wrong for group #2733 (16298, counted=16300).
    Fix<y>? yes
    
    Free inodes count wrong (78032196, counted=78032198).
    Fix<y>? yes
    
    
    /dev/md0: ***** FILE SYSTEM WAS MODIFIED *****
    
       70330 inodes used (0.09%)
        6186 non-contiguous inodes (8.8%)
             # of inodes with ind/dind/tind blocks: 38427/13987/5
    96130126 blocks used (61.55%)
           0 bad blocks
          17 large files
    
       66556 regular files
        3057 directories
          42 character device files
         103 block device files
           0 fifos
           0 links
         558 symbolic links (558 fast symbolic links)
           5 sockets
    --------
       70321 files
    
    root@NAS200 /root# 
    
    Thanks,

    Jackito

    PS: I already search google to find some documentation on e2fsck messages and so on, without success. :frown:
     
  2. jackito

    jackito LI Guru Member

    Finally I decided to go with ext3 for the data and conf partitions.
    The conversion was fast and simple.
    The only problem is that the NAS200 keeps mounting them as ext2 on boot, but I solve this unmounting and mounting them again just after they get mounted during boot.
    It´s not ideal, but hey, it´s a lot better than keep running them in ext2.

    Anyway if somebody can answer my question about e2fsck errors I´ll be glad. :)
    Thanks,

    Jackito
     
  3. morgan_greywolf

    morgan_greywolf Addicted to LI Member

    The e2fsck errors look like your filesystem got corrupted somehow. This probably didn't have anything to do with mounting them as ext2, which generally isn't a problem until you write to it (since the journal won't get updated). but is a result of the power being interrupted. Check to make sure you don't have any lossage.

    The ext2/ext3 problem can be solved by making sure the ext3.ko module is loaded at boottime before the drives are mounted. (Maybe early.sh can do this for you?)
     
  4. jackito

    jackito LI Guru Member

    It was ext2 at the time of corruption. And the corruption was indeed caused by an unclean shutdown after a power outage.
    I still would like to know what the messages like "Block bitmap differences", "Free blocks count wrong for group" mean and so on.
    After fixing the fs problems I converted both, data and conf partition, to ext3 by adding the journal.

    No need, ext3 is compiled in the kernel itself is not a module.
    The problem is that the firmware is mounting the the partitions as ext2 by default. So I need to umount them and mount them again as ext3 right after the firmware is doing it.
     
  5. jac_goudsmit

    jac_goudsmit Super Moderator Staff Member Member

    The output from programs such as e2fsck (but also chkdsk in Windows) is really meant for engineers that understand many details about the file system that's under test. Usually it's not important to know exactly what's wrong, as long as you know what got fixed and how (for example if a file got deleted, you will want to know that so you can restore it from your backup).

    I'm somewhat familiar with the internals of the FAT file system but not much with Linux file systems. I do know that each file has an inode which I think is basically like a cluster of blocks and (if necessary) more inodes, and in your case, judging from the fact that those inodes contained a long list of bad blocks, it looks like the file system had just created the inodes to write to the files, but the inodes were uninitialized when the power outage occurred.

    If you want to find out more about file system design, I can recommend an interesting online book written by one of my ex-colleagues at Be, Inc.: Practical File System Design by Dominic Giampaolo. It's focused on the Be file system and therefore somewhat irrelevant now, but that's why the book is out of print and that's why he offers it online as a free download. It starts with a bit of history about the BeOS operating system which is an interesting read all by itself, followed by a general discussion which is valid for most filesystems on Unix-like operating systems. You can stop reading after paragraph 3.2 (which is about ext2) unless you're interested in creating your own file system...

    ===Jac
     
  6. jackito

    jackito LI Guru Member

    Thanks a lot for the info jac, I will keep investigating it.

    Jackito
     
  7. morgan_greywolf

    morgan_greywolf Addicted to LI Member

    jackito -- what does your /etc/fstab file look like? The only reason the Linux kernel would be mounting your HDD as ext2 is if you failed to specify ext3 in fstab. (Unless the firmware is doing something weird)
     
  8. jackito

    jackito LI Guru Member

    Forget it, the firmware (in fact rc.bootbin) is actually forcing the mount to ext2.
    As a workaround I modified the startup script to remount the partitions as ext3 right after rc.bootbin is executed. So far, so good.

    Jackito
     

Share This Page