Messages in this thread | | | From | Andy Lutomirski <> | Date | Thu, 7 May 2015 20:24:49 -0700 | Subject | Re: [PATCH RFC] vfs: add a O_NOMTIME flag |
| |
On May 8, 2015 8:11 AM, "Dave Chinner" <david@fromorbit.com> 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@fromorbit.com > -- > To unsubscribe from this list: send the line "unsubscribe linux-api" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
| |