[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <569DA62B.7070701@codeaurora.org>
Date: Mon, 18 Jan 2016 18:57:47 -0800
From: Nikhilesh Reddy <reddyn@...eaurora.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
CC: Andy Lutomirski <luto@...capital.net>,
Nikolaus Rath <nikolaus@...h.org>,
fuse-devel <fuse-devel@...ts.sourceforge.net>,
Al Viro <viro@...iv.linux.org.uk>,
Greg KH <gregkh@...uxfoundation.org>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
Linux API <linux-api@...r.kernel.org>, Jan Kara <jack@...e.cz>,
Theodore Ts'o <tytso@....edu>, sven.utcke@....de,
Miklos Szeredi <miklos@...redi.hu>,
Richard Weinberger <richard@....at>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Antonio SJ Musumeci <trapexit@...wn.link>
Subject: Re: [PATCH] fuse: Add support for fuse stacked I/O
On 01/15/2016 01:53 PM, Linus Torvalds wrote:
> On Fri, Jan 15, 2016 at 1:46 PM, Andy Lutomirski <luto@...capital.net> wrote:
>
>> If mmap sets vm_file to the underlying thing, wouldn't CRIU and
>> anything else that uses map_files get confused? Or did you have
>> something else in mind?
>
> Why would they care?
>
> Also, I don't think you actually need to change vm_file - we have this
> whole notion of "inode->i_data" vs "inode->i_mapping".
>
> So I think you could set the "i_mapping" of the fuse inode to be the
> i_mapping of the passed-through-to inode, and it should just work.
>
> And no, I didn't look into this very deeply, and maybe there is some
> annoying detail that would make that not work well. But that's part of
> the whole point of the i_mapping indirection: so that you can share
> the page cache when you have two separate anchor points. I think coda
> uses it for the local caching, and block devices use it to not have
> mapping aliases between different inodex that all are the same block
> device.
>
> Linus
>
Hi
Thanks for your support.
I am looking into adding the mmap by change the i_mmaping but seems to
be getting stuck for some stress tests.
Once i get that debugged and working i will definitely send out a new
patch with that functionality.
( Sending it as a second patch will help make it easier to go through
the legal redtape and procedures i am forced to follow).
For now i am going to update the current patch and call it "passthrough"
as you suggested and also update the commit message giving a clearer
explanation of the motivation.
Once i get it tested I can send it out for consideration and review
Please do let me know if you have any questions or concerns on this and
i will try my best to address them all.
--
Thanks
Nikhilesh Reddy
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
Powered by blists - more mailing lists