Donate Share

Ext2 Filesystems Utilities

Tracker: Bugs

5 e2fsck does not fix problem detected in pass 2 - ID: 2862551
Last Update: Comment added ( tytso )

I have a ~500 GB ext2 filesystem that I wanted to check after a crash. It
had dir_index set and has a quite a lot of directories. While checking I
realized that pass 3A "Optimizing directories" had an ETA of about 5 days.
This was possible by a local modification giving pass 3A progress output.
Then, I killed e2fsck and deleted the dir_index feature with tune2fs.
Checking again, e2fsck reasonably cleared all htree indexes. However,
apart from some other problems, it reported in pass 2:
Duplicate entry '........nf' found.
Marking /sets/2009-06-11T03:05_lar:437/opt/applix/axfonts/sun_snf
(27364312) to be rebuilt.
and in pass 3A:
Entry '........nf' in
/sets/2009-06-11T03:05_lar:437/opt/applix/axfonts/sun_snf (27364312) has a
non-unique filename.
Rename to ........nf~0? yes
Entry '........snf' in
/sets/2009-06-11T03:05_lar:437/opt/applix/axfonts/sun_snf (27364312) has a
non-unique filename.
Rename to ........sn~0? yes

Now here is the e2fsck problem. Doing another check gives
e2fsck 1.41.9 (22-Aug-2009)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Duplicate entry '........snf' found.
Marking
/sets/2009-06-11T03:05_lar:437/opt/applix/axfonts/sun_snf (27364312) to be
rebuilt.

Pass 3: Checking directory connectivity
Pass 3A: Optimizing directories
Pass 4: Checking reference counts
Pass 5: Checking group summary information

backup: ***** FILE SYSTEM WAS MODIFIED *****
backup: 11590540/32152680 files (3.3% non-contiguous),
522271246/522602480 blocks

Running e2fsck again and again gives the same result. The last step is
with a vanilla 1.41.9 without local modifications.

I can keep this filesystem in this state for another few days to track the
problem. Unfortunately I cannot make the filesystem publicly available.
I'm fairly familiar with C programming but have no knowledge of the inner
workings of e2fsprogs nor ext2 layout. What would be the next step?
Please reach me at springl-e2fsprogs@bfw-online.de.

Stephan Springl


Nobody/Anonymous ( nobody ) - 2009-09-20 09:58

5

Closed

Fixed

Theodore Ts'o

e2fsck

None

Public


Comments ( 4 )

Date: 2009-11-17 02:58
Sender: tytsoProject AdminAccepting Donations

Fixed in commit b71e0183 on the e2fsprogs maint branch.


Date: 2009-11-16 13:50
Sender: sascha_silbe

Correction: renaming worked (renamed the wrong file originally - /olpc.fth,
not /boot/olpc.fth).



Date: 2009-11-16 13:30
Sender: sascha_silbe

Due to a driver bug in Open Firmware, I also ended up with a duplicate
entry (but otherwise the filesystem was clean). e2fsck didn't fix it:

flatty:~# fsck -f -y /dev/mmcblk0p1
fsck from util-linux-ng 2.16.1
e2fsck 1.41.9 (22-Aug-2009)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Duplicate entry 'olpc.fth' found.
Marking /boot (32263) to be rebuilt.

Pass 3: Checking directory connectivity
Pass 3A: Optimizing directories
Pass 4: Checking reference counts
Pass 5: Checking group summary information

debxo-boot: ***** FILE SYSTEM WAS MODIFIED *****
debxo-boot: 51/64512 files (5.9% non-contiguous), 24759/64512 blocks
flatty:~# fsck -f -y /dev/mmcblk0p1
fsck from util-linux-ng 2.16.1
e2fsck 1.41.9 (22-Aug-2009)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Duplicate entry 'olpc.fth' found.
Marking /boot (32263) to be rebuilt.

Pass 3: Checking directory connectivity
Pass 3A: Optimizing directories
Pass 4: Checking reference counts
Pass 5: Checking group summary information

debxo-boot: ***** FILE SYSTEM WAS MODIFIED *****
debxo-boot: 51/64512 files (5.9% non-contiguous), 24759/64512 blocks
flatty:~#

Even renaming the offending file doesn't change this cycle; the file name
remains the same (olpc.fth) in fsck, but ls doesn't list the old name
anymore.




Date: 2009-10-23 23:55
Sender: extensive

Same problem here with the latest version from git. I think the cause of
the problem is that when e2fsck_rehash_dir() calls
duplicate_search_and_fix(), duplicate_search_and_fix() expects fd->harray
to be sorted by name, but it is provided either sorted by inode or by hash.

As a consequence, duplicate filenames are not repaired by rehashing the
directory.

Cheers!

Thiemo Nagel


Attached File

No Files Currently Attached

Changes ( 4 )

Field Old Value Date By
close_date - 2009-11-17 02:58 tytso
allow_comments 1 2009-11-17 02:58 tytso
resolution_id None 2009-11-17 02:58 tytso
status_id Open 2009-11-17 02:58 tytso