From: Vivek Goyal <vgoyal@redhat.com>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
overlayfs <linux-unionfs@vger.kernel.org>,
Chengguang Xu <cgxu519@gmx.com>
Subject: Re: [RFC][PATCH] ovl: lazy copy up of data on first write
Date: Fri, 18 Jan 2019 14:52:02 -0500 [thread overview]
Message-ID: <20190118195202.GB2832@redhat.com> (raw)
In-Reply-To: <CAOQ4uxihLM_ztQ487SMiWr6w6646J0VfBpbNHyeybxX77COKsQ@mail.gmail.com>
On Fri, Jan 18, 2019 at 05:33:36PM +0200, Amir Goldstein wrote:
> On Fri, Jan 18, 2019 at 4:43 PM Vivek Goyal <vgoyal@redhat.com> wrote:
> >
> > On Fri, Jan 18, 2019 at 03:45:19PM +0200, Amir Goldstein wrote:
> > > When metacopy feature is enabled, copy up only metadata when
> > > opening a file O_RDWR and defer copy up of data until the first
> > > write operation.
> > >
> >
> > Amir,
> >
> > What's the primary use case of lazy data copy up. Are there users who
> > open file O_RDWR but never write to it.
>
> I don't know of all the cases, but AFAIK, MSOffice apps (over network share
> and maybe also LibreOffice) open the document file O_RDWR just to check
> if editing is allowed, but but they re-open the file read-only, because the
> document file is never written to. A temp file is written and moved over it.
> So copy up of an MSOffice document file data is never beneficial.
>
> > Or we want to transfer latency of copy up from open to write.
>
> Indeed. Chengguang reported that in their use case, the latency at open
> time is an issue.
>
> >
> > Should this behavior be an opt in with another mount option (and not
> > be enabled automatically with metacopy=on).
> >
>
> I can't think of one good reason for user to opt-in for copy up data on open.
> Or on a use case where latency on open is desired over latency on write.
> Can you?
IIUC, now if I open a file O_RDWR and only issue reads to file and never
issue writes, then for every read, I will open a lower file, finish read
and close fd. This is slower path. What's the performance penalty? If
this is significant, then it might make sense to opt-in for lazy copy
up behavior (instead of relying that application will open file O_RDONLY
if they never issue writes to it).
Thanks
Vivek
next prev parent reply other threads:[~2019-01-18 19:52 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-18 13:45 [RFC][PATCH] ovl: lazy copy up of data on first write Amir Goldstein
2019-01-18 14:43 ` Vivek Goyal
2019-01-18 15:33 ` Amir Goldstein
2019-01-18 18:34 ` Vivek Goyal
2019-01-18 19:57 ` Amir Goldstein
2019-01-18 19:52 ` Vivek Goyal [this message]
2019-01-18 20:12 ` Amir Goldstein
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=20190118195202.GB2832@redhat.com \
--to=vgoyal@redhat.com \
--cc=amir73il@gmail.com \
--cc=cgxu519@gmx.com \
--cc=linux-unionfs@vger.kernel.org \
--cc=miklos@szeredi.hu \
/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.