xfs
[Top] [All Lists]

File type is occasionally wrong

To: xfs@xxxxxxxxxxx
Subject: File type is occasionally wrong
From: Jan Kara <jack@xxxxxxx>
Date: Tue, 6 Jan 2015 14:56:08 +0100
Delivered-to: xfs@xxxxxxxxxxx
User-agent: Mutt/1.5.21 (2010-09-15)
  Hello,

  I've got two reports of XFS filesystem corruption where file type is
wrong. Both machines are running fairly recent kernels (currently
3.19-rc2) but it's hard to say when the corruption started to happen since
it isn't easily observable.

Attached is xfs_repair log. The interesting part there is:
would fix ftype mismatch (7/1) in directory/child inode 805307401/805388292
would fix ftype mismatch (1/7) in directory/child inode 805307401/805388295
would fix ftype mismatch (7/1) in directory/child inode 939525153/939541565
would fix ftype mismatch (7/1) in directory/child inode 939525153/939540212
would fix ftype mismatch (7/1) in directory/child inode 939525153/939539662
would fix ftype mismatch (7/1) in directory/child inode 939525153/939525162
would fix ftype mismatch (7/1) in directory/child inode 939525153/939525165
would fix ftype mismatch (7/1) in directory/child inode 939525153/939529260
would fix ftype mismatch (7/1) in directory/child inode 939525153/939540177
would fix ftype mismatch (1/7) in directory/child inode 939525153/939539749
would fix ftype mismatch (1/7) in directory/child inode 939525153/939529266
would fix ftype mismatch (1/7) in directory/child inode 939525153/939541566
would fix ftype mismatch (1/7) in directory/child inode 939525153/939540205
would fix ftype mismatch (1/7) in directory/child inode 939525153/939540211
would fix ftype mismatch (1/7) in directory/child inode 939525153/939525182
would fix ftype mismatch (1/7) in directory/child inode 939525153/939540269

So it seems that the file type between a regular file and a symlink gets
swapped. Since both directories where corruption happens are relatively
large (13 and 9 blocks respectively - they are /usr/bin and
/usr/share/man/man8) it seems as if file type wasn't properly updated when
the directory entry tree is updated or something like that. I have briefly
looked into the code but from a first look everything looks fine there...

I have also metadump without obfuscated names available so I can
provide that on request. Interestingly, in the second directory all the
directory entries for regular files that have file type set as symlink are
in the first directory block while inconsistency in other direction is in
other directory blocks.

I will be looking into this further but if some more knowledgeable has an
idea it would be welcome.

                                                                Honza

-- 
Jan Kara <jack@xxxxxxx>
SUSE Labs, CR

Attachment: xfs_repair.log
Description: Text document

<Prev in Thread] Current Thread [Next in Thread>