If you activate "my desktop" every share is asked for its size two times.
During resize of "my desktop" the dfree command is asked continuously.
We have a large disk for our shares so the user cannot see how much space he
uses in each share.
We have ~1000 shares, ~800 users and every user sees about five shares in "my
We implemented a simple shellscript which makes use of "du -sk" and simulates
a free space in specific 50MB, 1GB or 5GB blocks according to our needs. Our
shellscript consumes too much cpu-time because windows asks too often for the
Would it be possible to implement a caching algorithm for the dfree command?
Yeah I think I see how to do this. We'll need s "dfree cache time" per-share
parameter in seconds - default to zero (no caching). Would that work for you ?
Target would be 3.0.21 or 3.0.22.
Created attachment 1529 [details]
Ok - here's a proposed fix that does 2 things.
1). Makes dfree command a per-share parameter (it should be anyway IMHO).
2). Adds a "dfree cache time" parameter in seconds that specifies how long a
dfree command output should be cached for. Default is zero (no caching).
Please test this out and let me know - I'm going to commit this into the code
Many thanks for the fast answer. We tried the source packages .20a from
sernet.de. We were not able to use it. Joining a domain had a segmentation fault
as result. Tomorrow we try .20b from sernet and/or a normal tar-file from samba.org.
The solution would be very good for us. I asked me, if its possible to have the
dfree cache time parameter in the global section, too? this would be nice.
If you have segfaults in our packages, tell us please! :-)
Any per-share parameter can be placed in the [global] section and it will apply
to all shares.
Changes already checked in. Closing.
Jeremy, please make sure to update the docs (dfree is no service
level and add new "dfree cache time" option).
Already added them to docs. Thanks for the reminder.
Sorry that our tests took so long. We just tested the patch with Samba 3.0.20b
and 3.0.21pre1 now, but it seems that the patch doesn't work. dfree is still
called to often - nearly every second. Tell us if you need any logfiles or
What did you add in your smb.conf ? You know you need to add
dfree cache time = 60
We added "dfree cache time = 60" in our smb.conf as a per service parameter and
we also tried it as a global parameter, but id didn't work.
Ok I'll work on this...
Created attachment 1555 [details]
Ok, add this one on top of the previous... It actually hooks up the new code to
the dfree routines. Sorry about that.
we tried the patches against samba 3.0.21pre1, but it does not work perfectly.
The patch works great when we use "dfree command" in a service section or in the
But the problem is that the "dfree command" is only executed once per share and
per person. When the "dfree cache time" is expired the command is not executed
again. This means that the size of free space on the share is only calculated
when you connect it first. Then the command is never executed again.
Created attachment 1564 [details]
Ok I'm an idiot. I added the code in the first patch, hooked it into the code
path in the second, and now in the final patch I'm remembering that "dfree
cache time" should return an *integer*, not a pointer to the address of the
parameter (no wonder it was large).
Sorry, it should work now.
we just tested the final patch against 3.0.21pre1. Now it works fine.
Finally fixed :-).