Reiser4 on an inherently read-only block device
Paul Whittaker <[email protected]>
| Newsgroups | gmane.comp.file-systems.reiserfs.general |
|---|---|
| Organization | ThinLinX Pty Ltd |
| Message-ID | <[email protected]> |
Hi Reiser developers, Reiser4 is almost perfect for our (thinlinx.com's) needs except for one problem: it wants to write to the block device even when mounted read-only, and handles errors ungracefully (read as: crashes and burns) when it can't - specifically, when performing the umount operation. I haven't been able to devise a simple reproducer for this, e.g. using a tiny ISO9660 filesystem, so there must be some subtleties that I am unaware of, but it happens 100% of the time when using our real data. We have a couple of use cases that necessarily involve inherently read-only block devices: 1) We want to provide an ISO9660-based installer for our O/S that contains a Reiser4 (kinda-sorta-)root filesystem image that the installer would mount read-only via loopback to inspect certain files prior to dd'ing it to a target disk. 2) We want to share a copy of the Reiser4 (kinda-sorta-)root filesystem, which is mounted read-only on a writeable medium, read-only via the ATA-over-Ethernet protocol for use by network-booted instances of our O/S (this is feasible because the *real* root filesystem is AUFS with a couple of additional writeable layers). The resulting /dev/etherd/eX.Y block device is inherently read-only - if it isn't, we risk write contention and Bad Things. Unless I'm missing something, Reiser4 doesn't provide any mount option that would permit safe operation in the above use cases. Btrfs provides a "norecovery" a.k.a. "nologreplay" option that allows suppression of transaction log replay in situations in which the integrity of the filesystem is already guaranteed. Is it possible to add a comparable mount option in Reiser4? It seems to me that read-only should mean **read only**! FYI we are using the latest Git state of https://github.com/edward6/reiser4 that compiles cleanly on a Linux 5.4 kernel (commit 1a55b8ed6e0ac4de20135146d77bac4607d59fbe). Regards, Paul Whittaker (<[email protected]> or <[email protected]>), ThinLinX Pty Ltd