[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