All of lore.kernel.org
 help / color / mirror / Atom feed
From: bugzilla-daemon@bugzilla.kernel.org
To: linux-ext4@vger.kernel.org
Subject: [Bug 214927] New: re-mount read-write (mount -oremount,rw) of read-only filesystem rejected with EROFS, but block device is nor read-only
Date: Wed, 03 Nov 2021 09:49:27 +0000	[thread overview]
Message-ID: <bug-214927-13602@https.bugzilla.kernel.org/> (raw)

https://bugzilla.kernel.org/show_bug.cgi?id=214927

            Bug ID: 214927
           Summary: re-mount read-write (mount -oremount,rw) of read-only
                    filesystem rejected with EROFS, but block device is
                    nor read-only
           Product: File System
           Version: 2.5
    Kernel Version: 4.12.14-122.91-default (SLES12 SP5)
          Hardware: All
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: ext3
          Assignee: fs_ext3@kernel-bugs.osdl.org
          Reporter: Ulrich.Windl@rz.uni-regensburg.de
        Regression: No

I think there's a kernel or filesystem bug related to ext3:
We run a SLES12 SP5 Xen PVM that gets its system disk from a sparse file
located on a SLES15 SP2 Xen host using OCFS2 (the host is a node in a pacemaker
cluster).

The OCFS2 filesystem became full or almost full, and thus the ext3
filesystem(s) experienced write errors, remounting to read-only.
So far, so good, but:
The errors behavior of ext 3 was set to "continue", so I wonder why it had been
set to read-only at all.
Next, after having extended the OCFS2 filesystem size, any remount-attempt
fails with:

mount: /: cannot remount /dev/... read-write, is write-protected.

I strace-d the mount command and the mount syscall is returning EROFS
(Read-only filesystem).
However in the VM configuration on the host the disk is marked read-write, the
disk in the VM is flagged read-write, also the VG, LVs, etc. I checked the
/sys/block/*/ro, too: It's all "0".

I also did an fsck (which succeeded), but still after that the error is the
same.
Interestingly I noticed that after a *failed* remount attempt, the filesystem
(that is mounted read-only) got the error flag being set again.

The only conclusion I have is that there is at least one kernel bug regarding
the read-only status of the block device.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

             reply	other threads:[~2021-11-03  9:49 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-03  9:49 bugzilla-daemon [this message]
2021-11-03  9:49 ` [Bug 214927] re-mount read-write (mount -oremount,rw) of read-only filesystem rejected with EROFS, but block device is not read-only bugzilla-daemon
2021-11-03  9:58 ` bugzilla-daemon
2021-11-03 10:06 ` bugzilla-daemon
2021-11-03 15:13 ` bugzilla-daemon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-214927-13602@https.bugzilla.kernel.org/ \
    --to=bugzilla-daemon@bugzilla.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.