[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