thr3ads.net - Ext3 users - Re: Strange fsck.ext3 behavior

If this information is useful, please help other people find it:
Share via:

Richards, Paul Franklin

2013-Aug-30 01:48 UTC

Strange fsck.ext3 behavior - infinite loop

Greetings! Need your help fellow penguins!

Strange behavior with fsck.ext3: how to remove a long orphaned inode list?

After copying data over from one old RAID to another new RAID with rsync, the
dump command would not complete because of filesystem errors on the new RAID. So
I ran fsck.ext3 with the -y option and it would just run in an infinite loop
restarting itself and then trying to correct the same inodes over and over
again. Some of the errors were lots of orphaned inodes. So I ran a tar tape
backup and reformatted it with mkfs.ext3. After restoring the tar backup, I got
the same errors when I ran fsck.ext3 -f. Again fsck.ext3 -y would run in an
infinite loop trying to correct the problem. So I formatted it again and ran
fsck immediately afterwards and it's still detecting corrupted orphaned
inode lists. This is on what should be a pristine filesystem with basically no
files. Is this a hardware problem with the RAID or a bug somewhere or just
normal behavior?

[root@myhost /]# mkfs.ext3 /dev/sda1
mke2fs 1.35 (28-Feb-2004)
Filesystem labelOS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
268435456 inodes, 536868352 blocks
26843417 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
16384 block groups
32768 blocks per group, 32768 fragments per group
16384 inodes per group
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
        4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
        102400000, 214990848, 512000000

Writing inode tables: done
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 24 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.
[root@myhost /]# fsck
fsck         fsck.cramfs  fsck.ext2    fsck.ext3    fsck.msdos   fsck.vfat
[root@myhost /]# man fsck.ext3
[root@myhost /]# fsck.ext3 -C /root/completion /dev/sda1
e2fsck 1.35 (28-Feb-2004)
/dev/sda1: clean, 11/268435456 files, 8450084/536868352 blocks
[root@myhost /]# fsck.ext3 -f -C /root/completion /dev/sda1
e2fsck 1.35 (28-Feb-2004)
Pass 1: Checking inodes, blocks, and sizes
Inodes that were part of a corrupted orphan linked list found.  Fix<y>?
yes

Inode 26732609 was part of the orphaned inode list.  FIXED.
Inode 26732609 has imagic flag set.  Clear<y>? yes

Inode 26732610 is in use, but has dtime set.  Fix<y>? yes

Inode 26732611 is in use, but has dtime set.  Fix<y>? yes

Inode 26732611 has imagic flag set.  Clear<y>? yes

Inode 26732612 is in use, but has dtime set.  Fix<y>? yes

Inode 26732613 is in use, but has dtime set.  Fix<y>? yes

Inode 26732613 has imagic flag set.  Clear<y>?

/dev/sda1: e2fsck canceled.

/dev/sda1: ***** FILE SYSTEM WAS MODIFIED *****
[root@myhost /]# fsck.ext3 -f /dev/sda1
e2fsck 1.35 (28-Feb-2004)
Pass 1: Checking inodes, blocks, and sizes
Inode 26732609 is in use, but has dtime set.  Fix<y>?

Andreas Dilger

2013-Aug-30 18:07 UTC

head link

Re: Strange fsck.ext3 behavior - infinite loop

On 2013-08-29, at 7:48 PM, Richards, Paul Franklin
wrote:> Strange behavior with fsck.ext3: how to remove a long orphaned inode list?
> 
> After copying data over from one old RAID to another new RAID with rsync,
the dump command would not complete because of filesystem errors on the new
RAID. So I ran fsck.ext3 with the -y option and it would just run in an infinite
loop restarting itself and then trying to correct the same inodes over and over
again. Some of the errors were lots of orphaned inodes. So I ran a tar tape
backup and reformatted it with mkfs.ext3. After restoring the tar backup, I got
the same errors when I ran fsck.ext3 -f. Again fsck.ext3 -y would run in an
infinite loop trying to correct the problem. So I formatted it again and ran
fsck immediately afterwards and it's still detecting corrupted orphaned
inode lists. This is on what should be a pristine filesystem with basically no
files. Is this a hardware problem with the RAID or a bug somewhere or just
normal behavior?
Definitely a bug somewhere.
> [root@myhost /]# mkfs.ext3 /dev/sda1
> mke2fs 1.35 (28-Feb-2004)
First thing I would suggest is to update to a newer version of e2fsprogs, since
this one is 9+ years old and that is a lot of
water under the bridge.

