All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
* [Bug 218648] New: ext4: previously opened file remains writeable on readonly ext4 filesystem; Data loss.
@ 2024-03-27  9:31 bugzilla-daemon
  2024-03-28 14:55 ` [Bug 218648] " bugzilla-daemon
  2024-03-29  9:06 ` bugzilla-daemon
  0 siblings, 2 replies; 3+ messages in thread
From: bugzilla-daemon @ 2024-03-27  9:31 UTC (permalink / raw)
  To: linux-ext4

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

            Bug ID: 218648
           Summary: ext4: previously opened file remains writeable on
                    readonly ext4 filesystem; Data loss.
           Product: File System
           Version: 2.5
    Kernel Version: 6.5
          Hardware: All
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P3
         Component: ext4
          Assignee: fs_ext4@kernel-bugs.osdl.org
          Reporter: zsolt@integrity.hu
        Regression: No

I have a VM on KVM. The KVM image is on GlusterFS and for the test I stopped
the gluster server. If this backend goes offline, the ext4 filesystem will be
readonly in the VM. It's OK.

But if I have a previously opened file (for writing) in this ext4 filesystem. I
can continue to write. The "ls -l" command shows, the file is growing (but the
modification time isn't changes anymore).
Second test: previously mmap-ed file. I can rewrite the 4k blocks on readonly
ext4. Of course, this changes will be lost on reboot.

So the readonly filesystem blocked the new open for writing, but the prevously
opened file can I write, but the data will be lost.

Are these cases normal on readonly filesystem or a bug?

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

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [Bug 218648] ext4: previously opened file remains writeable on readonly ext4 filesystem; Data loss.
  2024-03-27  9:31 [Bug 218648] New: ext4: previously opened file remains writeable on readonly ext4 filesystem; Data loss bugzilla-daemon
@ 2024-03-28 14:55 ` bugzilla-daemon
  2024-03-29  9:06 ` bugzilla-daemon
  1 sibling, 0 replies; 3+ messages in thread
From: bugzilla-daemon @ 2024-03-28 14:55 UTC (permalink / raw)
  To: linux-ext4

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

Theodore Tso (tytso@mit.edu) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tytso@mit.edu

--- Comment #1 from Theodore Tso (tytso@mit.edu) ---
Normally, if there is a file opened for writing when there is an attempt to
remount a file system read-only via a command, e.g., "mount -o remount,ro
/dev/sdc", the remount with fail with EBUSY.

The problem is what should we do if the block device has failed or otherwise
disappeared.   In that situation, we can either do absolutely nothing
("errors=continue"), panic and halt the system ("errors=panic"), or remount the
file-system ("errors=remount-ro").  However, what should be done if there is a
file descriptor open for writing?

1) We could fail the remount, which would mean that the file system would
continue to be mounted read/write, which would cause the behavior to devolve to
"errors=continue".

2) We could force the file system to be read-only, but any file descriptors
that are still would be still open --- but attempts to write to the file will
fail with EIO.

We've chosen because it's the best we can do.  We can refuse a remount
read-only if it is initiated by the system administrator, if a user yanks the
USB thumb drive out of the laptop, or a terrorist slams a plain into the
machine room at the Pentagon, it's not like the kernel can stop something like
that from happening.   ("I'm sorry Hal, I'm afraid I can't allow you to do that
ala the movie "2001: A Spacey Odessey" is not yet a thing; although maybe
sometime soon our AI Overlords will have that power.  :-)

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

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [Bug 218648] ext4: previously opened file remains writeable on readonly ext4 filesystem; Data loss.
  2024-03-27  9:31 [Bug 218648] New: ext4: previously opened file remains writeable on readonly ext4 filesystem; Data loss bugzilla-daemon
  2024-03-28 14:55 ` [Bug 218648] " bugzilla-daemon
@ 2024-03-29  9:06 ` bugzilla-daemon
  1 sibling, 0 replies; 3+ messages in thread
From: bugzilla-daemon @ 2024-03-29  9:06 UTC (permalink / raw)
  To: linux-ext4

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

Artem S. Tashkinov (aros@gmx.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |ANSWERED

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

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2024-03-29  9:06 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-03-27  9:31 [Bug 218648] New: ext4: previously opened file remains writeable on readonly ext4 filesystem; Data loss bugzilla-daemon
2024-03-28 14:55 ` [Bug 218648] " bugzilla-daemon
2024-03-29  9:06 ` bugzilla-daemon

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.