Re: [RFC PATCH v5 06/10] ovl: implement overlayfs' ->write_inode operation

[Chengguang Xu]

 ---- 在 星期三, 2021-12-01 03:04:59 Amir Goldstein <amir73il@xxxxxxxxx> 撰写 ----
 > >  > 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.



Thanks,
Chengguang