Re: xfs_repair segfaults

[Eric Sandeen <sandeen@sandeen.net>]

On 3/12/13 5:41 AM, Ole Tange wrote:
> On Fri, Mar 8, 2013 at 9:32 PM, Eric Sandeen <sandeen@sandeen.net> wrote:
>> On 3/8/13 4:21 AM, Ole Tange wrote:
>>> On Mon, Mar 4, 2013 at 4:20 PM, Eric Sandeen <sandeen@sandeen.net> 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@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
> 

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs