On 2015-12-14 14:16, Christoph Anton Mitterer wrote:
On Mon, 2015-12-14 at 12:50 -0500, Austin S. Hemmelgarn wrote:
It should also imply noatime. I'm not sure how BTRFS handles atime
when
mounted RO, but I know a lot of old UNIX systems updated atime even
on
filesystems mounted RO, and I know that at least at one point Linux
did too.
I stumbled over that recently myself, and haven't bothered to try it
out, yet.
But Duncan's argument, why at least ro-snapshots (yes I know, this may
not be exactly the same as RO mount option) would need to imply
noatime, is pretty convincing. :)
The traditional reasoning was that read-only meant that users couldn't
change anything, not that the actual data on disk wouldn't change.
That, and there's been some really brain-dead software over the years
that depended on atimes being right (now, the only remaining software I
know of that even uses them at all is Mutt).
Anyway, if it "ro" wouldn't imply noatime, I would ask why, because the
atime is definitely something the fs exports normally to userland,...
and that's how I'd basically consider hard-ro vs. (soft-)ro:
soft-ro: data as visible by the mounted fs must not change (unless
perhaps for necessary repair/replay operations to get the
filesystem back in a consistent state)
hard-ro: soft-ro + nothing on the backing devices may change (bitwise)
This should be 'Nothing on the backing device may change as a result of
the FS', nitpicking I know, but we should be specific so that we
hopefully avoid ending up in the same situation again.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
