[Ocfs2-tools-devel] [PATCH] mount.ocfs2: return -EROFS if file system is readonly
Eric Ren
zren at suse.com
Wed Dec 27 22:41:17 PST 2017
Hi Jun,
>>>>> 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
>> .
>>
> Yes, when readonly device detected but readonly mount was not
> specified, we will also get -EROFS from kernel as below:
Hmm, I just feel it's strange to return OCFS2_ET_CORRUPT_INODE_BLOCK to
user while kernel actually kernel returns EROFS. Well, I could be wrong.
>
> ocfs2_fill_super
> ...
> if (bdev_read_only(sb->s_bdev)) {
> ...
> ocfs2_set_ro_flag(osb, 1);
> ...
> }
>
> That is hard-ro error. Sadly we can hardly distinguish it from soft-ro,
Hmm, I think it's OK to see hard-ro and soft-ro as readonly. So, why not
just
return "readonly" error code to user? define it if it doesn't exist?
> and fsck seems useless. I just come up with a solution that we could
> use -EACCES instead of -EROFS in this case. I'm glad to hear your
> suggestion.
Hmm, EACCES seems not fit here:
#define EACCES 13 /* Permission denied */
Thanks,
Eric
More information about the Ocfs2-tools-devel
mailing list