All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Weinberger <richard.weinberger@gmail.com>
To: Zach Brown <zab@redhat.com>
Cc: Dave Chinner <david@fromorbit.com>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Sage Weil <sweil@redhat.com>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	"open list:ABI/API" <linux-api@vger.kernel.org>
Subject: Re: [PATCH RFC] vfs: add a O_NOMTIME flag
Date: Thu, 7 May 2015 21:09:58 +0200	[thread overview]
Message-ID: <CAFLxGvw8ESrM6vZ4iB70JFQN-qR-Trs3j1O_+y36tSOn0GVH4A@mail.gmail.com> (raw)
In-Reply-To: <20150507172053.GA659@lenny.home.zabbo.net>

On Thu, May 7, 2015 at 7:20 PM, Zach Brown <zab@redhat.com> 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.

But how can Joey random user know that some of his
applications are using O_NOMTIME and his KISS backup
program does no longer function as expected?

-- 
Thanks,
//richard

WARNING: multiple messages have this Message-ID (diff)
From: Richard Weinberger <richard.weinberger-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Zach Brown <zab-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: Dave Chinner <david-FqsqvQoI3Ljby3iVrkZq2A@public.gmane.org>,
	Alexander Viro
	<viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>,
	Sage Weil <sweil-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	linux-fsdevel
	<linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"open list:ABI/API"
	<linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH RFC] vfs: add a O_NOMTIME flag
Date: Thu, 7 May 2015 21:09:58 +0200	[thread overview]
Message-ID: <CAFLxGvw8ESrM6vZ4iB70JFQN-qR-Trs3j1O_+y36tSOn0GVH4A@mail.gmail.com> (raw)
In-Reply-To: <20150507172053.GA659-fypN+1c5dIyjpB87vu3CluTW4wlIGRCZ@public.gmane.org>

On Thu, May 7, 2015 at 7:20 PM, Zach Brown <zab-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 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.

But how can Joey random user know that some of his
applications are using O_NOMTIME and his KISS backup
program does no longer function as expected?

-- 
Thanks,
//richard

  parent reply	other threads:[~2015-05-07 19:10 UTC|newest]

Thread overview: 84+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-06 22:00 [PATCH RFC] vfs: add a O_NOMTIME flag Zach Brown
2015-05-06 22:00 ` Zach Brown
2015-05-06 22:14 ` Trond Myklebust
2015-05-06 22:19   ` Sage Weil
2015-05-06 22:41     ` Zach Brown
2015-05-06 22:41       ` Zach Brown
2015-05-06 22:46       ` Sage Weil
2015-05-06 22:46         ` Sage Weil
2015-05-06 23:21     ` Theodore Ts'o
2015-05-06 23:21       ` Theodore Ts'o
2015-05-07  0:26 ` Dave Chinner
2015-05-07  0:26   ` Dave Chinner
2015-05-07 17:20   ` Zach Brown
2015-05-07 17:20     ` Zach Brown
2015-05-07 18:43     ` Zach Brown
2015-05-07 19:09     ` Richard Weinberger [this message]
2015-05-07 19:09       ` Richard Weinberger
2015-05-07 19:53       ` Andy Lutomirski
     [not found]         ` <554BC4D8.9010507@nod.at>
2015-05-07 20:06           ` Andy Lutomirski
2015-05-08  2:42         ` Dave Chinner
2015-05-08  2:42           ` Dave Chinner
2015-07-14 11:44         ` Pavel Machek
2015-05-08  1:01     ` Sage Weil
2015-05-08  1:23       ` Trond Myklebust
2015-05-08  1:23         ` Trond Myklebust
2015-05-08 15:19         ` Sage Weil
2015-05-08 22:13         ` Dave Chinner
2015-05-08 22:13           ` Dave Chinner
2015-05-08 22:24           ` Sage Weil
2015-05-08 22:24             ` Sage Weil
2015-05-10 23:13             ` Trond Myklebust
2015-05-10 23:13               ` Trond Myklebust
2015-05-11  7:31               ` Dave Chinner
2015-05-11  7:31                 ` Dave Chinner
2015-05-11 16:39                 ` Sage Weil
2015-05-11 17:12                   ` Trond Myklebust
2015-05-11 17:30                     ` Sage Weil
2015-05-11 17:30                       ` Sage Weil
2015-05-12  1:21                       ` Dave Chinner
2015-05-12 23:12                         ` Sage Weil
2015-05-13  0:57                           ` Dave Chinner
2015-05-12 13:41                       ` John Stoffel
2015-05-12 13:41                         ` John Stoffel
2015-05-11 14:47               ` Theodore Ts'o
2015-05-11 16:24                 ` Sage Weil
2015-05-11 16:24                   ` Sage Weil
2015-05-11 23:10                   ` Theodore Ts'o
2015-05-11 23:10                     ` Theodore Ts'o
2015-05-12  5:08                     ` Kevin Easton
2015-05-12 11:45                       ` Austin S Hemmelgarn
2015-05-12 11:45                         ` Austin S Hemmelgarn
2015-05-12 13:54                         ` John Stoffel
2015-05-12 13:54                           ` John Stoffel
2015-05-12 14:36                           ` J. Bruce Fields
2015-05-12 14:53                             ` Austin S Hemmelgarn
2015-05-12 14:53                               ` Austin S Hemmelgarn
2015-05-12 21:51                               ` Dave Chinner
2015-05-13 15:16                                 ` Austin S Hemmelgarn
2015-05-12 22:39                             ` NeilBrown
2015-05-12 22:39                               ` NeilBrown
2015-05-12 22:39                               ` NeilBrown
2015-07-14 13:13                               ` Pavel Machek
2015-07-14 13:13                                 ` Pavel Machek
2015-07-15  4:54                                 ` NeilBrown
2015-07-15  4:54                                   ` NeilBrown
2015-07-22 13:47                                   ` Pavel Machek
2015-07-22 13:47                                     ` Pavel Machek
2015-05-12 21:35                       ` Sage Weil
2015-05-12 21:35                         ` Sage Weil
2015-05-13 12:32                   ` Jan Kara
2015-05-13 12:32                     ` Jan Kara
2015-05-08 14:29       ` John Stoffel
2015-07-14 11:50         ` Pavel Machek
2015-05-08 14:43       ` Austin S Hemmelgarn
2015-05-08 14:43         ` Austin S Hemmelgarn
2015-05-08 17:11       ` Zach Brown
2015-05-08 17:11         ` Zach Brown
2015-05-08  2:37     ` Dave Chinner
2015-05-08  2:37       ` Dave Chinner
2015-05-08  3:24       ` Andy Lutomirski
2015-05-08  3:24         ` Andy Lutomirski
2015-05-08 14:44         ` Eric Sandeen
2015-05-08 14:44           ` Eric Sandeen
2015-05-11 20:36           ` J. Bruce Fields

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAFLxGvw8ESrM6vZ4iB70JFQN-qR-Trs3j1O_+y36tSOn0GVH4A@mail.gmail.com \
    --to=richard.weinberger@gmail.com \
    --cc=david@fromorbit.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sweil@redhat.com \
    --cc=viro@zeniv.linux.org.uk \
    --cc=zab@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.