On Tue, Mar 06, 2007 at 10:44:55AM -0500, Theodore Tso wrote: > Yikes, what blkid function is rpc.mountd calling all the time which is > causing this kind of memory leakage?
blkid_probe_all_new() seems to be the one. It happens at every mount and umount, I believe; it's not like it's being called all the time (it leaks much faster on busy systems than on almost idle systems, AFAICS), it's that it leaks so _much_ memory all the time. > Oh, I see, because nfs-kernel-server 1.0.10 is in testing, and 1.0.12 > is in unstable. I assume it's unlikely that nfs-kernel-server 1.0.12 > is going to migrate to testing? I was originally planning to ask for an exception (with associated RM bribes, the diff is quite large), but given 1.0.11's and 1.0.12's track record so far, I think that's quite far-fetched, yes. > OK, release managers, the memory leak primarily occurs in the device > mapper probing code, and an additional leak when there is a partition > which does not have a valid filesystem known to blkid. rpc.mountd is, > as far as I know, the first long-lived daemon using blkid, and it's > apparently using it in a somewhat "interesting" way which is the > system to constantly reprobe the disk information (if it is leaking > megabytes per minute). The patch looks reasonably sane and low risk > based on a on-paper examination of the code changes --- but if > nfs-kernel-server 1.0.12 isn't going into etch, I'd say it's > borderline whether or not we include this patch into the e2fsprogs > upload I was about to do. FWIW, I agree with this analysis, possibly except the part about mountd's usage pattern. :-) /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
