From: "Maxim V. Patlasov" <mpatlasov@parallels.com>
To: Feng Shuo <steve.shuo.feng@gmail.com>
Cc: <miklos@szeredi.hu>, <dev@parallels.com>,
"fuse-devel@lists.sourceforge.net"
<fuse-devel@lists.sourceforge.net>,
<linux-kernel@vger.kernel.org>, <jbottomley@parallels.com>,
<viro@zeniv.linux.org.uk>, <linux-fsdevel@vger.kernel.org>,
<xemul@openvz.org>
Subject: Re: [PATCH v2 00/14] fuse: An attempt to implement a write-back cache policy
Date: Tue, 27 Nov 2012 11:56:51 +0400 [thread overview]
Message-ID: <50B47243.9080706@parallels.com> (raw)
In-Reply-To: <CALmpHyb5wpn-dABuEwpypUggRY=1aULvJW0z17HpH50pr1=HKg@mail.gmail.com>
Hi Feng,
11/27/2012 05:04 AM, Feng Shuo пишет:
> Hi Maxim,
>
> I'm new to fuse but have some experience with NFS. From my
> understanding after reviewing your patchset, it seems only work with
> local file system or a distributed file system whose file is never
> modified (could be grown but no or very few modified) because it
> doesn't exam the pre/post status of the writing object (e.g. a file).
> So if a file is modified outside, fuse might not get any chance to
> handle it...... Correct me if I got wrong since I'm really new to
> fuse. :-)
This topic was discussed when Pavel sent initial version of patches (you
can find it in fuse-devel archives). Brian asked:
> Would this pose a problem for a filesystem in which the size of the
> inode can change remotely (i.e., not visible to the local instance of
> fuse)? I haven't tested this, but it seems like it could be an issue
> based on the implementation.
And Pavel replied:
> Yes, it will. The model of i_size management I implemented here is based
> on an assumption that the userspace is just a storage for data and should
> catch up with the kernel i_size value. In order to make it possible for user
> space to update i_size in kernel we'd have to implement some (probably)
> tricky algorithm, I haven't yet thought about it.
The patch-set follows the model "trust kernel i_size only". This works
fine at least in case of userspace fuse wtih exclusive write semantics.
In case of mutual concurrent internal/external read/write access, sysad
should not turn the feature on (it's turned off by default). I wouldn't
like to complicate the patch-set further adding bits for that case. This
area is opened for future enhancements :)
Thanks,
Maxim
next prev parent reply other threads:[~2012-11-27 7:56 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
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:05 ` [PATCH 01/14] fuse: Linking file to inode helper Maxim Patlasov
2012-11-16 17:05 ` [PATCH 02/14] fuse: Getting file for writeback helper Maxim Patlasov
2012-11-16 17:06 ` [PATCH 03/14] fuse: Prepare to handle short reads Maxim Patlasov
2012-11-16 17:07 ` [PATCH 04/14] fuse: Prepare to handle multiple pages in writeback Maxim Patlasov
2012-11-16 17:07 ` [PATCH 05/14] fuse: Connection bit for enabling writeback Maxim Patlasov
2012-11-16 17:07 ` [PATCH 06/14] fuse: Trust kernel i_size only Maxim Patlasov
2012-12-05 16:39 ` [PATCH] fuse: Trust kernel i_size only - v2 Maxim Patlasov
2012-12-05 16:40 ` [PATCH] fuse: Implement writepages and write_begin/write_end callbacks " Maxim Patlasov
2012-11-16 17:09 ` [PATCH 07/14] fuse: Update i_mtime on buffered writes Maxim Patlasov
2012-11-16 17:09 ` [PATCH 08/14] fuse: Flush files on wb close Maxim Patlasov
2012-11-16 17:09 ` [PATCH 09/14] fuse: Implement writepages and write_begin/write_end callbacks Maxim Patlasov
2012-11-16 17:09 ` [PATCH 10/14] fuse: fuse_writepage_locked() should wait on writeback Maxim Patlasov
2012-11-16 17:10 ` [PATCH 11/14] fuse: fuse_flush() " Maxim Patlasov
2012-11-16 17:10 ` [PATCH 12/14] fuse: Fix O_DIRECT operations vs cached writeback misorder Maxim Patlasov
2012-12-05 16:43 ` [PATCH] fuse: Fix O_DIRECT operations vs cached writeback misorder - v2 Maxim Patlasov
2012-11-16 17:10 ` [PATCH 13/14] fuse: Turn writeback cache on Maxim Patlasov
2012-11-16 17:10 ` [PATCH 14/14] mm: Account for WRITEBACK_TEMP in balance_dirty_pages Maxim Patlasov
2012-11-21 12:01 ` Maxim Patlasov
2012-11-22 13:27 ` Jaegeuk Hanse
2012-11-22 13:56 ` Maxim V. Patlasov
2012-11-27 1:04 ` [PATCH v2 00/14] fuse: An attempt to implement a write-back cache policy Feng Shuo
2012-11-27 7:56 ` Maxim V. Patlasov [this message]
2012-12-12 14:53 ` Maxim V. Patlasov
2013-01-15 15:20 ` Maxim V. Patlasov
2013-01-25 10:21 ` Miklos Szeredi
2013-01-25 12:50 ` Maxim V. 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=50B47243.9080706@parallels.com \
--to=mpatlasov@parallels.com \
--cc=dev@parallels.com \
--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=steve.shuo.feng@gmail.com \
--cc=viro@zeniv.linux.org.uk \
--cc=xemul@openvz.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).