Re: Should xfs_repair take this long?

[Thomas Walker <walker@stsci.edu>]

     I see in other posts that "parted" is sometimes a culprit in these 
problems.  Indeed, in my case I did use "parted" to create a gpt 
partition table on these xfs volumes and I was asked my parted to use 
the secondary signature.

--- snip ---

i also remember something about parted (maybe...) finding a backup gpt
signature at the end of a disk, and "helpfully" copying it over the
front end if so.  This was a bug.  sgi guys do you remember?
    

But for this one has to invoke parted, and commit the operations done,
am I right?
  

if I recall, even invoking parted could do this.
--- snip ---

 

   So maybe I got bit the same way.  parted may be overwritten something 
at the head of the volume.  Is there any way to repair the super block 
though?  It seems that everyone agrees xfs can't do anything until it 
has a super block somewhere and I don't seem to have one.  If there's no 
way to repair, then what about recovery?  I see mention of possibly 
doing an xfs dump to another disk, reformat the original volume, and 
then xfs restore back.  Is there any online procedure for how to do that 
if it applies to me here?

   Thomas Walker

David Chinner wrote:

>On Thu, Mar 15, 2007 at 10:06:42AM -0400, Thomas Walker wrote:
>  
>
>>    The terminal shows a lot of "." dots running across the screen 
>>quickly, and every few hours it says this;
>>
>>
>>.....................................................found candidate 
>>secondary superblock...
>>unable to verify superblock, continuing...
>>found candidate secondary superblock...
>>unable to verify superblock, continuing...
>>    
>>
>
>The primary superblock is not good, and it's trying to find a valid
>secondary superblock. Doesn't sound promising so far - reapir can't
>start until a valid superblok is found....
>
>
>  
>