Le mercredi 15 juillet 2015, 17:12:35 Rogério Brito a écrit : > Yes, that solves it.
Thanks for checking this. > > I see you are using "--ignore /home", which is what well everybody should do > > to avoid that /home got scanned *twice* only just to detect broken symlinks > > & non-owned files. > > I didn't know that the current implementation of cruft did these things > twice, which I guess that could be done in just one pass (that could be done > with essentially a few lines with just a few calls to stat). But this is mostly written in shell / perl with helper functions in C. I didn't knew where to start without breaking it altogether; that's why I rewrote it in C. cruft compute on one side a list of all the files actualy on the system with find; and then run a handfull of plug-in scripts to generate a list of files that should be there. /usr/lib/cruft/explain/dpkg lists files owned by dpkg, and /usr/lib/cruft/explain/USERS lists (again) all the files under /home (minus broken symlinks) > Besides that, doing those things in two passes requires going to the disk > twice, which is bad from both the latency and caching (if many files are to > be scanned), especially if the system is constrained in memory (like my NAS > with only 128MB of which there is essentially 10MB usable at any given time, > due to the kernel reserving memory and other programs running). Ouch, original cruft spools everything to /var/spool; there is even a bug repport that says it consumes 15MB of disk space & that's too much: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=50731 My rewrite keeps everything in memory (that why also most of options becomes useless), so the memory usage is directly linked to # of files installed. https://github.com/a-detiste/cruft-ng/wiki/Benchmark See: cruft / maxresident : 12544k -> 12552k cruft-ng / maxresident: 8756k -> 53352k so this could either use less memory or OOM your device :-( depending on the number of files more stats: du -h /var/lib/mlocate/mlocate.db desktop: 23M RPi: 2,4M > > I was really tempted to make it the default behaviour, but I don't want to > > break users expectations either. > > Do a few releases of cruft and state (when the user executes the program) > that the current behavior is going to be deprecated and changed in a future > release with the "space" between the deprecation warning being one Debian > release (i.e., jessie+1). It's not really a problem to keep both packages for a while. > > For cruft-ng (my rewrite of the shell/perl/c engine in C++); > > I just never scan further that the first level in /home; > > and avoid /tmp altogether. > > That sounds like a good plan, but please, state clearly the differences in > behavior in the documentation. This documented in the project homepage that was written before the package got in the archive https://github.com/a-detiste/cruft-ng This is installed at /usr/share/doc/cruft-ng/README.md Now some of this could go in cruft-ng manpage. > > and tool can be indirectly configured by tweaking mlocate's > > /etc/updatedb.conf . > > Hummm, here we have a problem: not all users have even mlocate installed > (it's one of the first packages that I purge from my systems whenever I > install them). > > I wouldn't want to have a cron job running every day to update the list of > files that I have. The "one time" hit of running cruft (or cruft-ng, or > whatever) every now and then is acceptable, but the hit of running a cron > job every day (or weekly or whatever) is not something that I like to have. Original locate that is just a wrapper around find was a pain; and, as I wasn't reading the NEWS / release notes, I was stuck with it years after mlocate had become the new default. mlocate, by working in delta-mode, is much faster. You can also "chmod -x /etc/cron.daily/mlocate" ; cruft-ng will still call it once as needed during it's run. see updatedb() at https://github.com/a-detiste/cruft-ng/blob/master/cruft.cc#L51 is now just a stub, with an old comment in French saying that it could detect mlocate / dpkg last run. > But I guess that we can discuss these tangential points in another thread, > so as to not pollute this but report. :) I guess nobody else read this. ;-) > I'm happy to give you my intended usage patterns, so that you can > incorporate them into cruft-ng. I didn't thought of running it with ultra-low memory. Thanks, Alexandre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
