[Ocfs2-tools-devel] thoughts on xattr fsck

Tiger Yang tiger.yang at oracle.com
Fri Mar 20 04:05:52 PDT 2009


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.

thanks,
tiger



More information about the Ocfs2-tools-devel mailing list