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 have now done a 'xfs_repair' using the code in GIT. It failed, and I
then did 'xfs_repair -L' which succeeded.
Am I correct that I should now be able to mount the sparse disk-image
file and see all the filenames? In that case I am quite worried. 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|
My guess is some superblock is corrupt and that it should instead try
a backup superblock. It might be useful if xfs_repair could do this
automatically based on the rule of thumb that more than 90% of
filenames/dirnames match:
[- _.,=A-Za-z0-9':]* [([{]* [- _.,=A-Za-z0-9':]* []})]* [- _.,=A-Za-z0-9':]*
If it finds a superblock resulting in more then 10% not matching the
above it should probably ignore that superblock (unless the file names
are using non-latin characters - such as Japanese).
/Ole
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
