lkml.org 
[lkml]   [2015]   [May]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH RFC] vfs: add a O_NOMTIME flag
On 5/7/15 10:24 PM, Andy Lutomirski wrote:
> 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.

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



\
 
 \ /
  Last update: 2015-05-08 17:21    [W:0.071 / U:8.328 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site