[LU-14570] e2fsck reports "Entry '..' an incorrect filetype (was 18, should be 1)"

• Status: Open
• Project: Lustre
• Type: Bug
• Priority: Minor
• Reporter: Andreas Dilger
• Assignee: Andreas Dilger
• Resolution: Unresolved
• Labels: e2fsck
• Severity: 3

Description

Running e2fsck on a DNE filesystem where LFSCK was run reported:

Entry '..' in <195395086>/<195395122> (195395122) has an incorrect filetype (was 18, should be 1).
Entry '..' in <602879868>/<602879869> (602879869) has an incorrect filetype (was 18, should be 1).
Entry '..' in <134818057>/<134818059> (134818059) has an incorrect filetype (was 18, should be 1).
Entry '..' in <134818057>/<134818064> (134818064) has an incorrect filetype (was 18, should be 1).
Entry '..' in <134818057>/<134818066> (134818066) has an incorrect filetype (was 18, should be 1).

This is because the entry file_type has a flag EXT2_DIRENT_LUFID when the dirdata feature stores the FID in the directory entry, and it should be masked when checking the file type.

Issue Links

• is related to: LU-15913 rename stress test leads to REMOTE_PA...

Comments

[Andreas Dilger]

The trail on this issue went a bit cold, but I'm adding some notes of what I remember before it is lost completely:

• the fix is not as clear as it initially seemed, because the ".." entry was actually pointing to an inode that is a regular file
• that is of course bad, because it means that there is a problem with the directory structure itself
• the fix is not to change the file type in the .. dirent here, but to "fix" the parent directory itself so that it is a directory
• it isn't clear in this case whether the type of the parent directory was lost/incorrect in the inode, and it should be a directory, or if that is some random file?
• if it is a random file, it would be better to reconnect this directory to lost+found rather than trying to repair the dirent type, unless the parent directory inode itself has the wrong type. There is a "try as directory" check in e2fsck that could be used to see if the parent is really a valid directory

[Artem Blagodarenko (Inactive)]

We have faced with the quite the same issue using rename stress test. Without LFSCK 

Entry '14,37275pp37273,aaaaaaaaaa,bbbbbbbbbb,cccccccccc,dddddddddd,eeeeeeeeee,ffffffffff,gggggggggg,hhh' in /REMOTE_PARENT_DIR/0x24006497a:0x129bc:0x0 (4014289161) has an incorrect filetype (was 17, should be 2).
Fix? no
  

 

 '..' in /REMOTE_PARENT_DIR/0x24006497a:0x129bc:0x0/14,37275pp37273,aaaaaaaaaa,bbbbbbbbbb,cccccccccc,dddddddddd,eeeeeeeeee,ffffffffff,gggggggggg,hhh (4014289162) is /REMOTE_PARENT_DIR (4030089985), should be /REMOTE_PARENT_DIR/0x24006497a:0x129bc:0x0 (4014289161).
Fix? no

Another symptoms that looks related are

Entry '0x24006b05d:0xa4c8:0x0' in /REMOTE_PARENT_DIR (4030089985) is a link to directory /REMOTE_PARENT_DIR/0x24006497a:0x129bc:0x0/14,37275pp37273,aaaaaaaaaa,bbbbbbbbbb,cccccccccc,dddddddddd,eeeeeeeeee,ffffffffff,gggggggggg,hhh (4014289162 fid=[0x20006a4b1:0x42c6:0x0]).
Clear? no


Entry '0x24006afb0:0x3075:0x0' in /REMOTE_PARENT_DIR (4030089985) is a link to directory /REMOTE_PARENT_DIR/0x24006497a:0x12a59:0x0/27,4155pp4153,aaaaaaaaaa,bbbbbbbbbb,cccccccccc,dddddddddd,eeeeeeeeee,ffffffffff,gggggggggg,hhhhhhhhhh,iiiiiiiiii,jjjjjjjjjj,kkkkkkkkkk,llllllllll, (2072103563).
Clear? no

'..' in /REMOTE_PARENT_DIR/0x24006497a:0x129bc:0x0/14,37275pp37273,aaaaaaaaaa,bbbbbbbbbb,cccccccccc,dddddddddd,eeeeeeeeee,ffffffffff,gggggggggg,hhh (4014289162) is /REMOTE_PARENT_DIR (4030089985), should be /REMOTE_PARENT_DIR/0x24006497a:0x129bc:0x0 (4014289161).
Fix? no
...
'..' in /REMOTE_PARENT_DIR/0x24006497a:0x12a59:0x0/27,4155pp4153,aaaaaaaaaa,bbbbbbbbbb,cccccccccc,dddddddddd,eeeeeeeeee,ffffffffff,gggggggggg,hhhhhhhhhh,iiiiiiiiii,jjjjjjjjjj,kkkkkkkkkk,llllllllll, (2072103563) is /REMOTE_PARENT_DIR (4030089985), should be /REMOTE_PARENT_DIR/0x24006497a:0x12a59:0x0 (2072103562).
Fix? no