On May 8, 2015 8:11 AM, "Dave Chinner" <david@xxxxxxxxxxxxx> wrote: > > On Thu, May 07, 2015 at 10:20:53AM -0700, Zach Brown wrote: > > On Thu, May 07, 2015 at 10:26:17AM +1000, Dave Chinner wrote: > > > On Wed, May 06, 2015 at 03:00:12PM -0700, Zach Brown wrote: > > > > Add the O_NOMTIME flag which prevents mtime from being updated which can > > > > greatly reduce the IO overhead of writes to allocated and initialized > > > > regions of files. > > > > > > Hmmm. How do backup programs now work out if the file has changed > > > and hence needs copying again? ie. applications using this will > > > break other critical infrastructure in subtle ways. > > > > By using backup infrastructure that doesn't use cmtime. Like btrfs > > send/recv. Or application level backups that know how to do > > incrementals from metadata in giant database files, say, without > > walking, comparing, and copying the entire thing. > > "Use magical thing that doesn't exist"? Really? > > e.g. you can't do incremental backups with tools like xfsdump if > mtime is not being updated. The last thing an admin wants when > doing disaster recovery is to find out that the app started using > O_NOMTIME as a result of the upgrade they did 6 months ago. Hence > the last 6 months of production data isn't in the backups despite > the backup procedure having been extensively tested and verified > when it was first put in place. > > > > > The criteria for using O_NOMTIME is the same as for using O_NOATIME: > > > > owning the file or having the CAP_FOWNER capability. If we're not > > > > comfortable allowing owners to prevent mtime/ctime updates then we > > > > should add a tunable to allow O_NOMTIME. Maybe a mount option? > > > > > > I dislike "turn off safety for performance" options because Joe > > > SpeedRacer will always select performance over safety. > > > > Well, for ceph there's no safety concern. They never use cmtime in > > these files. > > Understood. > > > So are you suggesting not implementing this > > No. > > > Or are we talking about adding some speed bumps > > that ceph can flip on that might give Joe Speedracer pause? > > Yes, but not just Joe Speedracer - if it can be turned on silently > by apps then it's a great big landmine that most users and sysadmins > will not know about until it is too late. What about programs like tar that explicitly override mtime? No admin buy-in is required for that. Admittedly, that doesn't affect ctime, nor is it as likely to bite unexpectedly as a nomtime flag. I think it would be reasonably safe if a mount option had to be set to allow O_NOCMTIME or such. --Andy > Cheers, > > Dave. > -- > Dave Chinner > david@xxxxxxxxxxxxx > -- > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
