quota woes

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

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

Hello,

Quoted 3 lines

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

Quoted 4 lines

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

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