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

[Goldwyn Rodrigues]

Hi Tiger,

Thanks for testing.

2011/9/15 Tiger Yang <tiger.yang at oracle.com>:
> On 09/08/2011 09:31 AM, Goldwyn Rodrigues wrote:
>>
>> I tried recreating this on my system with fswreck and was unable to do so.
>> On second looks, creation of "." and ".." entries works fine but
>> re-creating the indexed directories errs. Again, the dirblock on which
>> it errs is the same, 61467. Could you provide me the output of
>> debugfs.ocfs2 dirblocks<dirname>  for the directory in question:
>>
>> 1. after creating the directory
>> 2. after punching holes
>> 3. after fsck.ocfs2
>
> Hi, Goldwyn,
>
> good news! I patched your 6 patches to the newest ocfs2-tools git tree, and
> tested them again with the 3.1.0 kernel, the result is good.

Are you sure about patching the ocfs2-tools? From the logs and the
message posted it did not fix anything. IOW, the holes still exist and
there is no fsck message which says "NO_HOLES".

> Patched fsck can fix the hole at the middle, but in case hole at the
> beginning, there is still the ".." directory issue can't be fixed.

If what I observe is true, This just proves the problem in inherent
without the patches.
Oh wait, it is also possible because there were no dentries in the
first block which it could use and modify, which would be possible
after holes are fixed.


> Please see the attached log files. I recorded the logs as you expected.
>
> after puch holes at the beginning:
> fsck.ocfs2 -f /dev/sda10
> fsck.ocfs2 1.8.0
> Checking OCFS2 filesystem in /dev/sda10:
>  Label: <NONE>
>  UUID:               D550FC1A362A41E09E1DF1CF5DBE5FC9
>  Number of blocks:   125676460
>  Block size:         1024
>  Number of clusters: 31419115
>  Cluster size:       4096
>  Number of slots:    8
>
> /dev/sda10 was run with -f, check forced.
> Pass 0a: Checking cluster allocation chains
> Pass 0b: Checking inode allocation chains
> Pass 0c: Checking extent block allocation chains
> Pass 1: Checking inodes and blocks.

I was expecting a NO_HOLES prompt here.. See comments above.

> Pass 2: Checking directory entries.
> Pass 3: Checking directory connectivity.
> [DIR_DOTDOT] Directory inode 663558 is referenced by a dirent in directory 9
> but its '..' entry points to inode 0. Fix the '..' entry to reference 9? <y>
> y
> Didn't find a '..' entry to fix.
> Pass 4a: checking for orphaned inodes
> Pass 4b: Checking inodes link counts.
> All passes succeeded.

Could you please cross-check?

-- 
Goldwyn