> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
