On Fri, Jun 29, 2018 at 6:35 AM, cgxu519 <cgxu519@xxxxxxx> wrote: > Hi guys, > > I have a simple question about copy-up timing after implementing stacked > file operation. > Could we postpone copy-up until first real write happens? > > The background is consuming much time on open is unexpected for some of our > applications. > I need this behavior as well for snapshots. On first glance it looks feasible to me. Seems like we could relax copy up on open(O_RDWR) if there were no special open flags (O_TRUNC, O_CREATE, O_APPEND...), then mask out O_ACCMODE if opening a lower inode and defer copy up to ovl_real_fdget_meta() in case the O_ACCMODE flags of file and real->file don't match. Then we can introduce ovl_real_fdget_read() call to be used in ovl_read_iter() and ovl_copyfile() (in_file) in which cases the mismatch O_ACCMODE flags doesn't need to be corrected with copy up. Miklos? Does this sound reasonable to you? Chengguang, Will you take a swing at implementing this if there are no holes found in the plan? Do you know if your applications typically open files with O_RDWR? any other flags? Deferring copy up to first write with O_WRONLY seems a bit more tricky. Thanks, Amir. -- To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
