RE: mount points / free disk space / dfree command
On Tue, 4 Mar 2003, Panko, Kevin wrote: I went and read some of the CIFS spec[1], and it seems to me that the QUERY_FS_INFO trans2 request only includes an identifier for the current connection. Given this information, samba can only attempt to determine the amount of space on the root of the share. This explains why using the dfree command did not give me any different numbers than not using it. I'm not sure I understand exactly what you want. But there is the potential, at least in the future, for doing more than simply a df. Did you see my reply of Feb 24th, which mentioned what samba can already do if quotas are present (and, implicitly, applicable to a filesystem)? And how this might be generalised? (By coincidence, another thread has just started about group quota.) If I really understand what is going on here, then what we would have to do is create a new share for each mounted device. That would be hard because the root that is exported happens to be an automounter directory, which changes. Want simple df-like functionality? Present, as the default. Want to use user quotas? Present, with appropriate compilation and UN*X-host quota configuration. Want to use group quotas? Not yet present; but a recent thread discusses a possibility. Want to call an external program? Present as dfree command. I have never used it. I suspect it cannot do quota-like per-user stuff, nor per-subdirectory stuff. I could well envisage something conceptually similar to dfree command, but more flexible, to allow use of username and current-directory: 1. yet another smb.conf option. Like dfree command (calling external program). This could be hacked up reasonably quickly, but is a dirty solution, expecially in view of current herculean efforts to clean the Samba code. 2. Generalise (and re-implement) the existing stuff (df, dfree command, quota) as VFS modules, allowing sites to write their own modules. This would take longer to do, but would be much cleaner, and aligns well with future development. Summary: What you want may not be there right now. But I think it could be added if designed reasonably carefully, and in context of the bigger picture. Hope that helps (a little, at least!). -- : David LeeI.T. Service : : Systems Programmer Computer Centre : : University of Durham : : http://www.dur.ac.uk/t.d.lee/South Road: : Durham: : Phone: +44 191 374 2882 U.K. :
RE: mount points / free disk space / dfree command
I went and read some of the CIFS spec[1], and it seems to me that the QUERY_FS_INFO trans2 request only includes an identifier for the current connection. Given this information, samba can only attempt to determine the amount of space on the root of the share. This explains why using the dfree command did not give me any different numbers than not using it. If I really understand what is going on here, then what we would have to do is create a new share for each mounted device. That would be hard because the root that is exported happens to be an automounter directory, which changes. [1] http://ubiqx.org/cifs/rfc-draft/draft-leach-cifs-v1-spec-02.html#s4.1.6 -Original Message- From: Panko, Kevin [mailto:[EMAIL PROTECTED] Sent: Thursday, February 20, 2003 3:27 PM To: '' Subject: mount points / free disk space / dfree command We have a share with mount points beneath it. Free disk space is incorrect because samba always returns the free space in the top level directory of the share. It is the same problem discussed before in this thread: http://groups.google.com/groups?hl=enlr=ie=UTF-8oe=UTF-8th=4c04c4aeb2405 d4dseekm=9q2iee%242s7r%241%40FreeBSD.csie.NCTU.edu.twframe=off I was hoping to use the dfree command smb.conf option, as the df command reports the correct amount of free space for each subdirectory. I found that my dfree command was always given the directory name of the top level of the share, regardless of the current directory on the Win2k client, so the answer I get with dfree is the same as the internal samba routines. Why does that happen? Does the call have knowledge of the current directory of the client, or is that not included in the client's request? If not, then I must admit that this may be impossible. If it does, and if that directory were passed to the df command, then what I need can be done via samba. I do not want to use recursion and add up the amount of free space as the sum of each mount point. I only care about the current directory. We do have a need to determine the amount of free space from Win2k, and creating a samba share for each subdirectory would be impractical. TIA, Kevin Panko
Re: mount points / free disk space / dfree command
On Thu, 20 Feb 2003, Panko, Kevin wrote: We have a share with mount points beneath it. Free disk space is incorrect because samba always returns the free space in the top level directory of the share. It is the same problem discussed before in this thread: http://groups.google.com/groups?hl=enlr=ie=UTF-8oe=UTF-8th=4c04c4aeb2405 d4dseekm=9q2iee%242s7r%241%40FreeBSD.csie.NCTU.edu.twframe=off I was hoping to use the dfree command smb.conf option, as the df command reports the correct amount of free space for each subdirectory. I found that my dfree command was always given the directory name of the top level of the share, regardless of the current directory on the Win2k client, so the answer I get with dfree is the same as the internal samba routines. Why does that happen? Does the QUERY_FS_INFO trans2 call have knowledge of the current directory of the client, or is that not included in the client's request? If not, then I must admit that this may be impossible. If it does, and if that directory were passed to the df command, then what I need can be done via samba. This raises a slightly wider question, of which yours is one case. Another case, already handled, is when the samba server (typically UNIX) has user quotas. Samba's behaviour is to let any individual user-quota override its normal df-for-whole-volume behaviour. Also the smb.conf file does allow an alternative command to be specified and run. (This might be an immediate way for you to address your particular issue, although I get the feeling, possibly wrongly, that this option might be regarded in the as try to avoid if reasonably possible or at your own risk etc.) Now pulling all that together and looking at the wider question... I wonder whether there is a case for reshaping this functionality into VFS modules in the VFS stack? The default would still be df behaviour, but there might be a VFS/quota module, which could act as a model for other free-space modules. -- : David LeeI.T. Service : : Systems Programmer Computer Centre : : University of Durham : : http://www.dur.ac.uk/t.d.lee/South Road: : Durham: : Phone: +44 191 374 2882 U.K. :
