This is inspired by a thread last year when someone intended to collect metadata about filesystems and I would have been happy to help, except that I noticed lots of left-over data in the dump that should never have been there. I would not have worried that much about some fragments of Python code or directory listings, but the possibility of recognizable customer data (potentially even cryptographic keys) made it unthinkable to share this. My method of coming up with these patches was: Pipe a metadump of my reference image through "strings -n 10" and scroll until something recognizable catches my eye. This did not take too long, usually. Find the origin of the found leak and squash it (using "XFS File System Structure" from the wiki). Repeat until there is nothing recognizable left. Said image is a 1.1 TB volume created in early 2012 and used daily ever since on our development server, containing about 12 million inodes (mostly hundreds of checkouts of our main Mercurial repo with about 15000 files in it). I have not submitted a patch before, and I don't think I will be particularly pushy with this one. It exists mostly to inform you of my findings. I have not dealt at all with a v3 filesystem. TBH, I don't even know what this is and how to create one. Looking at the metadump code as it exists now, it would likely have been much safer to copy just the required contents as opposed to copying everything and then trying to find every nook and cranny where unwanted stuff could seep through. Stefan Ring (1): xfs_metadump: Zap more stale data db/metadump.c | 74 +++++++++++++++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 69 insertions(+), 5 deletions(-) -- 2.14.4
