[Ocfs2-tools-devel] [PATCH] mount.ocfs2: return -EROFS if file system is readonly

Eric Ren zren at suse.com
Wed Dec 27 21:17:47 PST 2017


Hi Jun,


On 12/28/2017 11:58 AM, Joseph Qi wrote:
>
> On 17/12/28 10:01, piaojun wrote:
>> Hi Joseph,
>>
>> On 2017/12/28 9:11, Joseph Qi wrote:
>>>
>>> On 17/12/27 17:12, piaojun wrote:
>>>> If metadata is corrupted such as 'invalid inode block', we will get
>>>> -EROFS by calling 'mount()'. In this situation we need fix it by fsck,
>>>> and mount again rather than doing meaningless retry.
>>>>
>>>> Signed-off-by: Jun Piao <piaojun at huawei.com>
>>>> ---
>>>>   mount.ocfs2/mount.ocfs2.c | 13 ++++++++++---
>>>>   1 file changed, 10 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/mount.ocfs2/mount.ocfs2.c b/mount.ocfs2/mount.ocfs2.c
>>>> index e3d8871..1ab07ac 100644
>>>> --- a/mount.ocfs2/mount.ocfs2.c
>>>> +++ b/mount.ocfs2/mount.ocfs2.c
>>>> @@ -434,8 +434,15 @@ int main(int argc, char **argv)
>>>>   			o2cb_complete_group_join(&cluster, &desc, errno);
>>>>   		}
>>>>   		block_signals (SIG_UNBLOCK);
>>>> -		com_err(progname, ret, "while mounting %s on %s. Check 'dmesg' "
>>>> -			"for more information on this error.", mo.dev, mo.dir);
>>>> +		if (ret == -EROFS)
>>>> +			com_err(progname, 0, "file system is now readonly due to "
>>>> +				"on-disk corruption while mounting %s on %s, please "
>>>> +				"fix this by fsck.ocfs2 and then retry mounting",
>>>> +				mo.dev, mo.dir);
>>> Could we use a meaningful error code instead of 0?
>>>
>>> Thanks,
>>> Joseph
>> I looked over 'ocfs2_err.et', and did not find a suitable error code.
>> Should we define a new error code like this?
>>
>> --
>> ec OCFS2_ET_CORRUPT_INODE_BLOCK,
>> "Inode block is corrupt"
>> --
>>
> Yes, I think it should be acceptable.

Does it mean we will always interpret EROFS code ( returned from 
kernel?) as
"inode block corruption"? Is there some other internal error returning 
EROFS?

Thanks,
Eric



More information about the Ocfs2-tools-devel mailing list