contrib: add negdentdelete.py script

[brenns10]

The script is described in the docstring, but this is an interesting approach to target a directory and remove all negative dentries within it. The secret sauce is doing an open(..., O_CREAT), then unlink() then close(). This ensures that the dentry for this file will be freed on close() rather than left as a negative dentry.

You can test it out pretty easily using my negdentcreate tool. Here's an example.

stepbren at stepbren-ol9 in ~/repos/drgn (negdentdelete)
$ sudo slabtop -o | grep dentry
1244754 1243379  99%    0.19K  29637       42    237096K dentry

stepbren at stepbren-ol9 in ~/repos/drgn (negdentdelete)
$ mkdir tmp

stepbren at stepbren-ol9 in ~/repos/drgn (negdentdelete)
$ ./negdentcreate -p tmp/ -c 200000 -t 4
progress:     200000/    200000
done! waiting on threads

stepbren at stepbren-ol9 in ~/repos/drgn (negdentdelete)
$ sudo slabtop -o | grep dentry
1443414 1443368  99%    0.19K  34367       42    274936K dentry

stepbren at stepbren-ol9 in ~/repos/drgn (negdentdelete)
$ drgn contrib/negdentdelete.py tmp/
removed 200000 negative dentries in 1.98s (100815.77/s)

stepbren at stepbren-ol9 in ~/repos/drgn (negdentdelete)
$ sudo slabtop -o | grep dentry
1245342 1243903  99%    0.19K  29651       42    237208K dentry

[osandov]

Really neat, thanks!

[wenjianhn]

I'd like to share how we delete negative dentries of hundreds of servers.

1. find out the source by drgn.helpers.linux.slab: add support for retrieving objects exclusive… #306
2. a daily cron job deletes them with the help of a kernel module that calls shrink_dcache_parent(dentry)

[brenns10]

That's definitely a great way to go about it. I've dabbled with kernel modules to free dentries too. Using shrink_dcache_parent() is smart. With my modules, I tried to target all dentries on the system (not those contained in a single directory) and the - result was not very effective. I bet yours works much better :)

That said, kernel modules can't be easily used with secure boot/lockdown, and they are definitely riskier since they run in kernel space and take locks that other tasks may need. That said, this approach is probably orders of magnitude slower than a kernel module! Good to have both approaches.

Thanks for sharing!