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
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
