Re: unmount(2) returning EROFS

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Wed, 6 Nov 2024 17:14:12 +0100
    From:        Edgar =?iso-8859-1?B?RnXf?= <ef%math.uni-bonn.de@localhost>
    Message-ID:  <ZyuV1Op/4musIFR9%trav.math.uni-bonn.de@localhost>

  | Yes, but mounting the ffs device without -r either results in the mount
  | being read-only, in which case there should be no such thing,

That would be (and perhaps now is in later systems, I have no idea)
not unreasonable.

  | or not, in which case it shouldn't complain EROFS.

My guess is that what is happening, is that the mount (being just
a ffs mount after all) does not turn into a read only mount, and so
operations which change things (like say, the access times on files
that are being read for backups ... which is why using dump(8) or
something like it is so much better than tar style "backups") are
permitted, but as always, when performed, just affect the in core
cached version of the inode (there's no need to immediately write
inodes because of a changed time field).

Then when it is time to actually write the data that has changed
back to the filesystem (say, on an unmount, or a sync) the ffs code
detects that you're trying to write to a snapshot, which isn't
allowed (those are read only objects, they define the state of the
world at some past time, which obviously can't be altered after that
time) so the filesystem returns EROFS (the underlying filesystem is
read only - just like a (real, not user programmable) CD or DVD is.

  | OK, then I just mount -r.

That is certainly what you should do, snapshots are read only, and
should be mounted that way.

kre