Linux 6.8 To Allow Blocking Writes To Mounted Block Devices

[Nocifer]

BTRFS doesn't work yet and a person would need Ext4 or XFS to have full use of it. If they're using encrypted systemd-homed, then Ext4 with or without LUKS2. The way features in Linux file systems and system software overlap is a mess and what pushed me towards a certain out of tree file system. That's not an advertisement for that other file system, that's just me being frustrated about how too much choice and freedoms in open source can become a bad thing when too many things are trying to achieve the same goals in different manners so we end up with a hodgepodge of random feature support across the board.

IMHO, file systems need to be "Waylandized". By that I mean that there needs to be a protocol for Linux that describes a minimal file system supported feature set to help clean up all that mess so people don't have to worry about if the software supports the file system if both the file system and software can state they both support 1.1 of the Alesia Protocol.

But isn't this how it works right now? The kernel/Wayland declares support for a new feature/protocol, then the filesystems/compositors are free to implement it at their own pace; and while some of the filesystems/compositors (like EXT4/KWin) implement these features/protocols faster, others (like Btrfs/xfwm) lag behind due to lacking time/resources/some prerequisite feature or other. And that certain out of tree filesystem is subject to the same procedure, so you using it does not save you from the headache.

The only real difference with Wayland is that with the kernel we have a central, shared "library", while with Wayland we don't. But that's a different discussion for a different thread

[skeevy420]

But isn't this how it works right now? The kernel/Wayland declares support for a new feature/protocol, then the filesystems/compositors are free to implement it at their own pace; and while some of the filesystems/compositors (like EXT4/KWin) implement these features/protocols faster, others (like Btrfs/xfwm) lag behind due to lacking time/resources/some prerequisite feature or other. And that certain out of tree filesystem is subject to the same procedure, so you using it does not save you from the headache.

The only real difference with Wayland is that with the kernel we have a central, shared "library", while with Wayland we don't. But that's a different discussion for a different thread

Sort of, but no. Right now the way it works is something is added to the kernel and other things may or may not pick that up. Take Zstd. The kernel supports it but that doesn't mean that Ext4 uses it or will ever use it. A protocol around file systems would explicitly state what kinds of encryption algorithms, codecs, checksums, etc should be available, how subvolumes are handled, using fscrypt and, maybe, how to fallback to LUKS, how to handle case sensitivity and potential mixed OS workloads, user permissions and security contexts, how all that is turned on and off; things like that. A file system analog to how Wayland stipulates that a compositor needs to be able to do X, Y, and Z to be called a Wayland compatible compositor or how a graphics driver has to support what it does in order to become OpenGL or Vulkan compliant or to remain compliant as new extensions are added.

FWIW, using that other file system is no less of a headache than using AMDGPU-Pro or NVIDIA drivers. The headache of having to pin the kernel to whatever the driver supports or using a distribution that does it for you

But this isn't about that FS, it's about how the solution in Linux seems to be "One more file system should fix it." instead of dictating/standardizing how file systems should behave. It's like that "One more lane should fix it." meme, except on Highway Linux one lane is Roman, one lane is asphalt, one is cobblestone, one is a mag-lev train track, next to that is a sidewalk, one is an unpaved muddy trail, next to that is a reinforced runway, one is an 1800s train track, beside that is where the bike path is, one is a uneven laid brick, and there's a concrete lane with construction barriers on either side.

[Gonk]

Sounds reasonable: as I understand it, several filesystems that use a journal will replay the the journal even when mounted read-only - e.g. ext4*, and ZFS. From my point of view, mounting a filesystem read-only should do exactly what it says on the the tin, and replaying a journal ought to be a non-default option.

ro
- Mount filesystem read only. Note that ext4 will replay the journal (and thus write to the partition) even when mounted "read only". The mount options "ro,noload" can be used to prevent writes to the filesystem.

Ugh, yeah that violates the principle of least astonishment. norecovery/noload should be forcerecovery/forceload and off by default when mounting read-only. If the filesystem was not unmounted cleanly, spit out a warning about it and say that remounting with forceload will replay the journal, if so desired.

[cend]

That means if /dev/nvme0n1p1 is mounted rw at /boot, for example, then all direct writes from userspace to /dev/nvme0n1p1, /dev/nvme0n1 and /dev/nvme0 would fail with Operation not permitted?

[kreijack]

Sounds reasonable: as I understand it, several filesystems that use a journal will replay the the journal even when mounted read-only - e.g. ext4*, and ZFS. This is why the GRUB filesystem drivers are useful: they are guaranteed read-only and will not apply journalled updates. From my point of view, mounting a filesystem read-only should do exactly what it says on the the tin, and replaying a journal ought to be a non-default option.

*See also the documentation.

Time to time this question comes up. And there is not a real answer:

1) writing into the journal it is enough declare some metadata "as written" (e.g. after a sync); this means that after this point even after a (.e.g) a powerfailure you want to see the updated metadata; you dont'want to care if this was written in the journal or in the real filesystem. From this point of view the a filesystem driver that doesn't consider the journal should be considered "buggy".

The fact that the GRUB driver doesn't consider the journal is not a real issue only because the updating of the data used by grub is not very frequent.

2) there are some situation where you don't want to replay the journal for "safety reasons", like a buggy filesystem driver and/or a not reliable disk.

IMHO both these cases have sense, and most of the filesystem have mount option to skip the journal replay: ext4 has "norecovery", btrfs has nologreplay, xfs has norecovery....). But this should be considered differently from mounting the filesystem RO.

Finally I have to point out that not replaying a journal means that the filesystem may be in an inconsistency state. I don't know how a fsck or grub which read a filesystem, could be reliable int this case.

from ext4 man page

norecovery/noload
  Don't load the journal on mounting. Note that if the file sys‐
  tem was not unmounted cleanly, skipping the journal replay will
  lead to the file system containing inconsistencies that can lead
  to any number of problems.
​

[pWe00Iri3e7Z9lHOX2Qx]

I'm sticking with ext4, that one never disappoints.

Except when changes are backported to LTS "stable" kernels and introduce data corruption?

[bug77]

Except when changes are backported to LTS "stable" kernels and introduce data corruption?

And other file system are immune to that.. how?
Idk which fringe cases you're talking about, my main PC is ext4 for over a decade and never lost me anything. Saw some journal recovery after improper shutdowns, but nothing beyond that.