quota woes

quota woes

[Steve French (IBM LTC)]

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). 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).   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
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)  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)

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?"

Re: quota woes

[Nathan Scott]

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

Re: quota woes

[Jan Kara]

  Hello,

> 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). 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).
  Actually quota tools are not supposed to work on anything else than on
block devices. There's one exception - using RPC you can get your quota
usage from NFS server but that's all. Also kernel quotacltl(2) interface
is not supposed to be working for anything else than block devices.
  Quota on NFS mounts is actually done on the server and client knows
nothing about it.

>  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
> 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)  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)
> 
> 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?"
  The quota tools on SF are the latest ones. And currently they are
validating the device because kernel interface requires a device (at
least if we are speaking about standard VFS quota - XFS is a bit
different case).

								Honza

Re: quota woes

[Nathan Scott]

On Tue, Aug 12, 2003 at 02:23:20PM +0200, Jan Kara wrote:
> Hello,

hi Jan,

> > 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?"
>   The quota tools on SF are the latest ones. And currently they are
> validating the device because kernel interface requires a device (at
> least if we are speaking about standard VFS quota - XFS is a bit
> different case).

The XFS commands all require block special devices; the one command
that doesn't is Q_SYNC (one of the standard VFS commands) because
it can be used to sync all filesystems quota files at once, iirc.

cheers.

-- 
Nathan

Re: quota woes

[Steve French (IBM LTC)]

sys_quotactl takes a pathname, which is translated to a superblock.    This
would work fine for the many "deviceless" filesystems except that the name is
not translated as it is in most path based calls in the kernel.  sys_quotactl
takes the path name (ie parm named special) and simply converts it to a
superblock:
                 tmp = getname(special);
                 if (IS_ERR(tmp))
                         return PTR_ERR(tmp);
                 bdev = lookup_bdev(tmp);
                 putname(tmp);
                 if (IS_ERR(bdev))
                         return PTR_ERR(bdev);
                 sb = get_super(bdev);
My suggestion is to allow this to work for more filesystems by falling back on
failure on the above device to sb resolution (or changing the above code) to the
standard way paths are resolved to superblocks in the kernel sys layer.  For
example in statfs the name to superblock resolution is done simply by calling:
             error = user_path_walk(path, &nd);
then the vfs routine is called with the sb retrieved from above:
             vfs_statfs_native(nd.dentry->d_inode->i_sb ...)
This kind of name resolution (using user_path_walk or equivalent) handles a much
wider variety of filesystems than doing the more awkward name to device then
device to superblock.


Note that the routine that dispatches to the filesystem only needs a superblock
(which deviceless and network filesystems can handle) and does not explicitly
need a device number or name:

    do_quotactl(struct super_block *sb, int type, int cmd, qid_t id, caddr_t
addr)

I expect that CIFS and AFS and NFSv4 are not the only deviceless filesystems
that could be easily enhanced to transparently send the quota calls to the
proper target server if the above change were made.    For the CIFS case,
sending user quota calls to the server (Samba, Windows, Network Attached Storage
appliance) is fairly easy  (group quotas for the case of CIFS network protocol
need more investigation).

Nathan Scott wrote:

> > And currently they are
> > validating the device because kernel interface requires a device (at
> > least if we are speaking about standard VFS quota - XFS is a bit
> > different case).
>
> The XFS commands all require block special devices; the one command
> that doesn't is Q_SYNC (one of the standard VFS commands) because
> it can be used to sync all filesystems quota files at once, iirc.
>
> cheers.
>
> --
> Nathan

Re: quota woes

[Stefan (metze) Metzmacher]

At 10:50 13.08.2003 -0500, Steve French (IBM LTC) wrote:
>sys_quotactl takes a pathname, which is translated to a superblock.    This
>would work fine for the many "deviceless" filesystems except that the name is
>not translated as it is in most path based calls in the kernel.  sys_quotactl
>takes the path name (ie parm named special) and simply converts it to a
>superblock:
>                  tmp = getname(special);
>                  if (IS_ERR(tmp))
>                          return PTR_ERR(tmp);
>                  bdev = lookup_bdev(tmp);
>                  putname(tmp);
>                  if (IS_ERR(bdev))
>                          return PTR_ERR(bdev);
>                  sb = get_super(bdev);
>My suggestion is to allow this to work for more filesystems by falling back on
>failure on the above device to sb resolution (or changing the above code) 
>to the
>standard way paths are resolved to superblocks in the kernel sys layer.  For
>example in statfs the name to superblock resolution is done simply by calling:
>              error = user_path_walk(path, &nd);
>then the vfs routine is called with the sb retrieved from above:
>              vfs_statfs_native(nd.dentry->d_inode->i_sb ...)
>This kind of name resolution (using user_path_walk or equivalent) handles 
>a much
>wider variety of filesystems than doing the more awkward name to device then
>device to superblock.
>
>
>Note that the routine that dispatches to the filesystem only needs a 
>superblock
>(which deviceless and network filesystems can handle) and does not explicitly
>need a device number or name:
>
>     do_quotactl(struct super_block *sb, int type, int cmd, qid_t id, caddr_t
>addr)
>
>I expect that CIFS and AFS and NFSv4 are not the only deviceless filesystems
>that could be easily enhanced to transparently send the quota calls to the
>proper target server if the above change were made.

sounds nice

>    For the CIFS case,
>sending user quota calls to the server (Samba, Windows, Network Attached 
>Storage
>appliance) is fairly easy  (group quotas for the case of CIFS network protocol
>need more investigation).

yep, maybe we need to add a unix extension for this to the cifs protocol...

Can anyone CC: me in mail on this topic, please I don't read linux-fsdevel...
thanks


metze
-----------------------------------------------------------------------------
Stefan "metze" Metzmacher <metze@metzemix.de>