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 desktop". 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 free space. 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. Jeremy.
Created attachment 1529 [details] Proposed patch 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 for 3.0.21. Jeremy.
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. sincerely yours michael
If you have segfaults in our packages, tell us please! :-) Volker
Any per-share parameter can be placed in the [global] section and it will apply to all shares. Jeremy.
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. Jeremy.
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 something. sincerely yours michael
What did you add in your smb.conf ? You know you need to add dfree cache time = 60 right ? Jeremy.
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... Jeremy.
Created attachment 1555 [details] Additional patch Ok, add this one on top of the previous... It actually hooks up the new code to the dfree routines. Sorry about that. Jeremy.
Hello, 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 global section. 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. Regards, Michael Arlt
Created attachment 1564 [details] Final patch 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. Jeremy.
Hello, we just tested the final patch against 3.0.21pre1. Now it works fine. Thanks Michael Arlt
Finally fixed :-). Jeremy.