On 5/7/15 10:24 PM, Andy Lutomirski wrote: > 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. I was going to suggest the same. Make infrastructure available for an app to request O_NOMTIME, but a mount option must be set to allow it, so the administrator doesn't get an unhappy surprise at backup-restore time. (Not a big fan of more twiddly knobs, but that seems to put the control in all the right places). -Eric -- 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
