On 2015-12-14 14:44, Christoph Anton Mitterer wrote:
On Mon, 2015-12-14 at 14:33 -0500, Austin S. Hemmelgarn wrote:
The traditional reasoning was that read-only meant that users
couldn't
change anything
Where I'd however count the atime changes to.
The atimes wouldn't change magically, but only because the user stared
some program, configured some daemon, etc. ... which reads/writes/etc.
the file.
But reading the file is allowed, which is where this starts to get
ambiguous. Reading a file updates the atime (and in fact, this is the
way that most stuff that uses them cares about them), but even a ro
mount allows reading the file. The traditional meaning of ro on UNIX
was (AFAIUI) that directory structure couldn't change, new files
couldn't be created, existing files couldn't be deleted, flags on the
inodes couldn't be changed, and file data couldn't be changed. TBH, I'm
not even certain that atime updates on ro filesystems was even an
intentional thing in the first place, it really sounds to me like the
type of thing that somebody forgot to put in a permissions check for,
and then people thought it was a feature.
, 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).
Wasn't tmpwatcher anoterh candidate?
Most such software can use it, but doesn't depend on it. TBH, many
people these days run /tmp (and even /var/tmp) on an in memory
filesystem, so atime updates aren't as much of an issue there. Also,
even with noatime, I'm pretty sure the VFS updates the atime every time
the mtime changes (because not doing so would be somewhat stupid, and
you're writing the inode anyway), which technically means that stuff
could work around this by opening the file, truncating it to the size it
already is, and then closing it.
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.
Of course, you're right! :-)
(especially when btrfs should ever be formalised in a standards
document, this should read like:
hard-ro: Nothing on the backing device may change as a result of the
FS, however, e.g. maleware, may directly destroy the data on the
blockdevice ;-)
Chris.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
