Bug 2238 - VFS shadow_copy -- huge memory usage (leak?)
Summary: VFS shadow_copy -- huge memory usage (leak?)
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: File Services (show other bugs)
Version: 3.0.10
Hardware: All Windows XP
: P3 normal
Target Milestone: none
Assignee: Samba Bugzilla Account
QA Contact: Samba QA Contact
Depends on:
Reported: 2005-01-12 07:31 UTC by Jeb Campbell
Modified: 2005-08-24 10:18 UTC (History)
0 users

See Also:

Proposed patch (329 bytes, patch)
2005-01-13 19:52 UTC, Jeremy Allison
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jeb Campbell 2005-01-12 07:31:47 UTC
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
Comment 1 Jeremy Allison 2005-01-13 15:48:04 UTC
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.


Comment 2 Jeb Campbell 2005-01-13 17:43:02 UTC
I followed the directions at:

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).
Comment 3 Jeremy Allison 2005-01-13 18:38:42 UTC
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 !
Comment 4 Jeremy Allison 2005-01-13 19:52:12 UTC
Created attachment 889 [details]
Proposed patch
Comment 5 Jeremy Allison 2005-01-13 19:52:46 UTC
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.
Comment 6 Jeb Campbell 2005-01-13 20:28:35 UTC
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.

Comment 7 Jeb Campbell 2005-01-14 06:41:42 UTC
I can't edit the patch on here, but if you change:
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.
Comment 8 Jeb Campbell 2005-01-14 08:05:58 UTC
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,

Comment 9 Jeremy Allison 2005-01-14 13:22:09 UTC
Patch (with typo fixed :-) fixes the bug. Closing this one out.
Comment 10 Gerald (Jerry) Carter (dead mail address) 2005-08-24 10:18:38 UTC
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.