On 9/18/17 12:30 PM, Darrick J. Wong wrote:
> On Mon, Sep 18, 2017 at 12:18:50PM -0500, Eric Sandeen wrote:
>>
>>
>> On 9/18/17 12:16 PM, Eric Sandeen wrote:
>>>> @@ -812,6 +813,12 @@ _("%s fork in %s inode %" PRIu64 " claims used block %" PRIu64 "\n"),
>>>> forkname, ftype, ino, b);
>>>> goto done;
>>>>
>>>> + case XR_E_COW:
>>>> + do_warn(
>>>> +_("%s fork in %s inode %" PRIu64 " claims CoW block %" PRIu64 "\n"),
>>>> + forkname, ftype, ino, b);
>>>> + goto done;
>>>> +
>>> why do cow blocks get a special case and custom warning vs the above cases
>>> that just say "metadata?"
>>>
>>> Obviously it's just nitpicking over the do_warn message string, just
>>> double checking on the consistency front.
>>
>> And this was also found via the rmap, but that fact isn't printed like
>> it is for every other type. For that reason I'd probably rather just add
>> XR_RE_COW above the /* fallthrough */ too, for consistency. Thoughts?
>
> Strictly speaking, CoW blocks aren't metadata; they're, uh, alternate
> data.
Oh, fair point. ok.
> I'd rather have xfs_repair deliver a more specific message about
> the other alleged owner of a block so I'd know where to start looking --
> "claims CoW blocks" implies that I ought to start looking at the rmapbt
> for cow-owned blocks and the refcountbt, vs. just "shares with metadata,
> urk".
*nod*
> That said, we probably ought to have the rmapbt scan set XR_E_COW1 and
> have the refcountbt scan set XR_E_COW (similar to what we do for things
> like INUSE/INUSE1). Will try to work on that for 4.14, but for now
> let's at least not abort xfs_repair here.
yep not asking for the world here, just trying to understand and maybe plant
the seeds for future cleanups. ;)
-Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
