[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Cluster-devel] [gfs2-utils PATCH 06/47] fsck.gfs2: Check for formal inode mismatch when adding to lost+found



Hi,

On Fri, 2013-05-17 at 08:47 -0400, Bob Peterson wrote:
> ----- Original Message -----
> | Hi,
> | 
> | On Tue, 2013-05-14 at 11:21 -0500, Bob Peterson wrote:
> | > This patch adds a check to the code that adds inodes to lost+found
> | > so that dinodes with formal inode mismatches are logged, but not added.
> | > 
> | I'm not sure I understand what this one is doing. If there is a mismatch
> | between the dir entry and the inode that suggests that the dir entry and
> | inode are not related to the same thing,
> | 
> | Steve.
> 
> Hi,
> 
> Yes, you're correct, and this mismatch is precisely why it's wrong
> to add the file to lost+found, and that's what this patch is avoiding.
> 
I'm not sure that makes it any clearer... if the inode and the dir entry
do not have the same formal inode number, then there are three possible
causes:

1. There is no relation between the two, so we must add the inode to
lost+found and delete the directory entry. This might happen if the
inode number has become corrupted in the directory entry for example.
2. The inode has a corrupt formal inode number, and we can potentially
fix that by setting it to the same as the directory entry
3. The directory entry has a corrupt formal inode number, and we can
potentially fix that by setting it to be the same as the one in the
inode

How can we tell the difference between the three situations? I suspect
in reality that will be quite tricky to do, and I'm not sure that I
follow the logic here,

Steve.


> Regards,
> 
> Bob Peterson
> Red Hat File Systems



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]