Enabling shadow_copy causes individual smbd processes to keep growing in size (I saw 350M) until system dies from memory starvation. This is easily reproduceable as there were no snapshots (@GMT-XXX) in the directory. Just enable it on a share, access the share, and watch the memory grow. Os is FreeBSD 5_STABLE, PIII 733, 128M Ram, 512M Swap, Gigabit, and plenty of disks. I would really love to have this working after getting snapshots working in FreeBSD, but I'm not sure how to debug this. If someone could give me some tips for debugging, I would be happy to try them. Jeb Campbell jebc@c4solutions.net
Ok, can you tell me exactly what you mean by "Just enable it on a share" ? How exactly do I do that on a Samba share ? All the mmc tools only allow that on a local drive. Thanks, Jeremy.
I followed the directions at: http://us2.samba.org/samba/docs/man/Samba-HOWTO-Collection/VFS.html#id2574280 [shadow_share] comment = Shadow Copy Enabled Share path = /data/shadow_share vfs objects = shadow_copy writeable = yes browseable = yes And with just "vfs objects = shadow_copy" (and with or without snapshots in the directory) the memory usage balloons. To make sure we are all on the same page, Samba's OS has to perform the snapshotting (Linux or FreeBSD), and Windows can request these special directorys (read only snapshots).
Ah ok - Now I understand, thanks. I was looking at the Microsoft "shadow copy" stuff, not our own vfs. My mistake :-). I'll try and track down the memory leak, thanks ! Jeremy.
Created attachment 889 [details] Proposed patch
Can you try the proposed patch please ? I think it makes sense, but I don't have a shadow copy setup to test it and it'll probably be quicker for you to test it on your setup. Thanks, Jeremy.
I will test and report as soon as I get to work in the morning, but it would make sense if something was not getting freed. Jeb
I can't edit the patch on here, but if you change: SAFE_FREE(disp->dirs); to SAFE_FREE(dirp->dirs); tt compiles and also appears to work! Of course I will keep an eye on it today, but memory is constant after opening a few files, where last time it would have shot up to +20M. Thanks so much for the help and patch! I will only post back if there is a problem.
The fix works great! (watch the typo in the current patch) Memory usage is stable after an hour and a half of normal usage. Do I resolve this bug to FIXED, or will whoever commits the fix resolve it? Thanks again, Jeb
Patch (with typo fixed :-) fixes the bug. Closing this one out. Jeremy.
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.