| Message ID | 20210923130814.140814-7-cgxu519@mykernel.net (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | implement containerized syncfs for overlayfs | expand |
On Thu 23-09-21 21:08:10, Chengguang Xu wrote: > Implement overlayfs' ->write_inode to sync dirty data > and redirty overlayfs' inode if necessary. > > Signed-off-by: Chengguang Xu <cgxu519@mykernel.net> ... > +static int ovl_write_inode(struct inode *inode, > + struct writeback_control *wbc) > +{ > + struct ovl_fs *ofs = inode->i_sb->s_fs_info; > + struct inode *upper = ovl_inode_upper(inode); > + unsigned long iflag = 0; > + int ret = 0; > + > + if (!upper) > + return 0; > + > + if (!ovl_should_sync(ofs)) > + return 0; > + > + if (upper->i_sb->s_op->write_inode) > + ret = upper->i_sb->s_op->write_inode(inode, wbc); > + I'm somewhat confused here. 'inode' is overlayfs inode AFAIU, so how is it correct to pass it to ->write_inode function of upper filesystem? Shouldn't you pass 'upper' there instead? > + if (mapping_writably_mapped(upper->i_mapping) || > + mapping_tagged(upper->i_mapping, PAGECACHE_TAG_WRITEBACK)) > + iflag |= I_DIRTY_PAGES; > + > + iflag |= upper->i_state & I_DIRTY_ALL; Also since you call ->write_inode directly upper->i_state won't be updated to reflect that inode has been written out (I_DIRTY flags get cleared in __writeback_single_inode()). So it seems to me overlayfs will keep writing out upper inode until flush worker on upper filesystem also writes the inode and clears the dirty flags? So you rather need to call something like write_inode_now() that will handle the flag clearing and do writeback list handling for you? Honza
On Thu, 23 Sept 2021 at 15:08, Chengguang Xu <cgxu519@mykernel.net> wrote: > > Implement overlayfs' ->write_inode to sync dirty data > and redirty overlayfs' inode if necessary. > > Signed-off-by: Chengguang Xu <cgxu519@mykernel.net> > --- > fs/overlayfs/super.c | 30 ++++++++++++++++++++++++++++++ > 1 file changed, 30 insertions(+) > > diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c > index 2ab77adf7256..cddae3ca2fa5 100644 > --- a/fs/overlayfs/super.c > +++ b/fs/overlayfs/super.c > @@ -412,12 +412,42 @@ static void ovl_evict_inode(struct inode *inode) > clear_inode(inode); > } > > +static int ovl_write_inode(struct inode *inode, > + struct writeback_control *wbc) > +{ > + struct ovl_fs *ofs = inode->i_sb->s_fs_info; > + struct inode *upper = ovl_inode_upper(inode); > + unsigned long iflag = 0; > + int ret = 0; > + > + if (!upper) > + return 0; > + > + if (!ovl_should_sync(ofs)) > + return 0; > + > + if (upper->i_sb->s_op->write_inode) > + ret = upper->i_sb->s_op->write_inode(inode, wbc); Where is page writeback on upper inode triggered? Thanks, Miklos
---- 在 星期四, 2021-10-07 17:01:57 Jan Kara <jack@suse.cz> 撰写 ---- > On Thu 23-09-21 21:08:10, Chengguang Xu wrote: > > Implement overlayfs' ->write_inode to sync dirty data > > and redirty overlayfs' inode if necessary. > > > > Signed-off-by: Chengguang Xu <cgxu519@mykernel.net> > > ... > > > +static int ovl_write_inode(struct inode *inode, > > + struct writeback_control *wbc) > > +{ > > + struct ovl_fs *ofs = inode->i_sb->s_fs_info; > > + struct inode *upper = ovl_inode_upper(inode); > > + unsigned long iflag = 0; > > + int ret = 0; > > + > > + if (!upper) > > + return 0; > > + > > + if (!ovl_should_sync(ofs)) > > + return 0; > > + > > + if (upper->i_sb->s_op->write_inode) > > + ret = upper->i_sb->s_op->write_inode(inode, wbc); > > + > > I'm somewhat confused here. 'inode' is overlayfs inode AFAIU, so how is it > correct to pass it to ->write_inode function of upper filesystem? Shouldn't > you pass 'upper' there instead? That's right! > > > + if (mapping_writably_mapped(upper->i_mapping) || > > + mapping_tagged(upper->i_mapping, PAGECACHE_TAG_WRITEBACK)) > > + iflag |= I_DIRTY_PAGES; > > + > > + iflag |= upper->i_state & I_DIRTY_ALL; > > Also since you call ->write_inode directly upper->i_state won't be updated > to reflect that inode has been written out (I_DIRTY flags get cleared in > __writeback_single_inode()). So it seems to me overlayfs will keep writing > out upper inode until flush worker on upper filesystem also writes the > inode and clears the dirty flags? So you rather need to call something like > write_inode_now() that will handle the flag clearing and do writeback list > handling for you? > Calling ->write_inode directly upper->i_state won't be updated, however, I don't think overlayfs will keep writing out upper inode since ->write_inode will be called when only overlay inode itself marked dirty. Am I missing something? Thanks, Chengguang
---- 在 星期四, 2021-10-07 17:23:06 Miklos Szeredi <miklos@szeredi.hu> 撰写 ---- > On Thu, 23 Sept 2021 at 15:08, Chengguang Xu <cgxu519@mykernel.net> wrote: > > > > Implement overlayfs' ->write_inode to sync dirty data > > and redirty overlayfs' inode if necessary. > > > > Signed-off-by: Chengguang Xu <cgxu519@mykernel.net> > > --- > > fs/overlayfs/super.c | 30 ++++++++++++++++++++++++++++++ > > 1 file changed, 30 insertions(+) > > > > diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c > > index 2ab77adf7256..cddae3ca2fa5 100644 > > --- a/fs/overlayfs/super.c > > +++ b/fs/overlayfs/super.c > > @@ -412,12 +412,42 @@ static void ovl_evict_inode(struct inode *inode) > > clear_inode(inode); > > } > > > > +static int ovl_write_inode(struct inode *inode, > > + struct writeback_control *wbc) > > +{ > > + struct ovl_fs *ofs = inode->i_sb->s_fs_info; > > + struct inode *upper = ovl_inode_upper(inode); > > + unsigned long iflag = 0; > > + int ret = 0; > > + > > + if (!upper) > > + return 0; > > + > > + if (!ovl_should_sync(ofs)) > > + return 0; > > + > > + if (upper->i_sb->s_op->write_inode) > > + ret = upper->i_sb->s_op->write_inode(inode, wbc); > > Where is page writeback on upper inode triggered? > Should pass upper inode instead of overlay inode here. Thanks, Chengguang
On Thu, 7 Oct 2021 at 14:28, Chengguang Xu <cgxu519@mykernel.net> wrote: > > ---- 在 星期四, 2021-10-07 17:23:06 Miklos Szeredi <miklos@szeredi.hu> 撰写 ---- > > On Thu, 23 Sept 2021 at 15:08, Chengguang Xu <cgxu519@mykernel.net> wrote: > > > > > > Implement overlayfs' ->write_inode to sync dirty data > > > and redirty overlayfs' inode if necessary. > > > > > > Signed-off-by: Chengguang Xu <cgxu519@mykernel.net> > > > --- > > > fs/overlayfs/super.c | 30 ++++++++++++++++++++++++++++++ > > > 1 file changed, 30 insertions(+) > > > > > > diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c > > > index 2ab77adf7256..cddae3ca2fa5 100644 > > > --- a/fs/overlayfs/super.c > > > +++ b/fs/overlayfs/super.c > > > @@ -412,12 +412,42 @@ static void ovl_evict_inode(struct inode *inode) > > > clear_inode(inode); > > > } > > > > > > +static int ovl_write_inode(struct inode *inode, > > > + struct writeback_control *wbc) > > > +{ > > > + struct ovl_fs *ofs = inode->i_sb->s_fs_info; > > > + struct inode *upper = ovl_inode_upper(inode); > > > + unsigned long iflag = 0; > > > + int ret = 0; > > > + > > > + if (!upper) > > > + return 0; > > > + > > > + if (!ovl_should_sync(ofs)) > > > + return 0; > > > + > > > + if (upper->i_sb->s_op->write_inode) > > > + ret = upper->i_sb->s_op->write_inode(inode, wbc); > > > > Where is page writeback on upper inode triggered? > > > > Should pass upper inode instead of overlay inode here. That's true and it does seem to indicate lack of thorough testing. However that wasn't what I was asking about. AFAICS ->write_inode() won't start write back for dirty pages. Maybe I'm missing something, but there it looks as if nothing will actually trigger writeback for dirty pages in upper inode. Thanks, Miklos
---- 在 星期四, 2021-10-07 20:45:20 Miklos Szeredi <miklos@szeredi.hu> 撰写 ---- > On Thu, 7 Oct 2021 at 14:28, Chengguang Xu <cgxu519@mykernel.net> wrote: > > > > ---- 在 星期四, 2021-10-07 17:23:06 Miklos Szeredi <miklos@szeredi.hu> 撰写 ---- > > > On Thu, 23 Sept 2021 at 15:08, Chengguang Xu <cgxu519@mykernel.net> wrote: > > > > > > > > Implement overlayfs' ->write_inode to sync dirty data > > > > and redirty overlayfs' inode if necessary. > > > > > > > > Signed-off-by: Chengguang Xu <cgxu519@mykernel.net> > > > > --- > > > > fs/overlayfs/super.c | 30 ++++++++++++++++++++++++++++++ > > > > 1 file changed, 30 insertions(+) > > > > > > > > diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c > > > > index 2ab77adf7256..cddae3ca2fa5 100644 > > > > --- a/fs/overlayfs/super.c > > > > +++ b/fs/overlayfs/super.c > > > > @@ -412,12 +412,42 @@ static void ovl_evict_inode(struct inode *inode) > > > > clear_inode(inode); > > > > } > > > > > > > > +static int ovl_write_inode(struct inode *inode, > > > > + struct writeback_control *wbc) > > > > +{ > > > > + struct ovl_fs *ofs = inode->i_sb->s_fs_info; > > > > + struct inode *upper = ovl_inode_upper(inode); > > > > + unsigned long iflag = 0; > > > > + int ret = 0; > > > > + > > > > + if (!upper) > > > > + return 0; > > > > + > > > > + if (!ovl_should_sync(ofs)) > > > > + return 0; > > > > + > > > > + if (upper->i_sb->s_op->write_inode) > > > > + ret = upper->i_sb->s_op->write_inode(inode, wbc); > > > > > > Where is page writeback on upper inode triggered? > > > > > > > Should pass upper inode instead of overlay inode here. > > That's true and it does seem to indicate lack of thorough testing. It's a little bit weird this passed all overlay cases and generic/474(syncfs) without errors in xfstests. Please let me do more diagnosis on this and strengthen the test case. > > However that wasn't what I was asking about. AFAICS ->write_inode() > won't start write back for dirty pages. Maybe I'm missing something, > but there it looks as if nothing will actually trigger writeback for > dirty pages in upper inode. > Actually, page writeback on upper inode will be triggered by overlayfs ->writepages and overlayfs' ->writepages will be called by vfs writeback function (i.e writeback_sb_inodes). Thanks, Chengguang
On Thu, 7 Oct 2021 at 15:10, Chengguang Xu <cgxu519@mykernel.net> wrote: > > However that wasn't what I was asking about. AFAICS ->write_inode() > > won't start write back for dirty pages. Maybe I'm missing something, > > but there it looks as if nothing will actually trigger writeback for > > dirty pages in upper inode. > > > > Actually, page writeback on upper inode will be triggered by overlayfs ->writepages and > overlayfs' ->writepages will be called by vfs writeback function (i.e writeback_sb_inodes). Right. But wouldn't it be simpler to do this from ->write_inode()? I.e. call write_inode_now() as suggested by Jan. Also could just call mark_inode_dirty() on the overlay inode regardless of the dirty flags on the upper inode since it shouldn't matter and results in simpler logic. Thanks, Miklos > > Thanks, > Chengguang > > >
On Thu 07-10-21 20:26:36, Chengguang Xu wrote: > ---- 在 星期四, 2021-10-07 17:01:57 Jan Kara <jack@suse.cz> 撰写 ---- > > > > > + if (mapping_writably_mapped(upper->i_mapping) || > > > + mapping_tagged(upper->i_mapping, PAGECACHE_TAG_WRITEBACK)) > > > + iflag |= I_DIRTY_PAGES; > > > + > > > + iflag |= upper->i_state & I_DIRTY_ALL; > > > > Also since you call ->write_inode directly upper->i_state won't be updated > > to reflect that inode has been written out (I_DIRTY flags get cleared in > > __writeback_single_inode()). So it seems to me overlayfs will keep writing > > out upper inode until flush worker on upper filesystem also writes the > > inode and clears the dirty flags? So you rather need to call something like > > write_inode_now() that will handle the flag clearing and do writeback list > > handling for you? > > > > Calling ->write_inode directly upper->i_state won't be updated, however, > I don't think overlayfs will keep writing out upper inode since > ->write_inode will be called when only overlay inode itself marked dirty. > Am I missing something? Well, if upper->i_state is not updated, you are more or less guaranteed upper->i_state & I_DIRTY_ALL != 0 and thus even overlay inode stays dirty. And thus next time writeback runs you will see dirty overlay inode and writeback the upper inode again although it is not necessary. Honza
On Thu 07-10-21 15:34:19, Miklos Szeredi wrote: > On Thu, 7 Oct 2021 at 15:10, Chengguang Xu <cgxu519@mykernel.net> wrote: > > > However that wasn't what I was asking about. AFAICS ->write_inode() > > > won't start write back for dirty pages. Maybe I'm missing something, > > > but there it looks as if nothing will actually trigger writeback for > > > dirty pages in upper inode. > > > > > > > Actually, page writeback on upper inode will be triggered by overlayfs ->writepages and > > overlayfs' ->writepages will be called by vfs writeback function (i.e writeback_sb_inodes). > > Right. > > But wouldn't it be simpler to do this from ->write_inode()? You could but then you'd have to make sure you have I_DIRTY_SYNC always set when I_DIRTY_PAGES is set on the upper inode so that your ->write_inode() callback gets called. Overall I agree the logic would be probably simpler. Honza
---- 在 星期四, 2021-10-07 22:46:46 Jan Kara <jack@suse.cz> 撰写 ---- > On Thu 07-10-21 15:34:19, Miklos Szeredi wrote: > > On Thu, 7 Oct 2021 at 15:10, Chengguang Xu <cgxu519@mykernel.net> wrote: > > > > However that wasn't what I was asking about. AFAICS ->write_inode() > > > > won't start write back for dirty pages. Maybe I'm missing something, > > > > but there it looks as if nothing will actually trigger writeback for > > > > dirty pages in upper inode. > > > > > > > > > > Actually, page writeback on upper inode will be triggered by overlayfs ->writepages and > > > overlayfs' ->writepages will be called by vfs writeback function (i.e writeback_sb_inodes). > > > > Right. > > > > But wouldn't it be simpler to do this from ->write_inode()? > > You could but then you'd have to make sure you have I_DIRTY_SYNC always set > when I_DIRTY_PAGES is set on the upper inode so that your ->write_inode() > callback gets called. Overall I agree the logic would be probably simpler. > Hi Jan, Miklos Thnaks for your suggestions. Let me have a try in next version. Thanks, Chengguang
---- 在 星期四, 2021-10-07 22:41:56 Jan Kara <jack@suse.cz> 撰写 ---- > On Thu 07-10-21 20:26:36, Chengguang Xu wrote: > > ---- 在 星期四, 2021-10-07 17:01:57 Jan Kara <jack@suse.cz> 撰写 ---- > > > > > > > + if (mapping_writably_mapped(upper->i_mapping) || > > > > + mapping_tagged(upper->i_mapping, PAGECACHE_TAG_WRITEBACK)) > > > > + iflag |= I_DIRTY_PAGES; > > > > + > > > > + iflag |= upper->i_state & I_DIRTY_ALL; > > > > > > Also since you call ->write_inode directly upper->i_state won't be updated > > > to reflect that inode has been written out (I_DIRTY flags get cleared in > > > __writeback_single_inode()). So it seems to me overlayfs will keep writing > > > out upper inode until flush worker on upper filesystem also writes the > > > inode and clears the dirty flags? So you rather need to call something like > > > write_inode_now() that will handle the flag clearing and do writeback list > > > handling for you? > > > > > > > Calling ->write_inode directly upper->i_state won't be updated, however, > > I don't think overlayfs will keep writing out upper inode since > > ->write_inode will be called when only overlay inode itself marked dirty. > > Am I missing something? > > Well, if upper->i_state is not updated, you are more or less guaranteed > upper->i_state & I_DIRTY_ALL != 0 and thus even overlay inode stays dirty. > And thus next time writeback runs you will see dirty overlay inode and > writeback the upper inode again although it is not necessary. > Hi Jan, Yes, I get the point now. Thanks for the explanation. Thanks, Chengguang
On Thu, 7 Oct 2021 at 16:53, Chengguang Xu <cgxu519@mykernel.net> wrote: > > ---- 在 星期四, 2021-10-07 22:46:46 Jan Kara <jack@suse.cz> 撰写 ---- > > On Thu 07-10-21 15:34:19, Miklos Szeredi wrote: > > > On Thu, 7 Oct 2021 at 15:10, Chengguang Xu <cgxu519@mykernel.net> wrote: > > > > > However that wasn't what I was asking about. AFAICS ->write_inode() > > > > > won't start write back for dirty pages. Maybe I'm missing something, > > > > > but there it looks as if nothing will actually trigger writeback for > > > > > dirty pages in upper inode. > > > > > > > > > > > > > Actually, page writeback on upper inode will be triggered by overlayfs ->writepages and > > > > overlayfs' ->writepages will be called by vfs writeback function (i.e writeback_sb_inodes). > > > > > > Right. > > > > > > But wouldn't it be simpler to do this from ->write_inode()? > > > > You could but then you'd have to make sure you have I_DIRTY_SYNC always set > > when I_DIRTY_PAGES is set on the upper inode so that your ->write_inode() > > callback gets called. Overall I agree the logic would be probably simpler. > > > And it's not just for simplicity. The I_SYNC logic in writeback_single_inode() is actually necessary to prevent races between instances on a specific inode. I.e. if inode writeback is started by background wb then syncfs needs to synchronize with that otherwise it will miss the inode, or worse, mess things up by calling ->write_inode() multiple times in parallel. So going throught writeback_single_inode() is actually a must AFAICS. Thanks, Miklos
On Thu 07-10-21 20:51:47, Miklos Szeredi wrote: > On Thu, 7 Oct 2021 at 16:53, Chengguang Xu <cgxu519@mykernel.net> wrote: > > > > ---- 在 星期四, 2021-10-07 22:46:46 Jan Kara <jack@suse.cz> 撰写 ---- > > > On Thu 07-10-21 15:34:19, Miklos Szeredi wrote: > > > > On Thu, 7 Oct 2021 at 15:10, Chengguang Xu <cgxu519@mykernel.net> wrote: > > > > > > However that wasn't what I was asking about. AFAICS ->write_inode() > > > > > > won't start write back for dirty pages. Maybe I'm missing something, > > > > > > but there it looks as if nothing will actually trigger writeback for > > > > > > dirty pages in upper inode. > > > > > > > > > > > > > > > > Actually, page writeback on upper inode will be triggered by overlayfs ->writepages and > > > > > overlayfs' ->writepages will be called by vfs writeback function (i.e writeback_sb_inodes). > > > > > > > > Right. > > > > > > > > But wouldn't it be simpler to do this from ->write_inode()? > > > > > > You could but then you'd have to make sure you have I_DIRTY_SYNC always set > > > when I_DIRTY_PAGES is set on the upper inode so that your ->write_inode() > > > callback gets called. Overall I agree the logic would be probably simpler. > > > > > > > And it's not just for simplicity. The I_SYNC logic in > writeback_single_inode() is actually necessary to prevent races > between instances on a specific inode. I.e. if inode writeback is > started by background wb then syncfs needs to synchronize with that > otherwise it will miss the inode, or worse, mess things up by calling > ->write_inode() multiple times in parallel. So going throught > writeback_single_inode() is actually a must AFAICS. Yes, you are correct. Honza
---- 在 星期四, 2021-10-07 21:34:19 Miklos Szeredi <miklos@szeredi.hu> 撰写 ---- > On Thu, 7 Oct 2021 at 15:10, Chengguang Xu <cgxu519@mykernel.net> wrote: > > > However that wasn't what I was asking about. AFAICS ->write_inode() > > > won't start write back for dirty pages. Maybe I'm missing something, > > > but there it looks as if nothing will actually trigger writeback for > > > dirty pages in upper inode. > > > > > > > Actually, page writeback on upper inode will be triggered by overlayfs ->writepages and > > overlayfs' ->writepages will be called by vfs writeback function (i.e writeback_sb_inodes). > > Right. > > But wouldn't it be simpler to do this from ->write_inode()? > > I.e. call write_inode_now() as suggested by Jan. > > Also could just call mark_inode_dirty() on the overlay inode > regardless of the dirty flags on the upper inode since it shouldn't > matter and results in simpler logic. > Hi Miklos， Sorry for delayed response for this, I've been busy with another project. I agree with your suggesion above and further more how about just mark overlay inode dirty when it has upper inode? This approach will make marking dirtiness simple enough. Thanks, Chengguang
On Tue, 16 Nov 2021 at 03:20, Chengguang Xu <cgxu519@mykernel.net> wrote: > > ---- 在 星期四, 2021-10-07 21:34:19 Miklos Szeredi <miklos@szeredi.hu> 撰写 ---- > > On Thu, 7 Oct 2021 at 15:10, Chengguang Xu <cgxu519@mykernel.net> wrote: > > > > However that wasn't what I was asking about. AFAICS ->write_inode() > > > > won't start write back for dirty pages. Maybe I'm missing something, > > > > but there it looks as if nothing will actually trigger writeback for > > > > dirty pages in upper inode. > > > > > > > > > > Actually, page writeback on upper inode will be triggered by overlayfs ->writepages and > > > overlayfs' ->writepages will be called by vfs writeback function (i.e writeback_sb_inodes). > > > > Right. > > > > But wouldn't it be simpler to do this from ->write_inode()? > > > > I.e. call write_inode_now() as suggested by Jan. > > > > Also could just call mark_inode_dirty() on the overlay inode > > regardless of the dirty flags on the upper inode since it shouldn't > > matter and results in simpler logic. > > > > Hi Miklos， > > Sorry for delayed response for this, I've been busy with another project. > > I agree with your suggesion above and further more how about just mark overlay inode dirty > when it has upper inode? This approach will make marking dirtiness simple enough. Are you suggesting that all non-lower overlay inodes should always be dirty? The logic would be simple, no doubt, but there's the cost to walking those overlay inodes which don't have a dirty upper inode, right? Can you quantify this cost with a benchmark? Can be totally synthetic, e.g. lookup a million upper files without modifying them, then call syncfs. Thanks, Miklos
---- 在 星期二, 2021-11-16 20:35:55 Miklos Szeredi <miklos@szeredi.hu> 撰写 ---- > On Tue, 16 Nov 2021 at 03:20, Chengguang Xu <cgxu519@mykernel.net> wrote: > > > > ---- 在 星期四, 2021-10-07 21:34:19 Miklos Szeredi <miklos@szeredi.hu> 撰写 ---- > > > On Thu, 7 Oct 2021 at 15:10, Chengguang Xu <cgxu519@mykernel.net> wrote: > > > > > However that wasn't what I was asking about. AFAICS ->write_inode() > > > > > won't start write back for dirty pages. Maybe I'm missing something, > > > > > but there it looks as if nothing will actually trigger writeback for > > > > > dirty pages in upper inode. > > > > > > > > > > > > > Actually, page writeback on upper inode will be triggered by overlayfs ->writepages and > > > > overlayfs' ->writepages will be called by vfs writeback function (i.e writeback_sb_inodes). > > > > > > Right. > > > > > > But wouldn't it be simpler to do this from ->write_inode()? > > > > > > I.e. call write_inode_now() as suggested by Jan. > > > > > > Also could just call mark_inode_dirty() on the overlay inode > > > regardless of the dirty flags on the upper inode since it shouldn't > > > matter and results in simpler logic. > > > > > > > Hi Miklos， > > > > Sorry for delayed response for this, I've been busy with another project. > > > > I agree with your suggesion above and further more how about just mark overlay inode dirty > > when it has upper inode? This approach will make marking dirtiness simple enough. > > Are you suggesting that all non-lower overlay inodes should always be dirty? > > The logic would be simple, no doubt, but there's the cost to walking > those overlay inodes which don't have a dirty upper inode, right? That's true. > Can you quantify this cost with a benchmark? Can be totally synthetic, > e.g. lookup a million upper files without modifying them, then call > syncfs. > No problem, I'll do some tests for the performance. Thanks, Chengguang
---- 在 星期三, 2021-11-17 14:11:29 Chengguang Xu <cgxu519@mykernel.net> 撰写 ---- > ---- 在 星期二, 2021-11-16 20:35:55 Miklos Szeredi <miklos@szeredi.hu> 撰写 ---- > > On Tue, 16 Nov 2021 at 03:20, Chengguang Xu <cgxu519@mykernel.net> wrote: > > > > > > ---- 在 星期四, 2021-10-07 21:34:19 Miklos Szeredi <miklos@szeredi.hu> 撰写 ---- > > > > On Thu, 7 Oct 2021 at 15:10, Chengguang Xu <cgxu519@mykernel.net> wrote: > > > > > > However that wasn't what I was asking about. AFAICS ->write_inode() > > > > > > won't start write back for dirty pages. Maybe I'm missing something, > > > > > > but there it looks as if nothing will actually trigger writeback for > > > > > > dirty pages in upper inode. > > > > > > > > > > > > > > > > Actually, page writeback on upper inode will be triggered by overlayfs ->writepages and > > > > > overlayfs' ->writepages will be called by vfs writeback function (i.e writeback_sb_inodes). > > > > > > > > Right. > > > > > > > > But wouldn't it be simpler to do this from ->write_inode()? > > > > > > > > I.e. call write_inode_now() as suggested by Jan. > > > > > > > > Also could just call mark_inode_dirty() on the overlay inode > > > > regardless of the dirty flags on the upper inode since it shouldn't > > > > matter and results in simpler logic. > > > > > > > > > > Hi Miklos， > > > > > > Sorry for delayed response for this, I've been busy with another project. > > > > > > I agree with your suggesion above and further more how about just mark overlay inode dirty > > > when it has upper inode? This approach will make marking dirtiness simple enough. > > > > Are you suggesting that all non-lower overlay inodes should always be dirty? > > > > The logic would be simple, no doubt, but there's the cost to walking > > those overlay inodes which don't have a dirty upper inode, right? > > That's true. > > > Can you quantify this cost with a benchmark? Can be totally synthetic, > > e.g. lookup a million upper files without modifying them, then call > > syncfs. > > > > No problem, I'll do some tests for the performance. > Hi Miklos, I did some rough tests and the results like below. In practice, I don't think that 1.3s extra time of syncfs will cause significant problem. What do you think? Test bed: kvm vm 2.50GHz cpu 32core 64GB mem vm kernel 5.15.0-rc1+ (with ovl syncfs patch V6) one millon files spread to 2 level of dir hierarchy. test step: 1) create testfiles in ovl upper dir 2) mount overlayfs 3) excute ls -lR to lookup all file in overlay merge dir 4) excute slabtop to make sure overlay inode number 5) call syncfs to the file in merge dir Tested five times and the reusults are in 1.310s ~ 1.326s root@VM-144-4-centos test]# time ./syncfs ovl-merge/create-file.sh syncfs success real 0m1.310s user 0m0.000s sys 0m0.001s [root@VM-144-4-centos test]# time ./syncfs ovl-merge/create-file.sh syncfs success real 0m1.326s user 0m0.001s sys 0m0.000s [root@VM-144-4-centos test]# time ./syncfs ovl-merge/create-file.sh syncfs success real 0m1.321s user 0m0.000s sys 0m0.001s [root@VM-144-4-centos test]# time ./syncfs ovl-merge/create-file.sh syncfs success real 0m1.316s user 0m0.000s sys 0m0.001s [root@VM-144-4-centos test]# time ./syncfs ovl-merge/create-file.sh syncfs success real 0m1.314s user 0m0.001s sys 0m0.001s Directly run syncfs to the file in ovl-upper dir. Tested five times and the reusults are in 0.001s ~ 0.003s [root@VM-144-4-centos test]# time ./syncfs a syncfs success real 0m0.002s user 0m0.001s sys 0m0.000s [root@VM-144-4-centos test]# time ./syncfs ovl-upper/create-file.sh syncfs success real 0m0.003s user 0m0.001s sys 0m0.000s [root@VM-144-4-centos test]# time ./syncfs ovl-upper/create-file.sh syncfs success real 0m0.001s user 0m0.000s sys 0m0.001s [root@VM-144-4-centos test]# time ./syncfs ovl-upper/create-file.sh syncfs success real 0m0.001s user 0m0.000s sys 0m0.001s [root@VM-144-4-centos test]# time ./syncfs ovl-upper/create-file.sh syncfs success real 0m0.001s user 0m0.000s sys 0m0.001s [root@VM-144-4-centos test]# time ./syncfs ovl-upper/create-file.sh syncfs success real 0m0.001s user 0m0.000s sys 0m0.001
On Thu 18-11-21 14:32:36, Chengguang Xu wrote: > > ---- 在 星期三, 2021-11-17 14:11:29 Chengguang Xu <cgxu519@mykernel.net> 撰写 ---- > > ---- 在 星期二, 2021-11-16 20:35:55 Miklos Szeredi <miklos@szeredi.hu> 撰写 ---- > > > On Tue, 16 Nov 2021 at 03:20, Chengguang Xu <cgxu519@mykernel.net> wrote: > > > > > > > > ---- 在 星期四, 2021-10-07 21:34:19 Miklos Szeredi <miklos@szeredi.hu> 撰写 ---- > > > > > On Thu, 7 Oct 2021 at 15:10, Chengguang Xu <cgxu519@mykernel.net> wrote: > > > > > > > However that wasn't what I was asking about. AFAICS ->write_inode() > > > > > > > won't start write back for dirty pages. Maybe I'm missing something, > > > > > > > but there it looks as if nothing will actually trigger writeback for > > > > > > > dirty pages in upper inode. > > > > > > > > > > > > > > > > > > > Actually, page writeback on upper inode will be triggered by overlayfs ->writepages and > > > > > > overlayfs' ->writepages will be called by vfs writeback function (i.e writeback_sb_inodes). > > > > > > > > > > Right. > > > > > > > > > > But wouldn't it be simpler to do this from ->write_inode()? > > > > > > > > > > I.e. call write_inode_now() as suggested by Jan. > > > > > > > > > > Also could just call mark_inode_dirty() on the overlay inode > > > > > regardless of the dirty flags on the upper inode since it shouldn't > > > > > matter and results in simpler logic. > > > > > > > > > > > > > Hi Miklos， > > > > > > > > Sorry for delayed response for this, I've been busy with another project. > > > > > > > > I agree with your suggesion above and further more how about just mark overlay inode dirty > > > > when it has upper inode? This approach will make marking dirtiness simple enough. > > > > > > Are you suggesting that all non-lower overlay inodes should always be dirty? > > > > > > The logic would be simple, no doubt, but there's the cost to walking > > > those overlay inodes which don't have a dirty upper inode, right? > > > > That's true. > > > > > Can you quantify this cost with a benchmark? Can be totally synthetic, > > > e.g. lookup a million upper files without modifying them, then call > > > syncfs. > > > > > > > No problem, I'll do some tests for the performance. > > > > Hi Miklos, > > I did some rough tests and the results like below. In practice, I don't > think that 1.3s extra time of syncfs will cause significant problem. > What do you think? Well, burning 1.3s worth of CPU time for doing nothing seems like quite a bit to me. I understand this is with 1000000 inodes but although that is quite a few it is not unheard of. If there would be several containers calling sync_fs(2) on the machine they could easily hog the machine... That is why I was originally against keeping overlay inodes always dirty and wanted their dirtiness to at least roughly track the real need to do writeback. Honza > Test bed: kvm vm > 2.50GHz cpu 32core > 64GB mem > vm kernel 5.15.0-rc1+ (with ovl syncfs patch V6) > > one millon files spread to 2 level of dir hierarchy. > test step: > 1) create testfiles in ovl upper dir > 2) mount overlayfs > 3) excute ls -lR to lookup all file in overlay merge dir > 4) excute slabtop to make sure overlay inode number > 5) call syncfs to the file in merge dir > > Tested five times and the reusults are in 1.310s ~ 1.326s > > root@VM-144-4-centos test]# time ./syncfs ovl-merge/create-file.sh > syncfs success > > real 0m1.310s > user 0m0.000s > sys 0m0.001s > [root@VM-144-4-centos test]# time ./syncfs ovl-merge/create-file.sh > syncfs success > > real 0m1.326s > user 0m0.001s > sys 0m0.000s > [root@VM-144-4-centos test]# time ./syncfs ovl-merge/create-file.sh > syncfs success > > real 0m1.321s > user 0m0.000s > sys 0m0.001s > [root@VM-144-4-centos test]# time ./syncfs ovl-merge/create-file.sh > syncfs success > > real 0m1.316s > user 0m0.000s > sys 0m0.001s > [root@VM-144-4-centos test]# time ./syncfs ovl-merge/create-file.sh > syncfs success > > real 0m1.314s > user 0m0.001s > sys 0m0.001s > > > Directly run syncfs to the file in ovl-upper dir. > Tested five times and the reusults are in 0.001s ~ 0.003s > > [root@VM-144-4-centos test]# time ./syncfs a > syncfs success > > real 0m0.002s > user 0m0.001s > sys 0m0.000s > [root@VM-144-4-centos test]# time ./syncfs ovl-upper/create-file.sh > syncfs success > > real 0m0.003s > user 0m0.001s > sys 0m0.000s > [root@VM-144-4-centos test]# time ./syncfs ovl-upper/create-file.sh > syncfs success > > real 0m0.001s > user 0m0.000s > sys 0m0.001s > [root@VM-144-4-centos test]# time ./syncfs ovl-upper/create-file.sh > syncfs success > > real 0m0.001s > user 0m0.000s > sys 0m0.001s > [root@VM-144-4-centos test]# time ./syncfs ovl-upper/create-file.sh > syncfs success > > real 0m0.001s > user 0m0.000s > sys 0m0.001s > [root@VM-144-4-centos test]# time ./syncfs ovl-upper/create-file.sh > syncfs success > > real 0m0.001s > user 0m0.000s > sys 0m0.001 > > > > > >
---- 在 星期四, 2021-11-18 19:23:15 Jan Kara <jack@suse.cz> 撰写 ---- > On Thu 18-11-21 14:32:36, Chengguang Xu wrote: > > > > ---- 在 星期三, 2021-11-17 14:11:29 Chengguang Xu <cgxu519@mykernel.net> 撰写 ---- > > > ---- 在 星期二, 2021-11-16 20:35:55 Miklos Szeredi <miklos@szeredi.hu> 撰写 ---- > > > > On Tue, 16 Nov 2021 at 03:20, Chengguang Xu <cgxu519@mykernel.net> wrote: > > > > > > > > > > ---- 在 星期四, 2021-10-07 21:34:19 Miklos Szeredi <miklos@szeredi.hu> 撰写 ---- > > > > > > On Thu, 7 Oct 2021 at 15:10, Chengguang Xu <cgxu519@mykernel.net> wrote: > > > > > > > > However that wasn't what I was asking about. AFAICS ->write_inode() > > > > > > > > won't start write back for dirty pages. Maybe I'm missing something, > > > > > > > > but there it looks as if nothing will actually trigger writeback for > > > > > > > > dirty pages in upper inode. > > > > > > > > > > > > > > > > > > > > > > Actually, page writeback on upper inode will be triggered by overlayfs ->writepages and > > > > > > > overlayfs' ->writepages will be called by vfs writeback function (i.e writeback_sb_inodes). > > > > > > > > > > > > Right. > > > > > > > > > > > > But wouldn't it be simpler to do this from ->write_inode()? > > > > > > > > > > > > I.e. call write_inode_now() as suggested by Jan. > > > > > > > > > > > > Also could just call mark_inode_dirty() on the overlay inode > > > > > > regardless of the dirty flags on the upper inode since it shouldn't > > > > > > matter and results in simpler logic. > > > > > > > > > > > > > > > > Hi Miklos， > > > > > > > > > > Sorry for delayed response for this, I've been busy with another project. > > > > > > > > > > I agree with your suggesion above and further more how about just mark overlay inode dirty > > > > > when it has upper inode? This approach will make marking dirtiness simple enough. > > > > > > > > Are you suggesting that all non-lower overlay inodes should always be dirty? > > > > > > > > The logic would be simple, no doubt, but there's the cost to walking > > > > those overlay inodes which don't have a dirty upper inode, right? > > > > > > That's true. > > > > > > > Can you quantify this cost with a benchmark? Can be totally synthetic, > > > > e.g. lookup a million upper files without modifying them, then call > > > > syncfs. > > > > > > > > > > No problem, I'll do some tests for the performance. > > > > > > > Hi Miklos, > > > > I did some rough tests and the results like below. In practice, I don't > > think that 1.3s extra time of syncfs will cause significant problem. > > What do you think? > > Well, burning 1.3s worth of CPU time for doing nothing seems like quite a > bit to me. I understand this is with 1000000 inodes but although that is > quite a few it is not unheard of. If there would be several containers > calling sync_fs(2) on the machine they could easily hog the machine... That > is why I was originally against keeping overlay inodes always dirty and > wanted their dirtiness to at least roughly track the real need to do > writeback. > Hi Jan, Actually, the time on user and sys are almost same with directly excute syncfs on underlying fs. IMO, it only extends syncfs(2) waiting time for perticular container but not burning cpu. What am I missing? Thanks, Chengguang > > > Test bed: kvm vm > > 2.50GHz cpu 32core > > 64GB mem > > vm kernel 5.15.0-rc1+ (with ovl syncfs patch V6) > > > > one millon files spread to 2 level of dir hierarchy. > > test step: > > 1) create testfiles in ovl upper dir > > 2) mount overlayfs > > 3) excute ls -lR to lookup all file in overlay merge dir > > 4) excute slabtop to make sure overlay inode number > > 5) call syncfs to the file in merge dir > > > > Tested five times and the reusults are in 1.310s ~ 1.326s > > > > root@VM-144-4-centos test]# time ./syncfs ovl-merge/create-file.sh > > syncfs success > > > > real 0m1.310s > > user 0m0.000s > > sys 0m0.001s > > [root@VM-144-4-centos test]# time ./syncfs ovl-merge/create-file.sh > > syncfs success > > > > real 0m1.326s > > user 0m0.001s > > sys 0m0.000s > > [root@VM-144-4-centos test]# time ./syncfs ovl-merge/create-file.sh > > syncfs success > > > > real 0m1.321s > > user 0m0.000s > > sys 0m0.001s > > [root@VM-144-4-centos test]# time ./syncfs ovl-merge/create-file.sh > > syncfs success > > > > real 0m1.316s > > user 0m0.000s > > sys 0m0.001s > > [root@VM-144-4-centos test]# time ./syncfs ovl-merge/create-file.sh > > syncfs success > > > > real 0m1.314s > > user 0m0.001s > > sys 0m0.001s > > > > > > Directly run syncfs to the file in ovl-upper dir. > > Tested five times and the reusults are in 0.001s ~ 0.003s > > > > [root@VM-144-4-centos test]# time ./syncfs a > > syncfs success > > > > real 0m0.002s > > user 0m0.001s > > sys 0m0.000s > > [root@VM-144-4-centos test]# time ./syncfs ovl-upper/create-file.sh > > syncfs success > > > > real 0m0.003s > > user 0m0.001s > > sys 0m0.000s > > [root@VM-144-4-centos test]# time ./syncfs ovl-upper/create-file.sh > > syncfs success > > > > real 0m0.001s > > user 0m0.000s > > sys 0m0.001s > > [root@VM-144-4-centos test]# time ./syncfs ovl-upper/create-file.sh > > syncfs success > > > > real 0m0.001s > > user 0m0.000s > > sys 0m0.001s > > [root@VM-144-4-centos test]# time ./syncfs ovl-upper/create-file.sh > > syncfs success > > > > real 0m0.001s > > user 0m0.000s > > sys 0m0.001s > > [root@VM-144-4-centos test]# time ./syncfs ovl-upper/create-file.sh > > syncfs success > > > > real 0m0.001s > > user 0m0.000s > > sys 0m0.001 > > > > > > > > > > > > > -- > Jan Kara <jack@suse.com> > SUSE Labs, CR >
On Thu 18-11-21 20:02:09, Chengguang Xu wrote: > ---- 在 星期四, 2021-11-18 19:23:15 Jan Kara <jack@suse.cz> 撰写 ---- > > On Thu 18-11-21 14:32:36, Chengguang Xu wrote: > > > > > > ---- 在 星期三, 2021-11-17 14:11:29 Chengguang Xu <cgxu519@mykernel.net> 撰写 ---- > > > > ---- 在 星期二, 2021-11-16 20:35:55 Miklos Szeredi <miklos@szeredi.hu> 撰写 ---- > > > > > On Tue, 16 Nov 2021 at 03:20, Chengguang Xu <cgxu519@mykernel.net> wrote: > > > > > > > > > > > > ---- 在 星期四, 2021-10-07 21:34:19 Miklos Szeredi <miklos@szeredi.hu> 撰写 ---- > > > > > > > On Thu, 7 Oct 2021 at 15:10, Chengguang Xu <cgxu519@mykernel.net> wrote: > > > > > > > > > However that wasn't what I was asking about. AFAICS ->write_inode() > > > > > > > > > won't start write back for dirty pages. Maybe I'm missing something, > > > > > > > > > but there it looks as if nothing will actually trigger writeback for > > > > > > > > > dirty pages in upper inode. > > > > > > > > > > > > > > > > > > > > > > > > > Actually, page writeback on upper inode will be triggered by overlayfs ->writepages and > > > > > > > > overlayfs' ->writepages will be called by vfs writeback function (i.e writeback_sb_inodes). > > > > > > > > > > > > > > Right. > > > > > > > > > > > > > > But wouldn't it be simpler to do this from ->write_inode()? > > > > > > > > > > > > > > I.e. call write_inode_now() as suggested by Jan. > > > > > > > > > > > > > > Also could just call mark_inode_dirty() on the overlay inode > > > > > > > regardless of the dirty flags on the upper inode since it shouldn't > > > > > > > matter and results in simpler logic. > > > > > > > > > > > > > > > > > > > Hi Miklos， > > > > > > > > > > > > Sorry for delayed response for this, I've been busy with another project. > > > > > > > > > > > > I agree with your suggesion above and further more how about just mark overlay inode dirty > > > > > > when it has upper inode? This approach will make marking dirtiness simple enough. > > > > > > > > > > Are you suggesting that all non-lower overlay inodes should always be dirty? > > > > > > > > > > The logic would be simple, no doubt, but there's the cost to walking > > > > > those overlay inodes which don't have a dirty upper inode, right? > > > > > > > > That's true. > > > > > > > > > Can you quantify this cost with a benchmark? Can be totally synthetic, > > > > > e.g. lookup a million upper files without modifying them, then call > > > > > syncfs. > > > > > > > > > > > > > No problem, I'll do some tests for the performance. > > > > > > > > > > Hi Miklos, > > > > > > I did some rough tests and the results like below. In practice, I don't > > > think that 1.3s extra time of syncfs will cause significant problem. > > > What do you think? > > > > Well, burning 1.3s worth of CPU time for doing nothing seems like quite a > > bit to me. I understand this is with 1000000 inodes but although that is > > quite a few it is not unheard of. If there would be several containers > > calling sync_fs(2) on the machine they could easily hog the machine... That > > is why I was originally against keeping overlay inodes always dirty and > > wanted their dirtiness to at least roughly track the real need to do > > writeback. > > > > Hi Jan, > > Actually, the time on user and sys are almost same with directly excute syncfs on underlying fs. > IMO, it only extends syncfs(2) waiting time for perticular container but not burning cpu. > What am I missing? Ah, right, I've missed that only realtime changed, not systime. I'm sorry for confusion. But why did the realtime increase so much? Are we waiting for some IO? Honza > > > Test bed: kvm vm > > > 2.50GHz cpu 32core > > > 64GB mem > > > vm kernel 5.15.0-rc1+ (with ovl syncfs patch V6) > > > > > > one millon files spread to 2 level of dir hierarchy. > > > test step: > > > 1) create testfiles in ovl upper dir > > > 2) mount overlayfs > > > 3) excute ls -lR to lookup all file in overlay merge dir > > > 4) excute slabtop to make sure overlay inode number > > > 5) call syncfs to the file in merge dir > > > > > > Tested five times and the reusults are in 1.310s ~ 1.326s > > > > > > root@VM-144-4-centos test]# time ./syncfs ovl-merge/create-file.sh > > > syncfs success > > > > > > real 0m1.310s > > > user 0m0.000s > > > sys 0m0.001s > > > [root@VM-144-4-centos test]# time ./syncfs ovl-merge/create-file.sh > > > syncfs success > > > > > > real 0m1.326s > > > user 0m0.001s > > > sys 0m0.000s > > > [root@VM-144-4-centos test]# time ./syncfs ovl-merge/create-file.sh > > > syncfs success > > > > > > real 0m1.321s > > > user 0m0.000s > > > sys 0m0.001s > > > [root@VM-144-4-centos test]# time ./syncfs ovl-merge/create-file.sh > > > syncfs success > > > > > > real 0m1.316s > > > user 0m0.000s > > > sys 0m0.001s > > > [root@VM-144-4-centos test]# time ./syncfs ovl-merge/create-file.sh > > > syncfs success > > > > > > real 0m1.314s > > > user 0m0.001s > > > sys 0m0.001s > > > > > > > > > Directly run syncfs to the file in ovl-upper dir. > > > Tested five times and the reusults are in 0.001s ~ 0.003s > > > > > > [root@VM-144-4-centos test]# time ./syncfs a > > > syncfs success > > > > > > real 0m0.002s > > > user 0m0.001s > > > sys 0m0.000s > > > [root@VM-144-4-centos test]# time ./syncfs ovl-upper/create-file.sh > > > syncfs success > > > > > > real 0m0.003s > > > user 0m0.001s > > > sys 0m0.000s > > > [root@VM-144-4-centos test]# time ./syncfs ovl-upper/create-file.sh > > > syncfs success > > > > > > real 0m0.001s > > > user 0m0.000s > > > sys 0m0.001s > > > [root@VM-144-4-centos test]# time ./syncfs ovl-upper/create-file.sh > > > syncfs success > > > > > > real 0m0.001s > > > user 0m0.000s > > > sys 0m0.001s > > > [root@VM-144-4-centos test]# time ./syncfs ovl-upper/create-file.sh > > > syncfs success > > > > > > real 0m0.001s > > > user 0m0.000s > > > sys 0m0.001s > > > [root@VM-144-4-centos test]# time ./syncfs ovl-upper/create-file.sh > > > syncfs success > > > > > > real 0m0.001s > > > user 0m0.000s > > > sys 0m0.001 > > > > > > > > > > > > > > > > > > > > -- > > Jan Kara <jack@suse.com> > > SUSE Labs, CR > >
---- 在 星期五, 2021-11-19 00:43:49 Jan Kara <jack@suse.cz> 撰写 ---- > On Thu 18-11-21 20:02:09, Chengguang Xu wrote: > > ---- 在 星期四, 2021-11-18 19:23:15 Jan Kara <jack@suse.cz> 撰写 ---- > > > On Thu 18-11-21 14:32:36, Chengguang Xu wrote: > > > > > > > > ---- 在 星期三, 2021-11-17 14:11:29 Chengguang Xu <cgxu519@mykernel.net> 撰写 ---- > > > > > ---- 在 星期二, 2021-11-16 20:35:55 Miklos Szeredi <miklos@szeredi.hu> 撰写 ---- > > > > > > On Tue, 16 Nov 2021 at 03:20, Chengguang Xu <cgxu519@mykernel.net> wrote: > > > > > > > > > > > > > > ---- 在 星期四, 2021-10-07 21:34:19 Miklos Szeredi <miklos@szeredi.hu> 撰写 ---- > > > > > > > > On Thu, 7 Oct 2021 at 15:10, Chengguang Xu <cgxu519@mykernel.net> wrote: > > > > > > > > > > However that wasn't what I was asking about. AFAICS ->write_inode() > > > > > > > > > > won't start write back for dirty pages. Maybe I'm missing something, > > > > > > > > > > but there it looks as if nothing will actually trigger writeback for > > > > > > > > > > dirty pages in upper inode. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Actually, page writeback on upper inode will be triggered by overlayfs ->writepages and > > > > > > > > > overlayfs' ->writepages will be called by vfs writeback function (i.e writeback_sb_inodes). > > > > > > > > > > > > > > > > Right. > > > > > > > > > > > > > > > > But wouldn't it be simpler to do this from ->write_inode()? > > > > > > > > > > > > > > > > I.e. call write_inode_now() as suggested by Jan. > > > > > > > > > > > > > > > > Also could just call mark_inode_dirty() on the overlay inode > > > > > > > > regardless of the dirty flags on the upper inode since it shouldn't > > > > > > > > matter and results in simpler logic. > > > > > > > > > > > > > > > > > > > > > > Hi Miklos， > > > > > > > > > > > > > > Sorry for delayed response for this, I've been busy with another project. > > > > > > > > > > > > > > I agree with your suggesion above and further more how about just mark overlay inode dirty > > > > > > > when it has upper inode? This approach will make marking dirtiness simple enough. > > > > > > > > > > > > Are you suggesting that all non-lower overlay inodes should always be dirty? > > > > > > > > > > > > The logic would be simple, no doubt, but there's the cost to walking > > > > > > those overlay inodes which don't have a dirty upper inode, right? > > > > > > > > > > That's true. > > > > > > > > > > > Can you quantify this cost with a benchmark? Can be totally synthetic, > > > > > > e.g. lookup a million upper files without modifying them, then call > > > > > > syncfs. > > > > > > > > > > > > > > > > No problem, I'll do some tests for the performance. > > > > > > > > > > > > > Hi Miklos, > > > > > > > > I did some rough tests and the results like below. In practice, I don't > > > > think that 1.3s extra time of syncfs will cause significant problem. > > > > What do you think? > > > > > > Well, burning 1.3s worth of CPU time for doing nothing seems like quite a > > > bit to me. I understand this is with 1000000 inodes but although that is > > > quite a few it is not unheard of. If there would be several containers > > > calling sync_fs(2) on the machine they could easily hog the machine... That > > > is why I was originally against keeping overlay inodes always dirty and > > > wanted their dirtiness to at least roughly track the real need to do > > > writeback. > > > > > > > Hi Jan, > > > > Actually, the time on user and sys are almost same with directly excute syncfs on underlying fs. > > IMO, it only extends syncfs(2) waiting time for perticular container but not burning cpu. > > What am I missing? > > Ah, right, I've missed that only realtime changed, not systime. I'm sorry > for confusion. But why did the realtime increase so much? Are we waiting > for some IO? > There are many places to call cond_resched() in writeback process, so sycnfs process was scheduled several times. Thanks, Chengguang
On Fri 19-11-21 14:12:46, Chengguang Xu wrote: > ---- 在 星期五, 2021-11-19 00:43:49 Jan Kara <jack@suse.cz> 撰写 ---- > > On Thu 18-11-21 20:02:09, Chengguang Xu wrote: > > > ---- 在 星期四, 2021-11-18 19:23:15 Jan Kara <jack@suse.cz> 撰写 ---- > > > > On Thu 18-11-21 14:32:36, Chengguang Xu wrote: > > > > > > > > > > ---- 在 星期三, 2021-11-17 14:11:29 Chengguang Xu <cgxu519@mykernel.net> 撰写 ---- > > > > > > ---- 在 星期二, 2021-11-16 20:35:55 Miklos Szeredi <miklos@szeredi.hu> 撰写 ---- > > > > > > > On Tue, 16 Nov 2021 at 03:20, Chengguang Xu <cgxu519@mykernel.net> wrote: > > > > > > > > > > > > > > > > ---- 在 星期四, 2021-10-07 21:34:19 Miklos Szeredi <miklos@szeredi.hu> 撰写 ---- > > > > > > > > > On Thu, 7 Oct 2021 at 15:10, Chengguang Xu <cgxu519@mykernel.net> wrote: > > > > > > > > > > > However that wasn't what I was asking about. AFAICS ->write_inode() > > > > > > > > > > > won't start write back for dirty pages. Maybe I'm missing something, > > > > > > > > > > > but there it looks as if nothing will actually trigger writeback for > > > > > > > > > > > dirty pages in upper inode. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Actually, page writeback on upper inode will be triggered by overlayfs ->writepages and > > > > > > > > > > overlayfs' ->writepages will be called by vfs writeback function (i.e writeback_sb_inodes). > > > > > > > > > > > > > > > > > > Right. > > > > > > > > > > > > > > > > > > But wouldn't it be simpler to do this from ->write_inode()? > > > > > > > > > > > > > > > > > > I.e. call write_inode_now() as suggested by Jan. > > > > > > > > > > > > > > > > > > Also could just call mark_inode_dirty() on the overlay inode > > > > > > > > > regardless of the dirty flags on the upper inode since it shouldn't > > > > > > > > > matter and results in simpler logic. > > > > > > > > > > > > > > > > > > > > > > > > > Hi Miklos， > > > > > > > > > > > > > > > > Sorry for delayed response for this, I've been busy with another project. > > > > > > > > > > > > > > > > I agree with your suggesion above and further more how about just mark overlay inode dirty > > > > > > > > when it has upper inode? This approach will make marking dirtiness simple enough. > > > > > > > > > > > > > > Are you suggesting that all non-lower overlay inodes should always be dirty? > > > > > > > > > > > > > > The logic would be simple, no doubt, but there's the cost to walking > > > > > > > those overlay inodes which don't have a dirty upper inode, right? > > > > > > > > > > > > That's true. > > > > > > > > > > > > > Can you quantify this cost with a benchmark? Can be totally synthetic, > > > > > > > e.g. lookup a million upper files without modifying them, then call > > > > > > > syncfs. > > > > > > > > > > > > > > > > > > > No problem, I'll do some tests for the performance. > > > > > > > > > > > > > > > > Hi Miklos, > > > > > > > > > > I did some rough tests and the results like below. In practice, I don't > > > > > think that 1.3s extra time of syncfs will cause significant problem. > > > > > What do you think? > > > > > > > > Well, burning 1.3s worth of CPU time for doing nothing seems like quite a > > > > bit to me. I understand this is with 1000000 inodes but although that is > > > > quite a few it is not unheard of. If there would be several containers > > > > calling sync_fs(2) on the machine they could easily hog the machine... That > > > > is why I was originally against keeping overlay inodes always dirty and > > > > wanted their dirtiness to at least roughly track the real need to do > > > > writeback. > > > > > > > > > > Hi Jan, > > > > > > Actually, the time on user and sys are almost same with directly excute syncfs on underlying fs. > > > IMO, it only extends syncfs(2) waiting time for perticular container but not burning cpu. > > > What am I missing? > > > > Ah, right, I've missed that only realtime changed, not systime. I'm sorry > > for confusion. But why did the realtime increase so much? Are we waiting > > for some IO? > > > > There are many places to call cond_resched() in writeback process, > so sycnfs process was scheduled several times. 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. Honza
---- 在 星期二, 2021-11-30 19:22:06 Jan Kara <jack@suse.cz> 撰写 ---- > On Fri 19-11-21 14:12:46, Chengguang Xu wrote: > > ---- 在 星期五, 2021-11-19 00:43:49 Jan Kara <jack@suse.cz> 撰写 ---- > > > On Thu 18-11-21 20:02:09, Chengguang Xu wrote: > > > > ---- 在 星期四, 2021-11-18 19:23:15 Jan Kara <jack@suse.cz> 撰写 ---- > > > > > On Thu 18-11-21 14:32:36, Chengguang Xu wrote: > > > > > > > > > > > > ---- 在 星期三, 2021-11-17 14:11:29 Chengguang Xu <cgxu519@mykernel.net> 撰写 ---- > > > > > > > ---- 在 星期二, 2021-11-16 20:35:55 Miklos Szeredi <miklos@szeredi.hu> 撰写 ---- > > > > > > > > On Tue, 16 Nov 2021 at 03:20, Chengguang Xu <cgxu519@mykernel.net> wrote: > > > > > > > > > > > > > > > > > > ---- 在 星期四, 2021-10-07 21:34:19 Miklos Szeredi <miklos@szeredi.hu> 撰写 ---- > > > > > > > > > > On Thu, 7 Oct 2021 at 15:10, Chengguang Xu <cgxu519@mykernel.net> wrote: > > > > > > > > > > > > However that wasn't what I was asking about. AFAICS ->write_inode() > > > > > > > > > > > > won't start write back for dirty pages. Maybe I'm missing something, > > > > > > > > > > > > but there it looks as if nothing will actually trigger writeback for > > > > > > > > > > > > dirty pages in upper inode. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Actually, page writeback on upper inode will be triggered by overlayfs ->writepages and > > > > > > > > > > > overlayfs' ->writepages will be called by vfs writeback function (i.e writeback_sb_inodes). > > > > > > > > > > > > > > > > > > > > Right. > > > > > > > > > > > > > > > > > > > > But wouldn't it be simpler to do this from ->write_inode()? > > > > > > > > > > > > > > > > > > > > I.e. call write_inode_now() as suggested by Jan. > > > > > > > > > > > > > > > > > > > > Also could just call mark_inode_dirty() on the overlay inode > > > > > > > > > > regardless of the dirty flags on the upper inode since it shouldn't > > > > > > > > > > matter and results in simpler logic. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Miklos， > > > > > > > > > > > > > > > > > > Sorry for delayed response for this, I've been busy with another project. > > > > > > > > > > > > > > > > > > I agree with your suggesion above and further more how about just mark overlay inode dirty > > > > > > > > > when it has upper inode? This approach will make marking dirtiness simple enough. > > > > > > > > > > > > > > > > Are you suggesting that all non-lower overlay inodes should always be dirty? > > > > > > > > > > > > > > > > The logic would be simple, no doubt, but there's the cost to walking > > > > > > > > those overlay inodes which don't have a dirty upper inode, right? > > > > > > > > > > > > > > That's true. > > > > > > > > > > > > > > > Can you quantify this cost with a benchmark? Can be totally synthetic, > > > > > > > > e.g. lookup a million upper files without modifying them, then call > > > > > > > > syncfs. > > > > > > > > > > > > > > > > > > > > > > No problem, I'll do some tests for the performance. > > > > > > > > > > > > > > > > > > > Hi Miklos, > > > > > > > > > > > > I did some rough tests and the results like below. In practice, I don't > > > > > > think that 1.3s extra time of syncfs will cause significant problem. > > > > > > What do you think? > > > > > > > > > > Well, burning 1.3s worth of CPU time for doing nothing seems like quite a > > > > > bit to me. I understand this is with 1000000 inodes but although that is > > > > > quite a few it is not unheard of. If there would be several containers > > > > > calling sync_fs(2) on the machine they could easily hog the machine... That > > > > > is why I was originally against keeping overlay inodes always dirty and > > > > > wanted their dirtiness to at least roughly track the real need to do > > > > > writeback. > > > > > > > > > > > > > Hi Jan, > > > > > > > > Actually, the time on user and sys are almost same with directly excute syncfs on underlying fs. > > > > IMO, it only extends syncfs(2) waiting time for perticular container but not burning cpu. > > > > What am I missing? > > > > > > Ah, right, I've missed that only realtime changed, not systime. I'm sorry > > > for confusion. But why did the realtime increase so much? Are we waiting > > > for some IO? > > > > > > > There are many places to call cond_resched() in writeback process, > > so sycnfs process was scheduled several times. > > 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. 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. Thanks, Chengguang
> > 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. 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? Thanks, Amir.
---- 在 星期三, 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. Thanks, Chengguang
---- 在 星期三, 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
On Wed, Dec 1, 2021 at 8:31 AM Chengguang Xu <cgxu519@mykernel.net> wrote: > > > ---- 在 星期三, 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. > > 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.
On Wed 01-12-21 09:19:17, Amir Goldstein wrote: > On Wed, Dec 1, 2021 at 8:31 AM Chengguang Xu <cgxu519@mykernel.net> wrote: > > 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)? Well, if inode is writeably mapped, it must be also open for write, doesn't it? The VMA of the mapping will hold file open. So remarking overlay inode dirty during writeback while inode_is_open_for_write(upper) looks like reasonably easy and presumably there won't be that many inodes open for writing for this to become big overhead? > 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? But we still need to catch other dirtying events like timestamp updates, truncate(2) etc. to mark overlay inode dirty. Not sure how reliably that can be done... Honza
---- 在 星期三, 2021-12-01 21:46:10 Jan Kara <jack@suse.cz> 撰写 ---- > On Wed 01-12-21 09:19:17, Amir Goldstein wrote: > > On Wed, Dec 1, 2021 at 8:31 AM Chengguang Xu <cgxu519@mykernel.net> wrote: > > > 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)? > > Well, if inode is writeably mapped, it must be also open for write, doesn't > it? That's right. > The VMA of the mapping will hold file open. It's a bit tricky but currently ovl_mmap() will replace file to realfile in upper layer and release overlayfs file. So overlayfs file itself will not have any relationship with the VMA anymore after mmap(). Thanks, Chengguang > So remarking overlay inode > dirty during writeback while inode_is_open_for_write(upper) looks like > reasonably easy and presumably there won't be that many inodes open for > writing for this to become big overhead? > > > 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? > > But we still need to catch other dirtying events like timestamp updates, > truncate(2) etc. to mark overlay inode dirty. Not sure how reliably that > can be done... > > Honza > -- > Jan Kara <jack@suse.com> > SUSE Labs, CR >
---- 在 星期三, 2021-12-01 21:46:10 Jan Kara <jack@suse.cz> 撰写 ---- > On Wed 01-12-21 09:19:17, Amir Goldstein wrote: > > On Wed, Dec 1, 2021 at 8:31 AM Chengguang Xu <cgxu519@mykernel.net> wrote: > > > 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)? > > Well, if inode is writeably mapped, it must be also open for write, doesn't > it? The VMA of the mapping will hold file open. So remarking overlay inode > dirty during writeback while inode_is_open_for_write(upper) looks like > reasonably easy and presumably there won't be that many inodes open for > writing for this to become big overhead? > > > 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? > > But we still need to catch other dirtying events like timestamp updates, > truncate(2) etc. to mark overlay inode dirty. Not sure how reliably that > can be done... > To be honest I even don't fully understand what's the ->flush() logic in overlayfs. Why should we open new underlying file when calling ->flush()? Is it still correct in the case of opening lower layer first then copy-uped case? Thanks, Chengguang
On Wed, Dec 1, 2021 at 6:24 PM Chengguang Xu <cgxu519@mykernel.net> wrote: > > ---- 在 星期三, 2021-12-01 21:46:10 Jan Kara <jack@suse.cz> 撰写 ---- > > On Wed 01-12-21 09:19:17, Amir Goldstein wrote: > > > On Wed, Dec 1, 2021 at 8:31 AM Chengguang Xu <cgxu519@mykernel.net> wrote: > > > > 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)? > > > > Well, if inode is writeably mapped, it must be also open for write, doesn't > > it? The VMA of the mapping will hold file open. So remarking overlay inode > > dirty during writeback while inode_is_open_for_write(upper) looks like > > reasonably easy and presumably there won't be that many inodes open for > > writing for this to become big overhead? I think it should be ok and a good tradeoff of complexity vs. performance. > > > > > 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? > > > > But we still need to catch other dirtying events like timestamp updates, > > truncate(2) etc. to mark overlay inode dirty. Not sure how reliably that > > can be done... > > Oh yeh, we have those as well :) All those cases should be covered by ovl_copyattr() that updates the ovl inode ctime/mtime, so always dirty in ovl_copyattr() should be good. I *think* the only case of ovl_copyattr() that should not dirty is in ovl_inode_init(), so need some special helper there. > > To be honest I even don't fully understand what's the ->flush() logic in overlayfs. > Why should we open new underlying file when calling ->flush()? > Is it still correct in the case of opening lower layer first then copy-uped case? > The semantics of flush() are far from being uniform across filesystems. most local filesystems do nothing on close. most network fs only flush dirty data when a writer closes a file but not when a reader closes a file. It is hard to imagine that applications rely on flush-on-close of rdonly fd behavior and I agree that flushing only if original fd was upper makes more sense, so I am not sure if it is really essential for overlayfs to open an upper rdonly fd just to do whatever the upper fs would have done on close of rdonly fd, but maybe there is no good reason to change this behavior either. Thanks, Amir.
> > > > To be honest I even don't fully understand what's the ->flush() logic in overlayfs. > > Why should we open new underlying file when calling ->flush()? > > Is it still correct in the case of opening lower layer first then copy-uped case? > > > > The semantics of flush() are far from being uniform across filesystems. > most local filesystems do nothing on close. > most network fs only flush dirty data when a writer closes a file > but not when a reader closes a file. > It is hard to imagine that applications rely on flush-on-close of > rdonly fd behavior and I agree that flushing only if original fd was upper > makes more sense, so I am not sure if it is really essential for > overlayfs to open an upper rdonly fd just to do whatever the upper fs > would have done on close of rdonly fd, but maybe there is no good > reason to change this behavior either. > On second thought, I think there may be a good reason to change ovl_flush() otherwise I wouldn't have submitted commit a390ccb316be ("fuse: add FOPEN_NOFLUSH") - I did observe applications that frequently open short lived rdonly fds and suffered undesired latencies on close(). As for "changing existing behavior", I think that most fs used as upper do not implement flush at all. Using fuse/virtiofs as overlayfs upper is quite new, so maybe that is not a problem and maybe the new behavior would be preferred for those users? Thanks, Amir.
---- 在 星期四, 2021-12-02 07:23:17 Amir Goldstein <amir73il@gmail.com> 撰写 ---- > > > > > > To be honest I even don't fully understand what's the ->flush() logic in overlayfs. > > > Why should we open new underlying file when calling ->flush()? > > > Is it still correct in the case of opening lower layer first then copy-uped case? > > > > > > > The semantics of flush() are far from being uniform across filesystems. > > most local filesystems do nothing on close. > > most network fs only flush dirty data when a writer closes a file > > but not when a reader closes a file. > > It is hard to imagine that applications rely on flush-on-close of > > rdonly fd behavior and I agree that flushing only if original fd was upper > > makes more sense, so I am not sure if it is really essential for > > overlayfs to open an upper rdonly fd just to do whatever the upper fs > > would have done on close of rdonly fd, but maybe there is no good > > reason to change this behavior either. > > > > On second thought, I think there may be a good reason to change > ovl_flush() otherwise I wouldn't have submitted commit > a390ccb316be ("fuse: add FOPEN_NOFLUSH") - I did observe > applications that frequently open short lived rdonly fds and suffered > undesired latencies on close(). > > As for "changing existing behavior", I think that most fs used as > upper do not implement flush at all. > Using fuse/virtiofs as overlayfs upper is quite new, so maybe that > is not a problem and maybe the new behavior would be preferred > for those users? > So is that mean simply redirect the ->flush request to original underlying realfile? Thanks, Chengguang
On Thu, Dec 02, 2021 at 01:23:17AM +0200, Amir Goldstein wrote: > > > > > > To be honest I even don't fully understand what's the ->flush() logic in overlayfs. > > > Why should we open new underlying file when calling ->flush()? > > > Is it still correct in the case of opening lower layer first then copy-uped case? > > > > > > > The semantics of flush() are far from being uniform across filesystems. > > most local filesystems do nothing on close. > > most network fs only flush dirty data when a writer closes a file > > but not when a reader closes a file. > > It is hard to imagine that applications rely on flush-on-close of > > rdonly fd behavior and I agree that flushing only if original fd was upper > > makes more sense, so I am not sure if it is really essential for > > overlayfs to open an upper rdonly fd just to do whatever the upper fs > > would have done on close of rdonly fd, but maybe there is no good > > reason to change this behavior either. > > > > On second thought, I think there may be a good reason to change > ovl_flush() otherwise I wouldn't have submitted commit > a390ccb316be ("fuse: add FOPEN_NOFLUSH") - I did observe > applications that frequently open short lived rdonly fds and suffered > undesired latencies on close(). > > As for "changing existing behavior", I think that most fs used as > upper do not implement flush at all. > Using fuse/virtiofs as overlayfs upper is quite new, so maybe that > is not a problem and maybe the new behavior would be preferred > for those users? It probably will be nice not to send flush to fuse server when it is not required. Right now in virtiofsd, I see that we are depending on flush being sent as we are dealing with remote posix lock magic. I am supporting remotme posix locks in virtiofs and virtiofsd is building these on top of open file description locks on host. (Can't use posix locks on host as these locks are per process and virtiofsd is single process working on behalf of all the guest processes, and unexpected things happen). When an fd is being closed, flush request is sent and along with it we also send "lock_owner". inarg.lock_owner = fuse_lock_owner_id(fm->fc, id); We basically use this to keep track which process is closing the fd and release associated OFD locks on host. /me needs to dive into details to explain it better. Will do that if need be. Bottom line is that as of now virtiofsd seems to be relying on receiving FLUSH requests when remote posix locks are enabled. Maybe we can set FOPEN_NOFLUSH when remote posix locks are not enabled. Thanks Vivek
On Thu, Dec 02, 2021 at 10:11:39AM +0800, Chengguang Xu wrote: > > ---- 在 星期四, 2021-12-02 07:23:17 Amir Goldstein <amir73il@gmail.com> 撰写 ---- > > > > > > > > To be honest I even don't fully understand what's the ->flush() logic in overlayfs. > > > > Why should we open new underlying file when calling ->flush()? > > > > Is it still correct in the case of opening lower layer first then copy-uped case? > > > > > > > > > > The semantics of flush() are far from being uniform across filesystems. > > > most local filesystems do nothing on close. > > > most network fs only flush dirty data when a writer closes a file > > > but not when a reader closes a file. > > > It is hard to imagine that applications rely on flush-on-close of > > > rdonly fd behavior and I agree that flushing only if original fd was upper > > > makes more sense, so I am not sure if it is really essential for > > > overlayfs to open an upper rdonly fd just to do whatever the upper fs > > > would have done on close of rdonly fd, but maybe there is no good > > > reason to change this behavior either. > > > > > > > On second thought, I think there may be a good reason to change > > ovl_flush() otherwise I wouldn't have submitted commit > > a390ccb316be ("fuse: add FOPEN_NOFLUSH") - I did observe > > applications that frequently open short lived rdonly fds and suffered > > undesired latencies on close(). > > > > As for "changing existing behavior", I think that most fs used as > > upper do not implement flush at all. > > Using fuse/virtiofs as overlayfs upper is quite new, so maybe that > > is not a problem and maybe the new behavior would be preferred > > for those users? > > > > So is that mean simply redirect the ->flush request to original underlying realfile? If the file has been copied up since open(), then flush should go on upper file, right? I think Amir is talking about that can we optimize flush in overlay and not call ->flush at all if file was opened read-only, IIUC. In case of fuse he left it to server. If that's the case, then in case of overlayfs, it should be left to underlyng filesystem as well? Otherwise, it might happen underlying filesystem (like virtiofs) might be expecting ->flush() and overlayfs decided not to call it because file was read only. So I will lean towards continue to call ->flush in overlay and try to optimize virtiofsd to set FOPEN_NOFLUSH when not required. Thanks Vivek
On Thu, Dec 2, 2021 at 5:20 PM Vivek Goyal <vgoyal@redhat.com> wrote: > > On Thu, Dec 02, 2021 at 10:11:39AM +0800, Chengguang Xu wrote: > > > > ---- 在 星期四, 2021-12-02 07:23:17 Amir Goldstein <amir73il@gmail.com> 撰写 ---- > > > > > > > > > > To be honest I even don't fully understand what's the ->flush() logic in overlayfs. > > > > > Why should we open new underlying file when calling ->flush()? > > > > > Is it still correct in the case of opening lower layer first then copy-uped case? > > > > > > > > > > > > > The semantics of flush() are far from being uniform across filesystems. > > > > most local filesystems do nothing on close. > > > > most network fs only flush dirty data when a writer closes a file > > > > but not when a reader closes a file. > > > > It is hard to imagine that applications rely on flush-on-close of > > > > rdonly fd behavior and I agree that flushing only if original fd was upper > > > > makes more sense, so I am not sure if it is really essential for > > > > overlayfs to open an upper rdonly fd just to do whatever the upper fs > > > > would have done on close of rdonly fd, but maybe there is no good > > > > reason to change this behavior either. > > > > > > > > > > On second thought, I think there may be a good reason to change > > > ovl_flush() otherwise I wouldn't have submitted commit > > > a390ccb316be ("fuse: add FOPEN_NOFLUSH") - I did observe > > > applications that frequently open short lived rdonly fds and suffered > > > undesired latencies on close(). > > > > > > As for "changing existing behavior", I think that most fs used as > > > upper do not implement flush at all. > > > Using fuse/virtiofs as overlayfs upper is quite new, so maybe that > > > is not a problem and maybe the new behavior would be preferred > > > for those users? > > > > > > > So is that mean simply redirect the ->flush request to original underlying realfile? > > If the file has been copied up since open(), then flush should go on upper > file, right? > > I think Amir is talking about that can we optimize flush in overlay and > not call ->flush at all if file was opened read-only, IIUC. > Maybe that's what I wrote, but what I meant was if file was open as lower read-only and later copied up, not sure we should bother with ovl_open_realfile() for flushing upper. > In case of fuse he left it to server. If that's the case, then in case > of overlayfs, it should be left to underlyng filesystem as well? > Otherwise, it might happen underlying filesystem (like virtiofs) might > be expecting ->flush() and overlayfs decided not to call it because > file was read only. > Certainly, if upper wants flush on rdonly file we must call flush on close of rdonly file *that was opened on upper*. But if we opened rdonly file on lower, even if lower is virtiofs, does virtiosfd needs this flush? that same file on the server was not supposed to be written by anyone. If virtiofsd really needs this flush then it is a problem already today, because if lower file was copied up since open rdonly, virtiofsd is not going to get the flushes for the lower file (only the release). However, I now realize that if we opened file rdonly on lower, we may have later opened a short lived realfile on upper for read post copy up and we never issued a flush for this short live rdonly upper fd. So actually, unless we store a flag or something that says that we never opened upper realfile, we should keep current behavior. > So I will lean towards continue to call ->flush in overlay and try to > optimize virtiofsd to set FOPEN_NOFLUSH when not required. > Makes sense. Calling flush() on fs that does nothing with it doesn't hurt. Thanks, Amir.
On Thu, Dec 02, 2021 at 05:59:56PM +0200, Amir Goldstein wrote: > On Thu, Dec 2, 2021 at 5:20 PM Vivek Goyal <vgoyal@redhat.com> wrote: > > > > On Thu, Dec 02, 2021 at 10:11:39AM +0800, Chengguang Xu wrote: > > > > > > ---- 在 星期四, 2021-12-02 07:23:17 Amir Goldstein <amir73il@gmail.com> 撰写 ---- > > > > > > > > > > > > To be honest I even don't fully understand what's the ->flush() logic in overlayfs. > > > > > > Why should we open new underlying file when calling ->flush()? > > > > > > Is it still correct in the case of opening lower layer first then copy-uped case? > > > > > > > > > > > > > > > > The semantics of flush() are far from being uniform across filesystems. > > > > > most local filesystems do nothing on close. > > > > > most network fs only flush dirty data when a writer closes a file > > > > > but not when a reader closes a file. > > > > > It is hard to imagine that applications rely on flush-on-close of > > > > > rdonly fd behavior and I agree that flushing only if original fd was upper > > > > > makes more sense, so I am not sure if it is really essential for > > > > > overlayfs to open an upper rdonly fd just to do whatever the upper fs > > > > > would have done on close of rdonly fd, but maybe there is no good > > > > > reason to change this behavior either. > > > > > > > > > > > > > On second thought, I think there may be a good reason to change > > > > ovl_flush() otherwise I wouldn't have submitted commit > > > > a390ccb316be ("fuse: add FOPEN_NOFLUSH") - I did observe > > > > applications that frequently open short lived rdonly fds and suffered > > > > undesired latencies on close(). > > > > > > > > As for "changing existing behavior", I think that most fs used as > > > > upper do not implement flush at all. > > > > Using fuse/virtiofs as overlayfs upper is quite new, so maybe that > > > > is not a problem and maybe the new behavior would be preferred > > > > for those users? > > > > > > > > > > So is that mean simply redirect the ->flush request to original underlying realfile? > > > > If the file has been copied up since open(), then flush should go on upper > > file, right? > > > > I think Amir is talking about that can we optimize flush in overlay and > > not call ->flush at all if file was opened read-only, IIUC. > > > > Maybe that's what I wrote, but what I meant was if file was open as > lower read-only and later copied up, not sure we should bother with > ovl_open_realfile() for flushing upper. I am not sure either. Miklos might have thoughts on this. > > > In case of fuse he left it to server. If that's the case, then in case > > of overlayfs, it should be left to underlyng filesystem as well? > > Otherwise, it might happen underlying filesystem (like virtiofs) might > > be expecting ->flush() and overlayfs decided not to call it because > > file was read only. > > > > Certainly, if upper wants flush on rdonly file we must call flush on > close of rdonly file *that was opened on upper*. > > But if we opened rdonly file on lower, even if lower is virtiofs, does > virtiosfd needs this flush? Right now virtiofsd seems to care about flush for read only files for remote posix locks. Given overlayfs is not registering f_op->lock() handler, my understaning is that all locking will be done by VFS on overlayfs inode and it will never reach to the level of virtiofs (lower or upper). If that's the case, then atleast from locking perspective we don't need flush on lower for virtiofs. > that same file on the server was not supposed > to be written by anyone. > If virtiofsd really needs this flush then it is a problem already today, > because if lower file was copied up since open rdonly, virtiofsd > is not going to get the flushes for the lower file (only the release). So virtiofs will not get flushes on lower only if file got copied-up after opening on lower, right? So far nobody has complained. But if there is a use case somewhere, we might have to issue a flush on lower as well. > > However, I now realize that if we opened file rdonly on lower, > we may have later opened a short lived realfile on upper for read post > copy up and we never issued a flush for this short live rdonly upper fd. > So actually, unless we store a flag or something that says that > we never opened upper realfile, we should keep current behavior. I am assuming you are referring to ovl_read_iter() where it will open upper file for read and then call fdput(real). So why should we issue flush on upper in this case? I thought flush will need to be issued only when overlay "fd" as seen by user space is closed (and not when inernal fds opened by overlay are closed). So real question is, do we need to issue flush when fd is opened read only. If yes, then we probably need to issue flush both on lower and upper (and not only on upper). But if flush is to be issued only for the case of fd which was writable, then issuing it on upper makes sense. > > > So I will lean towards continue to call ->flush in overlay and try to > > optimize virtiofsd to set FOPEN_NOFLUSH when not required. > > > > Makes sense. > Calling flush() on fs that does nothing with it doesn't hurt. This probably is safest right now given virtiofs expects flush to be issued even for read only fd (in case of remote posix locks). Though that's a different thing that when overlayfs is sitting on top, we will not be using remote posix lock functionality of virtiofs, IIUC. Vivek
---- 在 星期四, 2021-12-02 06:47:25 Amir Goldstein <amir73il@gmail.com> 撰写 ---- > On Wed, Dec 1, 2021 at 6:24 PM Chengguang Xu <cgxu519@mykernel.net> wrote: > > > > ---- 在 星期三, 2021-12-01 21:46:10 Jan Kara <jack@suse.cz> 撰写 ---- > > > On Wed 01-12-21 09:19:17, Amir Goldstein wrote: > > > > On Wed, Dec 1, 2021 at 8:31 AM Chengguang Xu <cgxu519@mykernel.net> wrote: > > > > > 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)? > > > > > > Well, if inode is writeably mapped, it must be also open for write, doesn't > > > it? The VMA of the mapping will hold file open. So remarking overlay inode > > > dirty during writeback while inode_is_open_for_write(upper) looks like > > > reasonably easy and presumably there won't be that many inodes open for > > > writing for this to become big overhead? > > I think it should be ok and a good tradeoff of complexity vs. performance. IMO, mark dirtiness on write is relatively simple, so I think we can mark the overlayfs inode dirty during real write behavior and only remark writable mmap unconditionally in ->write_inode(). > > > > > > > > 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? > > > > > > But we still need to catch other dirtying events like timestamp updates, > > > truncate(2) etc. to mark overlay inode dirty. Not sure how reliably that > > > can be done... > > > > > Oh yeh, we have those as well :) > All those cases should be covered by ovl_copyattr() that updates the > ovl inode ctime/mtime, so always dirty in ovl_copyattr() should be good. Currently ovl_copyattr() does not cover all the cases, so I think we still need to carefully check all the places of calling mnt_want_write(). Thanks, Chengguang > I *think* the only case of ovl_copyattr() that should not dirty is in > ovl_inode_init(), so need some special helper there. > > > > > To be honest I even don't fully understand what's the ->flush() logic in overlayfs. > > Why should we open new underlying file when calling ->flush()? > > Is it still correct in the case of opening lower layer first then copy-uped case? > > > > The semantics of flush() are far from being uniform across filesystems. > most local filesystems do nothing on close. > most network fs only flush dirty data when a writer closes a file > but not when a reader closes a file. > It is hard to imagine that applications rely on flush-on-close of > rdonly fd behavior and I agree that flushing only if original fd was upper > makes more sense, so I am not sure if it is really essential for > overlayfs to open an upper rdonly fd just to do whatever the upper fs > would have done on close of rdonly fd, but maybe there is no good > reason to change this behavior either. > > Thanks, > Amir. >
On Sun, Dec 5, 2021 at 4:07 PM Chengguang Xu <cgxu519@mykernel.net> wrote: > > ---- 在 星期四, 2021-12-02 06:47:25 Amir Goldstein <amir73il@gmail.com> 撰写 ---- > > On Wed, Dec 1, 2021 at 6:24 PM Chengguang Xu <cgxu519@mykernel.net> wrote: > > > > > > ---- 在 星期三, 2021-12-01 21:46:10 Jan Kara <jack@suse.cz> 撰写 ---- > > > > On Wed 01-12-21 09:19:17, Amir Goldstein wrote: > > > > > On Wed, Dec 1, 2021 at 8:31 AM Chengguang Xu <cgxu519@mykernel.net> wrote: > > > > > > 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)? > > > > > > > > Well, if inode is writeably mapped, it must be also open for write, doesn't > > > > it? The VMA of the mapping will hold file open. So remarking overlay inode > > > > dirty during writeback while inode_is_open_for_write(upper) looks like > > > > reasonably easy and presumably there won't be that many inodes open for > > > > writing for this to become big overhead? > > > > I think it should be ok and a good tradeoff of complexity vs. performance. > > IMO, mark dirtiness on write is relatively simple, so I think we can mark the > overlayfs inode dirty during real write behavior and only remark writable mmap > unconditionally in ->write_inode(). > If by "on write" you mean on write/copy_file_range/splice_write/... then yes I agree since we have to cover all other mnt_want_write() cases anyway. > > > > > > > > > > > > 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? > > > > > > > > But we still need to catch other dirtying events like timestamp updates, > > > > truncate(2) etc. to mark overlay inode dirty. Not sure how reliably that > > > > can be done... > > > > > > > > Oh yeh, we have those as well :) > > All those cases should be covered by ovl_copyattr() that updates the > > ovl inode ctime/mtime, so always dirty in ovl_copyattr() should be good. > > Currently ovl_copyattr() does not cover all the cases, so I think we still need to carefully > check all the places of calling mnt_want_write(). > Careful audit is always good, but if we do not have ovl_copyattr() in a call site that should mark inode dirty, then it sounds like a bug, because ovl inode ctime will not get updated. Do you know of any such cases? Thanks, Amir.
在 2021/12/7 13:33, Amir Goldstein 写道: > On Sun, Dec 5, 2021 at 4:07 PM Chengguang Xu <cgxu519@mykernel.net> wrote: >> ---- 在 星期四, 2021-12-02 06:47:25 Amir Goldstein <amir73il@gmail.com> 撰写 ---- >> > On Wed, Dec 1, 2021 at 6:24 PM Chengguang Xu <cgxu519@mykernel.net> wrote: >> > > >> > > ---- 在 星期三, 2021-12-01 21:46:10 Jan Kara <jack@suse.cz> 撰写 ---- >> > > > On Wed 01-12-21 09:19:17, Amir Goldstein wrote: >> > > > > On Wed, Dec 1, 2021 at 8:31 AM Chengguang Xu <cgxu519@mykernel.net> wrote: >> > > > > > 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)? >> > > > >> > > > Well, if inode is writeably mapped, it must be also open for write, doesn't >> > > > it? The VMA of the mapping will hold file open. So remarking overlay inode >> > > > dirty during writeback while inode_is_open_for_write(upper) looks like >> > > > reasonably easy and presumably there won't be that many inodes open for >> > > > writing for this to become big overhead? >> > >> > I think it should be ok and a good tradeoff of complexity vs. performance. >> >> IMO, mark dirtiness on write is relatively simple, so I think we can mark the >> overlayfs inode dirty during real write behavior and only remark writable mmap >> unconditionally in ->write_inode(). >> > If by "on write" you mean on write/copy_file_range/splice_write/... > then yes I agree > since we have to cover all other mnt_want_write() cases anyway. > >> > >> > > > >> > > > > 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? >> > > > >> > > > But we still need to catch other dirtying events like timestamp updates, >> > > > truncate(2) etc. to mark overlay inode dirty. Not sure how reliably that >> > > > can be done... >> > > > >> > >> > Oh yeh, we have those as well :) >> > All those cases should be covered by ovl_copyattr() that updates the >> > ovl inode ctime/mtime, so always dirty in ovl_copyattr() should be good. >> >> Currently ovl_copyattr() does not cover all the cases, so I think we still need to carefully >> check all the places of calling mnt_want_write(). >> > Careful audit is always good, but if we do not have ovl_copyattr() in > a call site > that should mark inode dirty, then it sounds like a bug, because ovl inode ctime > will not get updated. Do you know of any such cases? Sorry for my late response, I've been very busy lately. For your question, for example, there is a case of calling ovl_want_write() in ovl_cache_get_impure() and caller does not call ovl_copyattr() so I think we should explicitly mark ovl inode dirty in that case. Is that probably a bug? Thanks, Chengguang
On Sat, Feb 5, 2022 at 6:10 PM Chengguang Xu <cgxu519@mykernel.net> wrote: > > 在 2021/12/7 13:33, Amir Goldstein 写道: > > On Sun, Dec 5, 2021 at 4:07 PM Chengguang Xu <cgxu519@mykernel.net> wrote: > >> ---- 在 星期四, 2021-12-02 06:47:25 Amir Goldstein <amir73il@gmail.com> 撰写 ---- > >> > On Wed, Dec 1, 2021 at 6:24 PM Chengguang Xu <cgxu519@mykernel.net> wrote: > >> > > > >> > > ---- 在 星期三, 2021-12-01 21:46:10 Jan Kara <jack@suse.cz> 撰写 ---- > >> > > > On Wed 01-12-21 09:19:17, Amir Goldstein wrote: > >> > > > > On Wed, Dec 1, 2021 at 8:31 AM Chengguang Xu <cgxu519@mykernel.net> wrote: > >> > > > > > 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)? > >> > > > > >> > > > Well, if inode is writeably mapped, it must be also open for write, doesn't > >> > > > it? The VMA of the mapping will hold file open. So remarking overlay inode > >> > > > dirty during writeback while inode_is_open_for_write(upper) looks like > >> > > > reasonably easy and presumably there won't be that many inodes open for > >> > > > writing for this to become big overhead? > >> > > >> > I think it should be ok and a good tradeoff of complexity vs. performance. > >> > >> IMO, mark dirtiness on write is relatively simple, so I think we can mark the > >> overlayfs inode dirty during real write behavior and only remark writable mmap > >> unconditionally in ->write_inode(). > >> > > If by "on write" you mean on write/copy_file_range/splice_write/... > > then yes I agree > > since we have to cover all other mnt_want_write() cases anyway. > > > >> > > >> > > > > >> > > > > 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? > >> > > > > >> > > > But we still need to catch other dirtying events like timestamp updates, > >> > > > truncate(2) etc. to mark overlay inode dirty. Not sure how reliably that > >> > > > can be done... > >> > > > > >> > > >> > Oh yeh, we have those as well :) > >> > All those cases should be covered by ovl_copyattr() that updates the > >> > ovl inode ctime/mtime, so always dirty in ovl_copyattr() should be good. > >> > >> Currently ovl_copyattr() does not cover all the cases, so I think we still need to carefully > >> check all the places of calling mnt_want_write(). > >> > > Careful audit is always good, but if we do not have ovl_copyattr() in > > a call site > > that should mark inode dirty, then it sounds like a bug, because ovl inode ctime > > will not get updated. Do you know of any such cases? > > Sorry for my late response, I've been very busy lately. > For your question, for example, there is a case of calling > ovl_want_write() in ovl_cache_get_impure() and caller does not call > ovl_copyattr() > so I think we should explicitly mark ovl inode dirty in that case. Is > that probably a bug? > > The correct behavior would be similar to that of setting impure xattr in ovl_link_up(). We would want to snapshot the upperdir attrs before removing xattr and restore them after (best effort). Not that this case is so important, but if you have an opportunity to mark inode dirty in ovl_copyattr() I think that would be the best way to go. Thanks, Amir.
diff --git a/fs/overlayfs/super.c b/fs/overlayfs/super.c index 2ab77adf7256..cddae3ca2fa5 100644 --- a/fs/overlayfs/super.c +++ b/fs/overlayfs/super.c @@ -412,12 +412,42 @@ static void ovl_evict_inode(struct inode *inode) clear_inode(inode); } +static int ovl_write_inode(struct inode *inode, + struct writeback_control *wbc) +{ + struct ovl_fs *ofs = inode->i_sb->s_fs_info; + struct inode *upper = ovl_inode_upper(inode); + unsigned long iflag = 0; + int ret = 0; + + if (!upper) + return 0; + + if (!ovl_should_sync(ofs)) + return 0; + + if (upper->i_sb->s_op->write_inode) + ret = upper->i_sb->s_op->write_inode(inode, wbc); + + if (mapping_writably_mapped(upper->i_mapping) || + mapping_tagged(upper->i_mapping, PAGECACHE_TAG_WRITEBACK)) + iflag |= I_DIRTY_PAGES; + + iflag |= upper->i_state & I_DIRTY_ALL; + + if (iflag) + ovl_mark_inode_dirty(inode); + + return ret; +} + static const struct super_operations ovl_super_operations = { .alloc_inode = ovl_alloc_inode, .free_inode = ovl_free_inode, .destroy_inode = ovl_destroy_inode, .drop_inode = generic_delete_inode, .evict_inode = ovl_evict_inode, + .write_inode = ovl_write_inode, .put_super = ovl_put_super, .sync_fs = ovl_sync_fs, .statfs = ovl_statfs,
Implement overlayfs' ->write_inode to sync dirty data and redirty overlayfs' inode if necessary. Signed-off-by: Chengguang Xu <cgxu519@mykernel.net> --- fs/overlayfs/super.c | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+)