From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Harkes Subject: Re: Networked filesystems vs backing_dev_info Date: Sat, 27 Oct 2007 11:22:27 -0400 Message-ID: <20071027152227.GE3200@cs.cmu.edu> References: <1193477666.5648.61.camel@lappy> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-kernel , linux-fsdevel , David Howells , sfrench@samba.org, Andrew Morton , vandrove@vc.cvut.cz To: Peter Zijlstra Return-path: Received: from DELFT.AURA.CS.CMU.EDU ([128.2.206.88]:34683 "EHLO delft.aura.cs.cmu.edu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753432AbXJ0P4l (ORCPT ); Sat, 27 Oct 2007 11:56:41 -0400 Content-Disposition: inline In-Reply-To: <1193477666.5648.61.camel@lappy> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Sat, Oct 27, 2007 at 11:34:26AM +0200, Peter Zijlstra wrote: > I had me a little look at bdi usage in networked filesystems. > > NFS, CIFS, (smbfs), AFS, CODA and NCP > > And of those, NFS is the only one that I could find that creates > backing_dev_info structures. The rest seems to fall back to > default_backing_dev_info. While a file is opened in Coda we associate the open file handle with a local cache file. All read and write operations are redirected to this local file and we even redirect inode->i_mapping. Actual reads and writes are completely handled by the underlying file system. We send the new file contents back to the servers only after all local references have been released (last-close semantics). As a result, there is no need for backing_dev_info structures in Coda, if any congestion control is needed it will be handled by the underlying file system where our locally cached copies are stored. Jan