From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Sharp Subject: Re: nfs exporting my stacked fs Date: Wed, 28 May 2003 22:29:22 -0700 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <20030529052922.GA4324@ccpu.com> References: <20030528215754.GA2336@ccpu.com> <16085.16577.463731.505824@notabene.cse.unsw.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org Return-path: Received: from covad-netfall.meer.net ([209.157.145.14]:46301 "EHLO eviltwins") by vger.kernel.org with ESMTP id S261873AbTE2FQJ (ORCPT ); Thu, 29 May 2003 01:16:09 -0400 To: Neil Brown Content-Disposition: inline In-Reply-To: <16085.16577.463731.505824@notabene.cse.unsw.edu.au> List-Id: linux-fsdevel.vger.kernel.org On Thu, May 29, 2003 at 09:05:37AM +1000, Neil Brown wrote: > On Wednesday May 28, andy@ccpu.com wrote: > > I could use some help getting my stacked (I guess that's the term d' jour) > > file system to be nfs exported/mounted. From reading the code, it seems > > that my file system either has to require a device, it doesn't, or it > > has to have some sort of FSID (the call to nfsctl_export() is failing), > > only I can't seem to figure out how to accomplish that. I tried to go > > through the mountd source, but came up empty. What did I miss? > > If your filesystem isn't device based (which seems likely for a > stacked filesystem), the nfsd cannot use the device number as a short, > fixed length identifier for the filesystem, which it needs for storing > in the filehandle. So, you need to provide one. > This is done in the /etc/exportss file with the fsid= option. > e.g. > > /my/file/system myclient(rw,no_root_squash,sync,fsid=27) Thanks for that info, I was unaware of that option. Soooo, this brings up some other questions for me. What is the relation between the fsid option mentioned above and the fsid returned by statfs op? Which I discovered shortly after sending my first email. Should they match? The i_dev is apparently used on device datasets for the filehandle, so do all datasets with the same i_dev somehow guarantee that i_dev/inode # 'filehandles' are somehow unique? a