Bug 404 - turning off htree causes fsck to complain
Summary: turning off htree causes fsck to complain
Status: CLOSED CODE_FIX
Alias: None
Product: File System
Classification: Unclassified
Component: ext3 (show other bugs)
Hardware: i386 Linux
: P2 low
Assignee: Andrew Morton
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-02-24 11:42 UTC by Burton Windle
Modified: 2003-05-12 20:08 UTC (History)
0 users

See Also:
Kernel Version: 2.5.62-bk7
Subsystem:
Regression: ---
Bisected commit-id:


Attachments

Description Burton Windle 2003-02-24 11:42:29 UTC
Distribution: Debian Testing
Hardware Environment: x86, IDE
Software Environment: 
ext3+htree

Problem Description:

It seems that if you remove htree (tune2fs -O ^dir_index /dev/xxx), and do a 
fsck, it will complain about inodes with INDEX_FL flag set on filesystem 
without htree support. This isn't a big deal, but causes auto-fscks-on-boot to 
fail, and drop you to single-user mode, scaring the living crap out of the 
SysAdmin in the process. I don't know if tune2fs should remove the INDEX_FL 
flag when removing htree from an ext3 drive, or if the kernel can fix these 
(very minor) "errors". Or should I be complaining to the author of tune2fs?

Steps to reproduce:

Create/modify an ext3 partition with htree, force a directory optimization with 
e2fsck -D /dev/xxx, then remove htree, and fsck again. You'll get lots of these:

Inode 1999038 has INDEX_FL flag set on filesystem without htree support.
Clear HTree index<y>? yes

Inode 2015948 has INDEX_FL flag set on filesystem without htree support.
Clear HTree index<y>? yes

Inode 2033401 has INDEX_FL flag set on filesystem without htree support.
Clear HTree index<y>? yes

Inode 2051968 has INDEX_FL flag set on filesystem without htree support.
Clear HTree index<y>? yes
Comment 1 Burton Windle 2003-02-24 14:20:26 UTC
From: Andreas Dilger <adilger@clusterfs.com>
To: Andrew Morton <akpm@digeo.com>
Cc: ext2-devel@lists.sourceforge.net, bwindle-kbt@fint.org

This should probably only cause e2fsck to exit with a return code of "1",
which means errors were encountered, but could be fixed automatically.

It appears this problem exists in the 1.32 release, but is already fixed
in the BK code by adding the PR_PREEN_OK flag on that error code, so it
will now just clean it up when running "fsck -a" or "e2fsck -p".

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

Note You need to log in before you can comment on or make changes to this bug.