Andrea Gelmini posted on Mon, 24 Jun 2013 18:45:39 +0200 as excerpted: > 2013/6/24 Josef Bacik <jbacik@xxxxxxxxxxxx>: >> Could you make an image of this fs for me and upload it somewhere so I >> can pull it down and run some stuff on it? I've > > n.b.: I've got a lot of sensible/private data in my home, but maybe we > could find a way to give all to you. I'm not so afraid to trust you. FWIW, I just updated btrfs-progs from git, and one of the new commits allows anonymizing filenames (actual file data/content hasn't been in the image, which I believe is meta-data only, either ever or at least for some time, but filenames can be sensitive too). There's even two different modes that can be used to do it, a fast "random name of the same length" mode, and a much, MUCH slower "find a crc32c hash collision of the same length and use it" mode. (The commit noted that on new Intel hardware with hardware crc accel, it took two plus minutes to find a collision for a single text string, three-plus minutes without that hardware accel, so doing the math, on a filesystem with even moderate thousands of files, the long one's likely to take days to generate. Obviously this will only be used on relatively small filesystems troubleshooting problems where the fast method doesn't give a useful result.) So if you can build a current git btrfs-progs, you should be able to try at least the fast version, and reasonably anonymize even the filenames. =:^) If filenames aren't a problem, then certainly anything even reasonably current should deliver an image with in-the-clear filenames, but no content to worry about. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
