xfs
[Top] [All Lists]

Re: [PATCH 04/10] xfs_repair: fix broken EFSBADCRC/EFSCORRUPTED usage wi

To: "Darrick J. Wong" <djwong@xxxxxxxxxxxxxxxx>, david@xxxxxxxxxxxxx, darrick.wong@xxxxxxxxxx
Subject: Re: [PATCH 04/10] xfs_repair: fix broken EFSBADCRC/EFSCORRUPTED usage with buffer errors
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Mon, 17 Aug 2015 14:57:09 -0500
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <55D23B3B.6060803@xxxxxxxxxxx>
References: <20150815014338.1839.37405.stgit@xxxxxxxxxxxxxxxx> <20150815014404.1839.75324.stgit@xxxxxxxxxxxxxxxx> <55D23B3B.6060803@xxxxxxxxxxx>
On 8/17/15 2:51 PM, Eric Sandeen wrote:
> On 8/14/15 8:44 PM, Darrick J. Wong wrote:
>> When we encounter CRC or verifier errors, bp->b_error is set to
>> -EFSBADCRC and -EFSCORRUPTED; note the negative sign.  For whatever
>> reason, repair and db use the positive versions, and therefore fail to
>> notice the error, so fix all the broken uses.
>>
>> Note however that the db and repair turn the negative codes returned
>> by libxfs into positive codes that can be used with strerror.
>>
>> Signed-off-by: Darrick J. Wong <darrick.wong@xxxxxxxxxx>
> 
> This looks right, but I think there's more; see:
> 
> XFS_WANT_CORRUPTED_GOTO
> XFS_WANT_CORRUPTED_RETURN
> 
> (these return negative errors in kernelspace)
> 
> and a bunch of stuff in libxlog/xfs_log_recover.c...

Ok, I guess libxlog/* was never switched to negative, and so far it looks
ok.

The XFS_WANT_CORRUPTED* macros seem like a problem, though.

-Eric

<Prev in Thread] Current Thread [Next in Thread>