Sage> I think this is the fundamental question: who do we give the
Sage> ammunition to, the user or app writer, or the sysadmin?
Sage> One might argue that we gave the user a similar power with
Sage> O_NOATIME (the power to break applications that assume atime is
Sage> accurate). Here we give developers/users the power to not
Sage> update mtime and suffer the consequences (like, obviously,
Sage> breaking mtime-based backups). It should be pretty obvious to
Sage> anyone using the flag what the consequences are.
Not modifying atime doesn't really break anything except people who
think they can tell when a file was last accessed. Which isn't
critical (unless your in a paranoid security conscious place...) but
MTIME is another beast entirely. Turning that off is going to break
lots of hidden assumptions.
Sage> Note that we can suffer similar lapses in mtime with fdatasync
Sage> followed by a system crash. And as Andy points out it's
Sage> semi-broken for writable mmap. The crash case is obviously a
Sage> slightly different thing, but the idea that mtime can't always
Sage> be trusted certainly isn't crazy talk.
True, but after a crash... people expect and understand there might be
corruption in a filesystem.
Umm. No; people do not expect anything newer than ext3 to get
corrupted, ever.
In fact, I did not know about fdatasync/crash. That's rather nasty
surprise.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html