From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nathan Scott Subject: Re: quota woes Date: Mon, 11 Aug 2003 11:24:21 +1000 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <20030811012421.GG9384@frodo> References: <3F36A2EC.EC77B3FF@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org Return-path: Received: from zok.SGI.COM ([204.94.215.101]:24022 "EHLO zok.sgi.com") by vger.kernel.org with ESMTP id S270805AbTHKB1Z (ORCPT ); Sun, 10 Aug 2003 21:27:25 -0400 To: "Steve French (IBM LTC)" Content-Disposition: inline In-Reply-To: <3F36A2EC.EC77B3FF@us.ibm.com> List-Id: linux-fsdevel.vger.kernel.org On Sun, Aug 10, 2003 at 02:54:20PM -0500, Steve French (IBM LTC) wrote: > Experimenting with Linux quotas for network filesystems is turning out > to be painful. I have not been able to experiment with the parms > passed in from the quota calls invoked by the common Linux/Unix quota > tools (quotacheck, quotaon, quotacheck) due to what looks like bugs in > the Linux quota tools (the only source I could find for these tools was > out on the sourceforge project). That is the most uptodate source, and Jan actively maintains it. > Even for the new xfs style quota > interface they refuse to handle a deviceless (network) filesystem mount > properly even after modifying the quota tools code to make the cifs vfs > treated like XFS (the only one that seems to invoke the new quota call > format). There are multiple quotactl interfaces and multiple ondisk formats. The XFS interface and ondisk format are specific to XFS (they came originally from the IRIX implementation); nothing else needs to use those. > After changing the tool to recognize my filesystem name as a > valid one (they hardcode the actual valid filesystem names in the quota > tools on sourceforge!) it still fails to invoke my test code due to Outrageous. > mismatch on devnumber (network filesystems don't have real device > numbers for each mount). I had been hoping to experiment with the > current stub quota routines (in preparation for adding remote quota > support to cifs filesystem in the long run) ... Its been awhile since I looked at that source, but IIRC for NFS mounts the tools do not actually go into the (local) kernel via quotactl, they make RPC calls to the remote host instead (i.e. the tools decide what to do based on the filesystem type). > ... that I added to the cifs > vfs source in the cifs bitkeeper tree a few days ago, eventually these > could call the server to get/set the quotas by specifying a valid SID > which is also an interesting problem because that requires either an IPC > to Winbind or upcall to a user space daemon to do mapping of local to > domain identity (to be exact mapping the Linux UID to domain SID) Sounds like you need to come up with a design - adding code behind quotactl ops in cifs doesn't sound like a useful thing to do until you know what approach you want to take (maybe look more at the way an NFS client implements this - its all userspace). > Is there another source of quota tools that calls the newer quota > interface that would not require validating mount's local device numbers > before invoking the kernel quotactl interface?" No, I guess you'd need to add some code to do so, if going into the kernel via quotactl is the right thing for cifs to do - from your description above, its not clear that it is though. cheers. -- Nathan