Cheers, Andreas
> Filesystem label> OS type: Linux
> Block size=4096 (log=2)
> Fragment size=4096 (log=2)
> 268435456 inodes, 536868352 blocks
> 26843417 blocks (5.00%) reserved for the super user
> First data block=0
> Maximum filesystem blocks=4294967296
> 16384 block groups
> 32768 blocks per group, 32768 fragments per group
> 16384 inodes per group
> Superblock backups stored on blocks: 
>         32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632,
2654208,
>         4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
>         102400000, 214990848, 512000000
> 
> Writing inode tables: done                            
> Creating journal (8192 blocks): done
> Writing superblocks and filesystem accounting information: done
> 
> This filesystem will be automatically checked every 24 mounts or
> 180 days, whichever comes first.  Use tune2fs -c or -i to override.
> [root@myhost /]# fsck
> fsck         fsck.cramfs  fsck.ext2    fsck.ext3    fsck.msdos   fsck.vfat
> [root@myhost /]# man fsck.ext3
> [root@myhost /]# fsck.ext3 -C /root/completion /dev/sda1
> e2fsck 1.35 (28-Feb-2004)
> /dev/sda1: clean, 11/268435456 files, 8450084/536868352 blocks
> [root@myhost /]# fsck.ext3 -f -C /root/completion /dev/sda1
> e2fsck 1.35 (28-Feb-2004)
> Pass 1: Checking inodes, blocks, and sizes
> Inodes that were part of a corrupted orphan linked list found. 
Fix<y>? yes
> 
> Inode 26732609 was part of the orphaned inode list.  FIXED.
> Inode 26732609 has imagic flag set.  Clear<y>? yes
> 
> Inode 26732610 is in use, but has dtime set.  Fix<y>? yes
> 
> Inode 26732611 is in use, but has dtime set.  Fix<y>? yes
> 
> Inode 26732611 has imagic flag set.  Clear<y>? yes
> 
> Inode 26732612 is in use, but has dtime set.  Fix<y>? yes
> 
> Inode 26732613 is in use, but has dtime set.  Fix<y>? yes
> 
> Inode 26732613 has imagic flag set.  Clear<y>? 
> 
> /dev/sda1: e2fsck canceled.
> 
> /dev/sda1: ***** FILE SYSTEM WAS MODIFIED *****
> [root@myhost /]# fsck.ext3 -f /dev/sda1
> e2fsck 1.35 (28-Feb-2004)
> Pass 1: Checking inodes, blocks, and sizes
> Inode 26732609 is in use, but has dtime set.  Fix<y>?
> 
> _______________________________________________
> Ext3-users mailing list
> Ext3-users@redhat.com
> https://www.redhat.com/mailman/listinfo/ext3-users

Cheers, Andreas

Theodore Ts'o

2013-Aug-30 18:23 UTC

head link

Re: Strange fsck.ext3 behavior - infinite loop

On Fri, Aug 30, 2013 at 12:07:22PM -0600, Andreas Dilger
wrote:> 
> > [root@myhost /]# mkfs.ext3 /dev/sda1
> > mke2fs 1.35 (28-Feb-2004)
> 
> First thing I would suggest is to update to a newer version of e2fsprogs,
since this one is 9+ years old and that is a lot of
> water under the bridge.
That's definitely good advice, but even with e2fsprogs 1.35, if e2fsck
-f is finding errors when run immediately after running mke2fs, it
would make me suspect the storage device.

Are you sure the RAID controller (is this a hw raid, or software raid)
is working correctly?

					- Ted

Possibly Parallel Threads

Search for more apparently analagous threads

Ext3 users - Aug 2013 - Re: Strange fsck.ext3 behavior - infinite loop

Strange fsck.ext3 behavior - infinite loop

Re: Strange fsck.ext3 behavior - infinite loop

Re: Strange fsck.ext3 behavior - infinite loop

Possibly Parallel Threads