All of lore.kernel.org
 help / color / mirror / Atom feed
From: bugzilla-daemon@bugzilla.kernel.org
To: linux-ext4@vger.kernel.org
Subject: [Bug 50261] New: Invalid d_type on readdir(), but e2fsck sees correct type
Date: Thu,  8 Nov 2012 09:40:08 +0000 (UTC)	[thread overview]
Message-ID: <bug-50261-13602@https.bugzilla.kernel.org/> (raw)

https://bugzilla.kernel.org/show_bug.cgi?id=50261

           Summary: Invalid d_type on readdir(), but e2fsck sees correct
                    type
           Product: File System
           Version: 2.5
          Platform: All
        OS/Version: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: ext4
        AssignedTo: fs_ext4@kernel-bugs.osdl.org
        ReportedBy: bernd.schubert@fastmail.fm
        Regression: No


While writing the on-disk-format upgrade tool for the next fhgfs version, I
also added a sanity check for the hash-directories. And while testing it it
reported a problem:

* Migrating inodes... (Processing 8192 hash directories...)
* Progress: 
Warning entry is not a directory: /fhgfs/meta/meta.dir//entries/A7 type: 8
Warning entry is not a directory: /fhgfs/meta/meta.dir//entries/177 type: 8
Warning entry is not a directory: /fhgfs/meta/meta.dir//entries/739 type: 8
Warning entry is not a directory: /fhgfs/meta/meta.dir//entries/835 type: 8
Warning entry is not a directory: /fhgfs/meta/meta.dir//entries/D84 type: 8
Warning entry is not a directory: /fhgfs/meta/meta.dir//entries/111C type: 8
Warning entry is not a directory: /fhgfs/meta/meta.dir//entries/13C1 type: 8
Warning entry is not a directory: /fhgfs/meta/meta.dir//entries/15B7 type: 8
Warning entry is not a directory: /fhgfs/meta/meta.dir//entries/17EB type: 8
Warning entry is not a directory: /fhgfs/meta/meta.dir//entries/19CA type: 8
Warning entry is not a directory: /fhgfs/meta/meta.dir//entries/1FD4 type: 8

So somehow those few directories out of 8192 (for dentries and inodes, each, so
two times 8192) seem to have a wrong directory type. 
So I went ahead and checked if e2fsck would correct it. But e2fsck reported no
errors. So I went further ahead and added some debug code to e2fsck and indeed,
e2fsck sees the correct type:

inode: 6293106 nameLen: 4 entryName: 17EB fileType: 2 should_be: 2

(fprintf line in check_filetype() ).

For verification, the stat() output also looks right:

schubert@squeeze2 ~>stat /fhgfs/meta/meta.dir//entries/17EB
  File: `/fhgfs/meta/meta.dir//entries/17EB'
  Size: 4096            Blocks: 8          IO Block: 4096   directory
Device: fe10h/65040d    Inode: 6293106     Links: 2
Access: (0755/drwxr-xr-x)  Uid: ( 5741/schubert)   Gid: (  100/   users)
Access: 2012-11-07 13:37:00.280689000 +0100
Modify: 2012-10-31 16:27:14.024689006 +0100
Change: 2012-10-31 16:27:14.024689006 +0100


So somehow either libc or kernel report a wrong file_type field for those
dentries. I will do some in-kernel debugging later on.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

             reply	other threads:[~2012-11-08  9:40 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-08  9:40 bugzilla-daemon [this message]
2013-07-22 16:28 ` [Bug 50261] Invalid d_type on readdir(), but e2fsck sees correct type bugzilla-daemon

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=bug-50261-13602@https.bugzilla.kernel.org/ \
    --to=bugzilla-daemon@bugzilla.kernel.org \
    --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.