Red Hat Bugzilla – Bug 499397
[CIFS] Share-level (or folder-level) quota not handled
Last modified: 2014-06-18 03:38:58 EDT
For shares exported with share-level/folder level quotas on a Windows 2003 R2 server, the df command reports the size of the total used/free space on the filesystem instead of the effective disk space for the share.
Steps to Reproduce:
- Create partition Windows 2003 R2 (<-- !!! "R2" IS IMPORTANT. NOT TO CONFUSE WITH "SP2" !!!) fileserver e.g. size 1GB
- Create folder on newly created partition
- Enable folder quota on newly created folder e.g. size 100MB
- Export folder from Server
- Mount share with RHEL5 Client via cifs
- Call "df" on the mountpoint
You see the filesystem size of the share (here 1GB), not the quota size.
You should see the effective size (the quota size) (100MB) as seen on Windows clients.
The windows client uses
QUERY_FS_INFO with level of interest "Query Full FS Size Info"
which returns "Allocation Size", "Caller Free Units", "Actual Free Units".
The RHEL5 Client (cifs-sharelevel-quota-rhelclient.pcap) uses
QUERY_FS_INFO with level of Interest "Query FS Size Info"
which only returns "Allocation Size", "Free Units". Both of this values
doesn't reflect the defined quota.
As I saw in the kernel source code (RedHat Source-RPM) the "Level of Interest"
is defined, but never used
#define SMB_QUERY_FS_SIZE_INFO 0x103
#define SMB_QUERY_FS_FULL_SIZE_INFO 0x3ef
int CIFSSMBQFSInfo(const int xid, struct cifsTconInfo *tcon, struct kstatfs *FSData)
pSMB->InformationLevel = cpu_to_le16(SMB_QUERY_FS_SIZE_INFO);
This is similar to the code seen in the upstream kernel tree.
Created attachment 342663 [details]
tcpdump with Windows client
I've had a bit of a chance to look at this...
SMB_QUERY_FS_FULL_SIZE_INFO is a passthrough infolevel, so we'll need to make sure that we don't regress when talking to older servers that may not support that call (I've got a win98se image that I can test against).
The code may need to fall back to the current call if the new call doesn't work against a particular server.
Adding Steve French, the upstream maintainer for CIFS...
This looks doable, but I'm trying to determine if this is correct behavior. Why should we have statfs take quotas into account? Having statfs return different info for different users sounds confusing (I assume that different users get different values here? Is that correct?).
Too late for 5.5 anyway...
Been a while since I've revisited this one, but I'm inclined to NAK this BZ altogether and suggest that it instead be turned into a feature request to fix up quota handling for CIFS. It seems to me that statfs info ought to show global information about the share, and that info on quotas is better presented via the quota tools.
On that, I'm going to devel_nak this BZ for 5.6. Please reopen it as a feature request if you wish to pursue implementing the quota interfaces in CIFS.
Development Management has reviewed and declined this request. You may appeal
this decision by reopening this request.