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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.