From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Van Hensbergen Subject: Re: v9fs writepage Date: Sat, 30 Apr 2005 13:10:39 -0500 Message-ID: References: Reply-To: Eric Van Hensbergen Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: kernel-mentors@selenic.com, v9fs-developer@lists.sourceforge.net, linux-fsdevel@vger.kernel.org, hch@infradead.org, viro@parcelfarce.linux.theplanet.co.uk Return-path: To: Miklos Szeredi In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kernel-mentors-bounces@selenic.com Errors-To: kernel-mentors-bounces@selenic.com List-Id: linux-fsdevel.vger.kernel.org On 4/30/05, Miklos Szeredi wrote: > > I'm not given an easy handle (in most cases its the dentry or the > > file structure) to resolve a FID against. > > While it had a writepage(), FUSE had a similar problem. The solution > was to store a list of files suitable for writing in the inode (the > private inode data). The list was updated in the open() and release() > methods. And in writepage() the first entry on the list was taken. > No searching was required. > > You're probably wondering what happened to writepage() in FUSE. Well > it was removed because it turned out to be deadlock prone in OOM > situations. That is actually not a speciality of FUSE, most network > filesystems are vulnerable in case the server is running on the same > machine as the client. And in other cases as well, but only to a > lesser extent. > > The reason is that if the server needs to allocate memory to fulfill > the writeback request, this allocation will block (since the system is > just trying to free up memory) resulting in a deadlock. > > You should keep this in mind for v9fs too, if you want to allow > non-privileged users to mount their filesystems. > I remember seeing some of this thread on LKML, wasn't this one of Linus' big complaints about FUSE? I'm fine with leaving writepage out of v9fs, particularly for user-mounts and/or synthetic file systems. Is there an established guideline for its use? (I suppose as long as we know the file system is remote then we can allow it -- or is it only user-space file systems/user-mounts that are a concern?) It would seem a relaxed check in my v9fs_fid_locate would provide the same service as keeping open files in the inode. We had looked at doing something similar, but I hated the idea of having to keep the extra book-keeping if there was another path (particularly since we are already cacheing fids in dentries). Basically, I could add a flag to v9fs_fid locate which says if you can't find an appropriate context (a fid owned by the same user, pid, or pgrp as the context performing the writepage) then choose any open fid matching the file. I may be able to get closer by flagging fids which have been mmapped -- but that seems like overkill and doesn't necessarily provide any additional accuracy for this corner case. Thanks Miklos. -eric