Linux 6.8 To Allow Blocking Writes To Mounted Block Devices

[phoronix]

Phoronix: Linux 6.8 To Allow Blocking Writes To Mounted Block Devices

As part of the VFS changes submitted for the upcoming Linux 6.8 merge window, a new "BLK_DEV_WRITE_MOUNTED" Kconfig option is added that allows controlling whether writes are allowed to mounted block devices...

https://www.phoronix.com/news/Linux-6.8-Block-Dev-Write-Mount

[ThomasD]

So this prevents me from accidentally overwriting /dev/sda with dd, when /dev/sda1 is mounted?

[bug77]

Title could use some rewording, I thought it now allows writes that block (i.e., non-async).

[xorbe]

"Allow Blocking" -> "Support Disabling"

[skeevy420]

Btrfs is currently opted out of this because they still haven't merged
patches we require for this to work from three kernel releases ago.

* Reimplement block device freezing and thawing as holder operations on the
block device.

This allows us to extend block device freezing to all devices associated with
a superblock and not just the main device. It also allows us to remove
get_active_super() and thus another function that scans the global list of
superblocks.

Freezing via additional block devices only works if the filesystem chooses to
use @fs_holder_ops for these additional devices as well. That currently only
includes ext4 and xfs.

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.

[coder]

Title could use some rewording, I thought it now allows writes that block (i.e., non-async).

Exactly.

"Linux 6.8 To Allow Blocking Writes To Mounted Block Devices"

My first thought was along the lines of: "wow, did they only support async writes?"
🤣

[coder]

So this prevents me from accidentally overwriting /dev/sda with dd, when /dev/sda1 is mounted?

Uh, not quite that, I presume. Otherwise, you couldn't run parted to create a new partition on /dev/sda, when a filesystem from any sda partition is mounted. I've most often done things like that on USB drives. Not so much on internal drives.

I think it would just keep you from clobbering sda1 when sda1 is mounted.

[bug77]

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.

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

[stormcrow]

So this prevents me from accidentally overwriting /dev/sda with dd, when /dev/sda1 is mounted?

Not entirely clear in the explanation, but it appears like it will prevent any program from writing to the underlying block device while a filesystem on that device is mounted regardless of it being r/o or r/w. So yes, it probably would... however... what's not clear is whether or not it will actually block the worst case scenario as well - when you need to fsck a potentially corrupted r/o root partition. As stated, this is the case where this particular operation is absolutely essential. Having one kernel capable of doing this, while the default kernel is incapable would be highly inconvenient should such a situation occur, especially if you have several kernels in your system due to updates and you can't remember which is which. I think this is another one of those kernel options where "If you don't know exactly what this does, leave it on default setting."

[Old Grouch]

Not entirely clear in the explanation, but it appears like it will prevent any program from writing to the underlying block device while a filesystem on that device is mounted regardless of it being r/o or r/w. So yes, it probably would... however... what's not clear is whether or not it will actually block the worst case scenario as well - when you need to fsck a potentially corrupted r/o root partition. As stated, this is the case where this particular operation is absolutely essential. Having one kernel capable of doing this, while the default kernel is incapable would be highly inconvenient should such a situation occur, especially if you have several kernels in your system due to updates and you can't remember which is which. I think this is another one of those kernel options where "If you don't know exactly what this does, leave it on default setting."

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.

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.