[Ocfs2-tools-devel] [PATCH 0/6] Fix extent records for holes/overlaps

[Goldwyn Rodrigues]

Hi Tiger,

On Fri, Sep 2, 2011 at 1:22 AM, Tiger Yang <tiger.yang at oracle.com> wrote:
>>> I have tested the new patches with test cases of punching hole at the
>>> beginning and middle, them can't fix the problems.
>>> I have studied this problem and I found the reason is the new size of dir
>>> inode changed by fsck is wrong. In my test case, blocksize is 1024,
>>> cluster
>>> size if 4096,  dir size is 23552 (23 blocks), but it taken 6 clusters (24
>>> blocks) , so when fsck found a hole and reduce that cluster, the new size
>>> became 20480, it include the last uninitialized block in the last
>>> cluster.
>>> so in pass2,  ocfs2_read_dir_block->  ocfs2_validate_meta_ecc ->
>>> ocfs2_block_check_validate will return OCFS2_ET_IO. For hole at the
>>> beginning, the fix should initialize "." and ".." in the directory as
>>> Joel
>>> commented on bug 1324.
>>
>> How did you punch the holes? Did you wipe out existing data from the
>> directories? The idea of the patchset is to fix extent records.
>
> ocfs2 don't allow to punch holes on directory inode, So I modify the code
> both in kernel and in tools. you can see the attached patches below.
> Yes, that tools wipe out the existing data like punch holes on common file.
> I think only fix extent records is not enough to fix this problem, the
> customer may have corrupted directory inode like I had. Do we need another
> patch to fix this?

Yes.

>>
>> After fixing DIRENT_NOT_DOTTY were you able to access file of the
>> inodes 37414 from the directory? Do you know of a situation where
>> after fixing DIRENT_NOT_DOTTY the file represented by dirent fixed is
>> lost?
>
> I know fixing DIRENT_NOT_DOTTY will cause file lost, but I think we can add
> "." and ".." instead of change the files to them in the directory. Joel also
> commented this on bugzilla.

What you have discovered here is a bug in DIRENT_NOT_DOTTY. Instead of
blindly writing on the starting of the directory entry fsck must check
for existing valid dirents and try and re-insert them at a later
position. This can happen for reasons other than punching holes. If
you wish I can expose this problem with a small change in fswreck.

What comes next is the inability of fsck being able to find the parent
directory and it exits with an error. In a situation as this, where
the link/inode to the parent directory is lost, what is the best way
to find the inode number of the parent directory?


Thanks,

-- 
Goldwyn