On 3/12/13 5:41 AM, Ole Tange wrote: > On Fri, Mar 8, 2013 at 9:32 PM, Eric Sandeen <sandeen@xxxxxxxxxxx> wrote: >> On 3/8/13 4:21 AM, Ole Tange wrote: >>> On Mon, Mar 4, 2013 at 4:20 PM, Eric Sandeen <sandeen@xxxxxxxxxxx> wrote: >>> >>>> 2) so you could run a "real" non-"n" xfs_repair on a metadata image as a more realistic dry run > : >>> I get >>> filenames like: >>> >>> /mnt/disk/??5?z+hEOgl/?7?Psr1?aIH<?ip:??/>S??+??z=ozK/8_0/???d) >>> 5JCG?eiBd?EVsNF'A?v?m?f;Fi6v)d>/?M%?A??J?)B<soGlc??QuY!e-<,6G? >>> X[Df?Wm^[?f 4| >> >> By default, xfs_metadump scrambles filenames, so nothing to worry >> about (it's for privacy reasons). If you use the "-o" option it'll keep >> it in the clear. > > Ahh. To me that does not conform to Principle of Least Astonishment - > especially since some of the filenames were not obfuscated. > > I would have been less surprised if the files were named: > > Use_-o_for_real_file_names_XXXXXXXX > Use_-o_for_real_dir_names_XXXXXXXX > > where XXXXXXXX is just a unique number. That would completely change the actual on-disk metadata format, though, which would defeat the primary purpose of metadump. As it is, it preserves name lengths and name hashes, so that what is produced is an accurate representation of the original filesystem's metadata for analysis. This is described in the manpage, though I sympathize that it's a bit alarming the first time you see it in the dump output, if you weren't aware. -Eric > > /Ole > > _______________________________________________ > xfs mailing list > xfs@xxxxxxxxxxx > http://oss.sgi.com/mailman/listinfo/xfs > _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
