Re: [PATCH v2] ovl: improving copy-up efficiency for big sparse file

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Oct 31, 2019 at 11:20 AM Chengguang Xu <cgxu519@xxxxxxxxxxxx> wrote:
>
>  ---- 在 星期四, 2019-10-31 17:06:24 Amir Goldstein <amir73il@xxxxxxxxx> 撰写 ----
>  > >  > I did not explain myself well.
>  > >  >
>  > >  > This should be enough IMO:
>  > >  >
>  > >  > @@ -483,7 +483,7 @@ static int ovl_copy_up_inode(struct
>  > >  > ovl_copy_up_ctx *c, struct dentry *temp)
>  > >  >         }
>  > >  >
>  > >  >         inode_lock(temp->d_inode);
>  > >  > -       if (c->metacopy)
>  > >  > +       if (S_ISREG(c->stat.mode))
>  > >  >                 err = ovl_set_size(temp, &c->stat);
>  > >  >         if (!err)
>  > >  >                 err = ovl_set_attr(temp, &c->stat);
>  > >  >
>  > >  > There is no special reason IMO to try to spare an unneeded ovl_set_size
>  > >  > if it simplifies the code a bit.
>  > >
>  > > We can try this but I'm afraid that someone could complain
>  > > we do unnecessary ovl_set_size() in the case of full copy-up
>  > > or data-end file's copy-up.
>  > >
>  > >
>  >
>  > There is no one to complain.
>  > The cost of ovl_set_size() is insignificant compared to the cost of
>  > copying data (unless I am missing something).
>  > Please post a version as above and if Miklos finds it a problem,
>  > we can add a boolean c->should_set_size to the copy up context, initialize
>  > it: c->should_set_size = (S_ISREG(c->stat.mode) && c->stat.size)
>  > and set it to false in case all data was copied.
>  > I think that won't be necessary though.
>  >
>
> I forgot to mention that there are two callers of  ovl_copy_up_data()
> and ovl_copy_up_meta_inode_data() even don't have logic to set size.

Because set_size was already done during meta copy up and
"data copy up" does not need to change the size again.

> So do you still think set size in ovl_copy_up_inode() is simpler than
> set size inside ovl_copy_up_data()?
>

Yes. One line change is simpler.

Thanks,
Amir.




[Index of Archives]     [Linux Filesystems Devel]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux