All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Maxim V. Patlasov" <mpatlasov@parallels.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: <dev@parallels.com>, <xemul@parallels.com>,
	<fuse-devel@lists.sourceforge.net>,
	<linux-kernel@vger.kernel.org>, <jbottomley@parallels.com>,
	<viro@zeniv.linux.org.uk>, <linux-fsdevel@vger.kernel.org>,
	<devel@openvz.org>
Subject: Re: [PATCH 07/14] fuse: Update i_mtime on buffered writes
Date: Tue, 26 Mar 2013 13:55:30 +0400	[thread overview]
Message-ID: <51517092.2020203@parallels.com> (raw)
In-Reply-To: <CAJfpegtszx6cDJ9fUPTB_z-1vG7iM8J1jdKuEdqN+wPFkOf6NQ@mail.gmail.com>

Hi Miklos,

Sorry for long delay, see please inline comment below.

01/30/2013 02:19 AM, Miklos Szeredi пишет:
> On Fri, Jan 25, 2013 at 7:24 PM, Maxim V. Patlasov
> <MPatlasov@parallels.com> wrote:
>> If writeback cache is on, buffered write doesn't result in immediate mtime
>> update in userspace because the userspace will see modified data later, when
>> writeback happens. Consequently, mtime provided by userspace may be older than
>> actual time of buffered write.
>>
>> The problem can be solved by generating mtime locally (will come in next
>> patches) and flushing it to userspace periodically. Here we introduce a flag to
>> keep the state of fuse_inode: the flag is ON if and only if locally generated
>> mtime (stored in inode->i_mtime) was not pushed to the userspace yet.
>>
>> The patch also implements all bits related to flushing and clearing the flag.
>>
>> Signed-off-by: Maxim Patlasov <MPatlasov@parallels.com>
>> ---
>>   fs/fuse/dir.c    |   42 +++++++++++++++++++++++++----
>>   fs/fuse/file.c   |   31 ++++++++++++++++++---
>>   fs/fuse/fuse_i.h |   13 ++++++++-
>>   fs/fuse/inode.c  |   79 +++++++++++++++++++++++++++++++++++++++++++++++++++++-
>>   4 files changed, 154 insertions(+), 11 deletions(-)
>>
>> diff --git a/fs/fuse/dir.c b/fs/fuse/dir.c
>> index ff8b603..969c60d 100644
>> --- a/fs/fuse/dir.c
>> +++ b/fs/fuse/dir.c
>> @@ -177,6 +177,13 @@ static int fuse_dentry_revalidate(struct dentry *entry, unsigned int flags)
>>                  if (flags & LOOKUP_RCU)
>>                          return -ECHILD;
>>
>> +               if (test_bit(FUSE_I_MTIME_UPDATED,
>> +                            &get_fuse_inode(inode)->state)) {
>> +                       err = fuse_flush_mtime(inode, 0);
> ->d_revalidate may be called with or without i_mutex, there's
> absolutely no way to know.  So this won't work.
>
> I know it was me who suggested this approach, but I have second
> thoughts...  I really don't like the way this mixes userspace and
> kernel updates to mtime.  I think it should be either one or the
> other.
>
> I don't think you need to much changes to this patch.  Just clear
> S_NOCMTIME, implement i_op->update_time(), which sets the
> FUSE_I_MTIME_UPDATED flag and flush mtime just like you do now.
> Except now it doesn't need to take i_mutex since all mtime updates are
> now done by the kernel.
>
> Does that make sense?

Yes, but it's not as simple as you described above. mtime updates should 
be strictly serialized, I used i_mutex for this purpose. Abandoning 
i_mutex, we'll have to introduce another lock for synchronization. 
Otherwise, we won't know when it's secure to clear FUSE_I_MTIME_UPDATED 
flag. Another approach is to introduce one more state: 
FUSE_I_MTIME_UPDATE_IN_PROGRESS. But again, we'll need something like 
waitq to wait for mtime update completion.

I'd prefer much more simple solution: clear S_NOCMTIME and implement 
i_op->update_time() as you suggested; but flush mtime only on last 
close. May be we could extend FUSE_RELEASE request (struct 
fuse_release_in) to accommodate mtime. Are you OK about it?

Thanks,
Maxim

>
> Thanks,
> Miklos
>


  reply	other threads:[~2013-03-26  9:58 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-25 18:20 [PATCH v3 00/14] fuse: An attempt to implement a write-back cache policy Maxim V. Patlasov
2013-01-25 18:20 ` Maxim V. Patlasov
2013-01-25 18:20 ` [PATCH 01/14] fuse: Linking file to inode helper Maxim V. Patlasov
2013-01-25 18:20   ` Maxim V. Patlasov
2013-01-25 18:21 ` [PATCH 02/14] fuse: Getting file for writeback helper Maxim V. Patlasov
2013-01-25 18:21   ` Maxim V. Patlasov
2013-01-25 18:21 ` [PATCH 03/14] fuse: Prepare to handle short reads Maxim V. Patlasov
2013-01-25 18:21 ` [PATCH 04/14] fuse: Prepare to handle multiple pages in writeback Maxim V. Patlasov
2013-01-25 18:21   ` Maxim V. Patlasov
2013-01-25 18:22 ` [PATCH 05/14] fuse: Connection bit for enabling writeback Maxim V. Patlasov
2013-01-25 18:22   ` Maxim V. Patlasov
2013-01-25 18:22 ` [PATCH 06/14] fuse: Trust kernel i_size only - v2 Maxim V. Patlasov
2013-01-25 18:22   ` Maxim V. Patlasov
2013-01-29 10:18   ` Miklos Szeredi
2013-03-25 12:29     ` Maxim V. Patlasov
2013-01-25 18:24 ` [PATCH 07/14] fuse: Update i_mtime on buffered writes Maxim V. Patlasov
2013-01-29 22:19   ` Miklos Szeredi
2013-03-26  9:55     ` Maxim V. Patlasov [this message]
2013-01-25 18:24 ` [PATCH 08/14] fuse: Flush files on wb close Maxim V. Patlasov
2013-01-25 18:24   ` Maxim V. Patlasov
2013-01-29 22:58   ` Miklos Szeredi
2013-03-26 11:24     ` Maxim V. Patlasov
2013-03-26 11:24       ` Maxim V. Patlasov
2013-01-25 18:25 ` [PATCH 09/14] fuse: Implement writepages and write_begin/write_end callbacks - v2 Maxim V. Patlasov
2013-01-25 18:25   ` Maxim V. Patlasov
2013-01-29 23:08   ` Miklos Szeredi
2013-03-27 12:39     ` Maxim V. Patlasov
2013-03-27 12:39       ` Maxim V. Patlasov
2013-01-25 18:25 ` [PATCH 10/14] fuse: fuse_writepage_locked() should wait on writeback Maxim V. Patlasov
2013-01-25 18:25   ` Maxim V. Patlasov
2013-01-25 18:26 ` [PATCH 11/14] fuse: fuse_flush() " Maxim V. Patlasov
2013-01-25 18:26   ` Maxim V. Patlasov
2013-01-25 18:27 ` [PATCH 12/14] fuse: Fix O_DIRECT operations vs cached writeback misorder - v2 Maxim V. Patlasov
2013-01-25 18:27 ` [PATCH 13/14] fuse: Turn writeback cache on Maxim V. Patlasov
2013-01-25 18:27   ` Maxim V. Patlasov
2013-01-25 18:28 ` [PATCH 14/14] mm: Account for WRITEBACK_TEMP in balance_dirty_pages Maxim V. Patlasov
2013-01-25 18:28   ` Maxim V. Patlasov
  -- strict thread matches above, loose matches on Subject: below --
2012-11-16 17:04 [PATCH v2 00/14] fuse: An attempt to implement a write-back cache policy Maxim Patlasov
2012-11-16 17:09 ` [PATCH 07/14] fuse: Update i_mtime on buffered writes Maxim Patlasov
2012-11-16 17:09   ` Maxim Patlasov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51517092.2020203@parallels.com \
    --to=mpatlasov@parallels.com \
    --cc=dev@parallels.com \
    --cc=devel@openvz.org \
    --cc=fuse-devel@lists.sourceforge.net \
    --cc=jbottomley@parallels.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=viro@zeniv.linux.org.uk \
    --cc=xemul@parallels.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.