lkml.org 
[lkml]   [2014]   [Aug]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] fuse: do not evict dirty inodes
Hi Miklos,

On 08/13/2014 02:32 PM, Miklos Szeredi wrote:
> On Tue, Jun 3, 2014 at 1:49 PM, Maxim Patlasov <MPatlasov@parallels.com> wrote:
>> Commit 1e18bda8 added .write_inode method to the fuse super_operations. This
>> allowed fuse to use the kernel infrastructure for writing out dirty metadata
>> (mtime and ctime for now). However, given that .drop_inode was not redefined
>> from the legacy generic_delete_inode(), on umount(2) generic_shutdown_super()
>> led to the eviction of all inodes disregarding their state.
>>
>> The patch removes .drop_inode definition from the fuse super_operations. This
>> works because now iput_final() calls generic_drop_inode() and returns w/o
>> evicting inode. This, in turn, allows generic_shutdown_super() to write dirty
>> inodes by calling sync_filesystem().
>>
>> Signed-off-by: Maxim Patlasov <MPatlasov@parallels.com>
>> ---
>> fs/fuse/inode.c | 1 -
>> 1 file changed, 1 deletion(-)
>>
>> diff --git a/fs/fuse/inode.c b/fs/fuse/inode.c
>> index 754dcf2..ee017be 100644
>> --- a/fs/fuse/inode.c
>> +++ b/fs/fuse/inode.c
>> @@ -791,7 +791,6 @@ static const struct super_operations fuse_super_operations = {
>> .destroy_inode = fuse_destroy_inode,
>> .evict_inode = fuse_evict_inode,
>> .write_inode = fuse_write_inode,
>> - .drop_inode = generic_delete_inode,
>> .remount_fs = fuse_remount_fs,
>> .put_super = fuse_put_super,
>> .umount_begin = fuse_umount_begin,
>>
> (Sorry about the late answer)
>
> Big problem with this is that I don't want to make umount(2) and
> sync(2) wait on userspace filesystem. Generally this would make
> umount() hang if a fuse daemon was stuck for any reason.

I think we must honour interests both privileged and unprivileged
mounts. In case of trusted environment where only sysad decides which
fuse daemons are eligible to run, blocking umount() is completely fine.
And more than that, after settling down that sync-close feature, I
intend to take on synchronous umount (it's a shame that users have no
tools to find out when umount completed better than monitoring of fuse
daemon in proc table waiting for daemon termination). So we could put
such a behaviour under control of a tunable parameter.

>
> But is this really necessary?
>
> We are talking about just regular files: mtime is only updated by
> write(2) and friends. ctime is updated by write(2) as well as some
> other ops. For write, we can sync the times on FLUSH (close), for
> other ops we could flush the ctime synchronously. E.g. unlink would
> trigger UNLINK and SETATTR.
>
> Long term, much better solution would be to add a timestamp to
> fuse_in_header which would remove the duplicate requests and then we
> could also extend the kernel caching of timestamps from just regular
> files to everything, which would make the protocol conceptually
> simpler.

I like the idea of extending fuse_in_header. But if we'll extend it, why
not go further adding timestamps for mtime and atime as well? Because
pushing mtime along with data modifications is more reliable than
postponing flush to write_inode call. Also, this would simplify the code
a lot -- no more fuse_write_inode and fuse_flush_times needed. And who
knows, may be someone will request proper atime handling at some point
in future. If you're OK about:

> @@ -675,10 +675,15 @@ struct fuse_in_header {
> uint32_t opcode;
> uint64_t unique;
> uint64_t nodeid;
> + uint64_t atime;
> + uint64_t mtime;
> + uint64_t ctime;
> + uint32_t atimensec;
> + uint32_t mtimensec;
> + uint32_t ctimensec;
> uint32_t uid;
> uint32_t gid;
> uint32_t pid;
> - uint32_t padding;
> };

I could work on the patch.

Thanks,
Maxim


\
 
 \ /
  Last update: 2014-08-15 14:01    [W:0.042 / U:0.112 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site