can't read superblock on a xfs partition

[Nicolas]

Hi,

I have a big problem with a xfs partition, i have made a very big
mistake when i was typing the xfs_growfs command and now the partition
are not able to mount due to a superblock failure, of course i didn't
made backup :/

- I use xfs over lvm with xfs version 2.6.25 and try xfs 2.7.3too

The mistake :
- I made :
lvextend -L +100G /dev/jbod2/export
xfs_growfs /export
*sic*
( in place of : xfs_growfs /dev/jbod2/export )

My xfs partition was previously mounted on /export

So ... i start to panic, and then to think :
- I do a :
xfs_repair -n -o assume_xfs /dev/jbod2/export
( with alternatively -n and -o assume_xf options )

The output is :

Phase 1 - find and verify superblock...
error reading superblock 3 -- seek to offset 82431049728 failed
couldn't verify primary superblock - bad magic number !!!

attempting to find secondary superblock...
...
...
...
found candidate secondary superblock...
error reading superblock 3 -- seek to offset 82431049728 failed
unable to verify superblock, continuing...
...
...
...
found candidate secondar
y superblock...
error reading superblock 3 -- seek to offset 82431049728 failed
unable to verify superblock, continuing...
...
...
...
Sorry, could not find valid secondary superblock
Exiting now.


I have this message in my syslog :
attempt to access beyond end of device
dm-0: rw=0, want=1717313536, limit=121118720
I/O error in filesystem ("dm-0") meta-data dev dm-0 block 0x665c1fff

("xfs_read_buf") error 5 buf count 512

XFS: size check 2 failed

# xfs_check /dev/jbod2/export
XFS: totally zeroed log
can't seek in filesystem at bb 125297920
can't read block 0 for directory inode 167128840
no . entry for directory 167128840
no .. entry for directory 167128840
/bin/xfs_check: line 56: 5657 Segmentation fault xfs_db$DBOPTS -i
-p xfs_check -c "check$OPTS" $1

# xfs_admin -l -u /dev/jbod2/export
can't seek in filesystem at bb 160998144
can't read superblock for AG 3
failed to read label in AG 3
can't seek in filesystem at bb 160998144
can't read superblock for AG 3
failed to read UUID from AG 3


Did a small solution exist to recover of this superblock failure or will
i have to considere that my data are lost ? I apologize for these
questions, i havn't a lot of experience in xfs use, but if anyone could
give me a solution, i will greatly appreciate it.

Regards,

Nicolas

[Enrique Perez-Terron]

Post by Nicolas
Hi,
I have a big problem with a xfs partition, i have made a very big
mistake when i was typing the xfs_growfs command and now the partition
are not able to mount due to a superblock failure, of course i didn't
made backup :/
- I use xfs over lvm with xfs version 2.6.25 and try xfs 2.7.3too
lvextend -L +100G /dev/jbod2/export
xfs_growfs /export
*sic*
( in place of : xfs_growfs /dev/jbod2/export )
My xfs partition was previously mounted on /export

This is strange.

If xfs_growfs does not check the type of the specified file, it will
try to operate on the file given, in this case a directory. It must
open the given file read-write, as it has to look at the superblock
to determine what changes needs to be done, and it has to do the
changes. However, opening a directory for read-write fails with
EISDIR (21, Is a directory)!!

If you think back, can you remember anything else that could explain
the errors? It is always better to work from a correct hypotesis about
the nature of the problem.

Unfortunately i know noting about xfs, so I don't know how to repair
it.

In any case, if you have any medium (tape) that is large enough, I
would start with a backup of the raw disk devices, so I could always
start over bringing the disks back to the current state, in case I
did something stupid while attempting to rescue things.

Given the list of messages below, It looks like it is already beyond
repair. I would presume that the repair tool is written with a good
knowledge about the structure of the fs, and stepping through the
data structures by hand is not likely to be much better. However,
if there is serious doubt about what exactly has happened, and what
is really the current state of affairs, it might be an idea to read
up on the xfs data structures, and begin exploring the disk with
a hex dump/edit tool. You also have the lg and lv layers, so you
might need to make sure you understand those structures first, and
make sure the on-disk lg/lv structures are sound.

Post by Nicolas
xfs_repair -n -o assume_xfs /dev/jbod2/export
( with alternatively -n and -o assume_xf options )
Phase 1 - find and verify superblock...
error reading superblock 3 -- seek to offset 82431049728 failed
couldn't verify primary superblock - bad magic number !!!

A huge number. I still don't know anything about xfs, but it surprises
me that the third superblock resides at such a high address. If that
is what it means; superblock 3 - primary superblock???

Post by Nicolas
attempting to find secondary superblock...
...
...
...
found candidate secondary superblock...
error reading superblock 3 -- seek to offset 82431049728 failed
unable to verify superblock, continuing...
...
...
...
found candidate secondar
y superblock...
error reading superblock 3 -- seek to offset 82431049728 failed
unable to verify superblock, continuing...
...
...
...
Sorry, could not find valid secondary superblock
Exiting now.
attempt to access beyond end of device
dm-0: rw=0, want=1717313536, limit=121118720
I/O error in filesystem ("dm-0") meta-data dev dm-0 block 0x665c1fff
("xfs_read_buf") error 5 buf count 512
XFS: size check 2 failed
# xfs_check /dev/jbod2/export
XFS: totally zeroed log
can't seek in filesystem at bb 125297920
can't read block 0 for directory inode 167128840
no . entry for directory 167128840
no .. entry for directory 167128840
/bin/xfs_check: line 56: 5657 Segmentation fault xfs_db$DBOPTS -i
-p xfs_check -c "check$OPTS" $1
# xfs_admin -l -u /dev/jbod2/export
can't seek in filesystem at bb 160998144
can't read superblock for AG 3
failed to read label in AG 3
can't seek in filesystem at bb 160998144
can't read superblock for AG 3
failed to read UUID from AG 3
Did a small solution exist to recover of this superblock failure or will
i have to considere that my data are lost ? I apologize for these
questions, i havn't a lot of experience in xfs use, but if anyone could
give me a solution, i will greatly appreciate it.

This is just my two cents, mostly out of ignorance, but my gut feeling is
that there could have happened something to the logical volume.

-Enrique

[Enrique Perez-Terron]

Post by Nicolas
- I use xfs over lvm with xfs version 2.6.25 and try xfs 2.7.3too
lvextend -L +100G /dev/jbod2/export
xfs_growfs /export
*sic*
( in place of : xfs_growfs /dev/jbod2/export )

Another thought: Is there any chance that xfg_growfs is intelligent
enough to determine what device contains the specified directory,
i.e., that xfs_growfs was in the middle of doing just the right
thing, but you interrupted it when you realized your mistake?

If that is the actual problem, it may be possible to construct a
solution, if the data are sufficiently valuable, by studying the
order of the operations of xfs_growfs, and looking at the data on
the disks.

-Enrique