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
