lkml.org 
[lkml]   [2021]   [Dec]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH v5 06/10] ovl: implement overlayfs' ->write_inode operation

---- 在 星期三, 2021-12-01 10:37:15 Chengguang Xu <cgxu519@mykernel.net> 撰写 ----
>
> ---- 在 星期三, 2021-12-01 03:04:59 Amir Goldstein <amir73il@gmail.com> 撰写 ----
> > > > I was thinking about this a bit more and I don't think I buy this
> > > > explanation. What I rather think is happening is that real work for syncfs
> > > > (writeback_inodes_sb() and sync_inodes_sb() calls) gets offloaded to a flush
> > > > worker. E.g. writeback_inodes_sb() ends up calling
> > > > __writeback_inodes_sb_nr() which does:
> > > >
> > > > bdi_split_work_to_wbs()
> > > > wb_wait_for_completion()
> > > >
> > > > So you don't see the work done in the times accounted to your test
> > > > program. But in practice the flush worker is indeed burning 1.3s worth of
> > > > CPU to scan the 1 million inode list and do nothing.
> > > >
> > >
> > > That makes sense. However, in real container use case, the upper dir is always empty,
> > > so I don't think there is meaningful difference compare to accurately marking overlay
> > > inode dirty.
> > >
> >
> > It's true the that is a very common case, but...
> >
> > > I'm not very familiar with other use cases of overlayfs except container, should we consider
> > > other use cases? Maybe we can also ignore the cpu burden because those use cases don't
> > > have density deployment like container.
> > >
> >
> > metacopy feature was developed for the use case of a container
> > that chowns all the files in the lower image.
> >
> > In that case, which is now also quite common, all the overlay inodes are
> > upper inodes.
> >
>
> Regardless of metacopy or datacopy, that copy-up has already modified overlay inode
> so initialy marking dirty to all overlay inodes which have upper inode will not be a serious
> problem in this case too, right?
>
> I guess maybe you more concern about the re-mark dirtiness on above use case.
>
>
>
> > What about only re-mark overlay inode dirty if upper inode is dirty or is
> > writeably mmapped.
> > For other cases, it is easy to know when overlay inode becomes dirty?
> > Didn't you already try this?
> >
>
> Yes, I've tried that approach in previous version but as Miklos pointed out in the
> feedback there are a few of racy conditions.
>

So the final solution to handle all the concerns looks like accurately mark overlay inode
diry on modification and re-mark dirty only for mmaped file in ->write_inode().

Hi Miklos, Jan

Will you agree with new proposal above?



Thanks,
Chengguang































\
 
 \ /
  Last update: 2021-12-01 07:32    [W:0.258 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site