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.
Hmm, no idea why, but I cannot reproduce it anymore. When it occured it was very reproducible, but I didn't have time to investigate that time. So I'm closing it for now.