From: Eric Sandeen <sandeen@redhat.com>
To: Andreas Dilger <adilger@clusterfs.com>
Cc: ext4 development <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH] dir_index: error out instead of BUG on corrupt hash dir limit
Date: Fri, 10 Aug 2007 13:39:49 -0500 [thread overview]
Message-ID: <46BCB0F5.5060701@redhat.com> (raw)
In-Reply-To: <20070810181901.GT6689@schatzie.adilger.int>
Andreas Dilger wrote:
> On Aug 10, 2007 11:08 -0500, Eric Sandeen wrote:
>> Andreas Dilger wrote:
>>> I'd like to see the actual corruption, to find out why the hash-type
>>> check didn't find it. If it is because LDISKFS_DX_HASH_LEGACY hash
>>> type is zero, I think we can disable that hash type, and people will
>>> just have to run "e2fsck -fD" to reindex to a new type. This hasn't
>>> been on for a long, long time.
>> So far I haven't been able to find it in any of the images provided.
>>
>> We may have to dual-boot windows & run the crummy driver for a while to
>> track it down, if we care enough.
>>
>> Which reminds me, what do you think of the wording in the ext3_warning I
>> added - is "corruption" appropriate? The other warnings aren't quite so
>> stark... hmm maybe we should add "have you been running a binary-only
>> driver for windows?" :)
>
> It would be interesting to check if mounting a dir_index filesystem on
> linux with ext2 has the same problem. It _should_ have been that
> if rec_len % 4 == 0 (i.e. any valid dirent) we would fail the hash_version
> check, but we left in the DX_HASH_LEGACY (0) and that check is blown.
Hmmm...
> The unused_flags & 1 is only hit for a dirent with DT_FIFO (no good).
> The remaining check is indirect_levels > 1, which should be hit for
> any dirent with name_len > 1 (i.e. most, but not all).
>
> So, I think you could reproduce this in linux by making an indexed directory
> in ext3/4, mounting it as ext2, and then creating a 1-character filename
> in the directory, or any length filename and then deleting it.
With those quick tests I don't see any problems... you may be giving the
windows driver too much credit here. :)
-Eric
> In addition to your extra check, I think we should remove DX_HASH_LEGACY
> check, to catch this more easily. If (hash_version % 4 == 0) the warning
> shouldn't even be printed.
>
> Cheers, Andreas
> --
> Andreas Dilger
> Principal Software Engineer
> Cluster File Systems, Inc.
>
next prev parent reply other threads:[~2007-08-10 18:39 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-09 21:33 [PATCH] dir_index: error out instead of BUG on corrupt hash dir limit Eric Sandeen
2007-08-09 22:41 ` Eric Sandeen
2007-08-10 8:29 ` Andreas Dilger
2007-08-10 16:08 ` Eric Sandeen
2007-08-10 18:19 ` Andreas Dilger
2007-08-10 18:39 ` Eric Sandeen [this message]
2007-08-10 18:51 ` Andreas Dilger
2007-08-10 8:26 ` Andreas Dilger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=46BCB0F5.5060701@redhat.com \
--to=sandeen@redhat.com \
--cc=adilger@clusterfs.com \
--cc=linux-ext4@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.