Re: [PATCH v3] btrfs: Introduce new mount option to disable tree log replay

["Austin S. Hemmelgarn" <ahferroin7@gmail.com>]

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.
>