[Ocfs2-tools-devel] thoughts on xattr fsck

[Tiger Yang]

Tiger Yang wrote:
> Hi, Joel,
> 
> Joel Becker wrote:
>> wipe_entry:
>>         memmove(); memset();
>>     }
>>
>>     dealloc_used_map(used_map);
>>     return rc;
>>
>> 	The basic idea is that the used_map is a linked list of (offset,
>> length) tuples.  Then check_fits() can make sure a new region, like the
>> next entry you're checking or the name+value it points to, doesn't
>> overlap with any previously seen regions.  This handles the case of
>> out-of-order name_offsets you mentioned earlier.
>> 	What do you think?
>>
>> 	Sorry, (4) should heave read detected_count.  Since we never let
>> detected_count go past the max_count,we are assured that detected_count
>> <= max_count.  Then, if xh_count > detected_count, we ask to fix it.
> 
> The idea about used_map is great and I nearly finished it. One thing I 
> still concerned is that detected_count = max_count in the worst case.
> 
> if the GAP was corrupted, we will get detected_count = max_count, right?
> When we do wipe_entry in your pseudocode, our memmove will move the area 
> form next entry till the #detected_count(is max_count) entry.
> 
> memmove((void *)(xe + 1), (void *)xe, (xh->xh_count - i - 1) * ENTRY_SIZE);
> 
> But the detected_count is wrong, it maybe in the value area, after we 
> memmove, the value area will get overwrite. is this a real problem? or 
> maybe I misinterpret your pseudocode.
> 
> if it's a problem, I have an idea to solve this problem which is base on 
> the used_map linked list. After we go through all entries, we get the 
> list about all looks good entries.  Then we can move the entries 
> according to this list , because we know the exact entry number of each 
> entry. so we don't do memmove in wipe_entry, we only clean it from the 
> used_map. And we only need fix the entry area, in bucket we have a 
> defrag function for value area in kernel.
> 

The attachment is the patch about it for review.
It implement your idea about used_map.

Thanks,
tiger

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-ocfs2-tools-add-xattr-support-in-fsck.ocfs2.patch
Type: text/x-patch
Size: 27597 bytes
Desc: not available
Url : http://oss.oracle.com/pipermail/ocfs2-tools-devel/attachments/20090323/89a80dad/attachment-0001.bin