Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1505250

Re: [POC/RFC PATCH] overlayfs: fix data inconsistency at copy up

From Vivek Goyal <vgoyal@redhat.com>
Newsgroups linux.kernel
Subject Re: [POC/RFC PATCH] overlayfs: fix data inconsistency at copy up
Date 2016-10-20 23:00 +0200
Message-ID <susBx-49j-7@gated-at.bofh.it> (permalink)
References <srrVg-52p-33@gated-at.bofh.it> <susrL-45X-1@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Thu, Oct 20, 2016 at 04:46:30PM -0400, Vivek Goyal wrote:

[..]
> > +static ssize_t ovl_read_iter(struct kiocb *iocb, struct iov_iter *to)
> > +{
> > +	struct file *file = iocb->ki_filp;
> > +	bool isupper = OVL_TYPE_UPPER(ovl_path_type(file->f_path.dentry));
> > +	ssize_t ret = -EINVAL;
> > +
> > +	if (likely(!isupper)) {
> > +		const struct file_operations *fop = ovl_real_fop(file);
> > +
> > +		if (likely(fop->read_iter))
> > +			ret = fop->read_iter(iocb, to);
> > +	} else {
> > +		struct file *upperfile = filp_clone_open(file);
> > +
> 
> IIUC, every read of lower file will call filp_clone_open(). Looking at the
> code of filp_clone_open(), I am concerned about the overhead of this call.
> Is it significant? Don't want to be paying too much of penalty for read
> operation on lower files. That would be a common case for containers.
> 

Looks like I read the code in reverse. So if I open a file read-only,
and if it has not been copied up, I will simply call read_iter() on
lower filesystem. But if file has been copied up, then I will call
filp_clone_open() and pay the cost. And this will continue till this
file is closed by caller. 

When file is opened again, by that time it is upper file and we will
install real fop in file (instead of overlay fop).

Vivek

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: [POC/RFC PATCH] overlayfs: fix data inconsistency at copy up Vivek Goyal <vgoyal@redhat.com> - 2016-10-20 22:50 +0200
  Re: [POC/RFC PATCH] overlayfs: fix data inconsistency at copy up Vivek Goyal <vgoyal@redhat.com> - 2016-10-20 23:00 +0200
    Re: [POC/RFC PATCH] overlayfs: fix data inconsistency at copy up Amir Goldstein <amir73il@gmail.com> - 2016-10-21 11:00 +0200
      Re: [POC/RFC PATCH] overlayfs: fix data inconsistency at copy up Vivek Goyal <vgoyal@redhat.com> - 2016-10-21 22:20 +0200
        Re: [POC/RFC PATCH] overlayfs: fix data inconsistency at copy up Amir Goldstein <amir73il@gmail.com> - 2016-10-22 09:30 +0200
          Re: [POC/RFC PATCH] overlayfs: fix data inconsistency at copy up Amir Goldstein <amir73il@gmail.com> - 2016-10-22 17:40 +0200
            Re: [POC/RFC PATCH] overlayfs: fix data inconsistency at copy up Miklos Szeredi <miklos@szeredi.hu> - 2016-10-24 10:20 +0200
    Re: [POC/RFC PATCH] overlayfs: fix data inconsistency at copy up Miklos Szeredi <miklos@szeredi.hu> - 2016-10-21 11:20 +0200
      Re: [POC/RFC PATCH] overlayfs: fix data inconsistency at copy up Vivek Goyal <vgoyal@redhat.com> - 2016-10-21 15:40 +0200
  Re: [POC/RFC PATCH] overlayfs: fix data inconsistency at copy up Amir Goldstein <amir73il@gmail.com> - 2016-10-21 11:20 +0200
    Re: [POC/RFC PATCH] overlayfs: fix data inconsistency at copy up Miklos Szeredi <miklos@szeredi.hu> - 2016-10-21 11:40 +0200
      Re: [POC/RFC PATCH] overlayfs: fix data inconsistency at copy up Amir Goldstein <amir73il@gmail.com> - 2016-10-21 15:20 +0200

csiph-web