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 Actual results: You see the filesystem size of the share (here 1GB), not the quota size. Expected results: You should see the effective size (the quota size) (100MB) as seen on Windows clients. Additional info: 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 cifspdu.h: #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.