On Wed, Dec 1, 2021 at 8:31 AM Chengguang Xu <cgxu519@xxxxxxxxxxxx> wrote: > > > ---- 在 星期三, 2021-12-01 10:37:15 Chengguang Xu <cgxu519@xxxxxxxxxxxx> 撰写 ---- > > > > ---- 在 星期三, 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. > > Right.. > > 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? > Maybe you can still pull off a simpler version by remarking dirty only writably mmapped upper AND inode_is_open_for_write(upper)? If I am not mistaken, if you always mark overlay inode dirty on ovl_flush() of FMODE_WRITE file, there is nothing that can make upper inode dirty after last close (if upper is not mmaped), so one more inode sync should be enough. No? Thanks, Amir.
