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. :) 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) Cheers, Chris.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
