Bug 218648 - ext4: previously opened file remains writeable on readonly ext4 filesystem; Data loss.
Summary: ext4: previously opened file remains writeable on readonly ext4 filesystem; D...
Status: RESOLVED ANSWERED
Alias: None
Product: File System
Classification: Unclassified
Component: ext4 (show other bugs)
Hardware: All Linux
: P3 normal
Assignee: fs_ext4@kernel-bugs.osdl.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-03-27 09:31 UTC by Zsolt
Modified: 2024-03-29 09:06 UTC (History)
1 user (show)

See Also:
Kernel Version: 6.5
Subsystem:
Regression: No
Bisected commit-id:


Attachments

Description Zsolt 2024-03-27 09:31:57 UTC
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?
Comment 1 Theodore Tso 2024-03-28 14:55:22 UTC
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.  :-)

Note You need to log in before you can comment on or make changes to this bug.