From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot0-f196.google.com ([74.125.82.196]:38800 "EHLO mail-ot0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755126AbeDWOJF (ORCPT ); Mon, 23 Apr 2018 10:09:05 -0400 Received: by mail-ot0-f196.google.com with SMTP id j27-v6so17183653ota.5 for ; Mon, 23 Apr 2018 07:09:05 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20180423135309.GC2794@redhat.com> References: <20180412150826.20988-1-mszeredi@redhat.com> <20180412150826.20988-14-mszeredi@redhat.com> <20180423133617.GB2794@redhat.com> <20180423135309.GC2794@redhat.com> From: Miklos Szeredi Date: Mon, 23 Apr 2018 16:09:03 +0200 Message-ID: Subject: Re: [RFC PATCH 13/35] ovl: readd fsync To: Vivek Goyal Cc: Miklos Szeredi , overlayfs , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Mon, Apr 23, 2018 at 3:53 PM, Vivek Goyal wrote: > On Mon, Apr 23, 2018 at 03:39:45PM +0200, Miklos Szeredi wrote: >> On Mon, Apr 23, 2018 at 3:36 PM, Vivek Goyal wrote: >> > On Thu, Apr 12, 2018 at 05:08:04PM +0200, Miklos Szeredi wrote: >> >> Implement stacked fsync(). >> >> >> >> Signed-off-by: Miklos Szeredi >> >> --- >> >> fs/overlayfs/file.c | 20 ++++++++++++++++++++ >> >> 1 file changed, 20 insertions(+) >> >> >> >> diff --git a/fs/overlayfs/file.c b/fs/overlayfs/file.c >> >> index b98204c1c19c..4417527667ff 100644 >> >> --- a/fs/overlayfs/file.c >> >> +++ b/fs/overlayfs/file.c >> >> @@ -222,10 +222,30 @@ static ssize_t ovl_write_iter(struct kiocb *iocb, struct iov_iter *iter) >> >> return ret; >> >> } >> >> >> >> +static int ovl_fsync(struct file *file, loff_t start, loff_t end, int datasync) >> >> +{ >> >> + struct fd real; >> >> + const struct cred *old_cred; >> >> + int ret; >> >> + >> >> + ret = ovl_real_file(file, &real); >> >> + if (ret) >> >> + return ret; >> >> + >> >> + old_cred = ovl_override_creds(file_inode(file)->i_sb); >> >> + ret = vfs_fsync_range(real.file, start, end, datasync); >> >> + revert_creds(old_cred); >> > >> > Can we avoid calling fsync() on real file if it is not upper. Is it worth >> > optimizing. >> >> Not sure it's worth bothering with. If caller of fsync(2) didn't >> worry about cost, then why should we? > > I was thinking more from the point of view of metadata copy up patches. > For a metacopy file, I was thinking if I can just issue fsync() on upper > file and skip it on lower file. Ah, in that case I agree with doing fsync only on upper. If there's a choice in implementing the given functionality (and performance doesn't matter) then the simplest one should be chosen. Thanks, Miklos