Unexpected XFS SB number 0x00000000

Unexpected XFS SB number 0x00000000

[Martin Eisenhardt]

[-- Attachment #1: Type: text/plain, Size: 878 bytes --]

Hello list(s),

I run XFS on a software raid on Linux 2.6.19. When I invoke xfs_db in 
read-only mode, I get:

# xfs_db -r /dev/md0
xfs_db: unexpected XFS SB magic number 0x00000000
xfs_db: read failed: Invalid argument
xfs_db: data size check failed
Segmentation fault

The system is still running, the filesystem seems to be fine (except for the 
above): files are created, written, and deleted without any problem.

So, I have two questions:

* Is there a real problem, or might a quick reboot solve this?
* If there is a real problem with the file system: What steps do you recommend 
to overcome this problem?
* How safe is it to run xfs_check and xfs_repair?

Thanks in advance!

Kind regards
Martin Eisenhardt

P.S.: Sorry for cross-posting, I just figure that maybe the XFS users on 
non-linux systems might have a hint or two for me ... ;-)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Unexpected XFS SB number 0x00000000

[Nathan Scott]

On Thu, 2007-04-26 at 21:46 +0200, Martin Eisenhardt wrote:
> Hello list(s),
> 
> I run XFS on a software raid on Linux 2.6.19. When I invoke xfs_db in 
> read-only mode, I get:
> 
> # xfs_db -r /dev/md0
> xfs_db: unexpected XFS SB magic number 0x00000000
> xfs_db: read failed: Invalid argument
> xfs_db: data size check failed
> Segmentation fault

I think this segfault is fixed in recent xfs_db versions.

> The system is still running, the filesystem seems to be fine (except for the 
> above): files are created, written, and deleted without any problem.
> 
> So, I have two questions:
> 
> * Is there a real problem, or might a quick reboot solve this?

It looks like a real problem to me - something has written zeroes to
the start of your partition, where the primary XFS superblock should
be.  If the filesystem is still mounted(?), I'd
a/ make a backup copy of anything/everything precious there
b/ try to get the incore copy of the XFS superblock flushed out (this
assumes still mounted) - creater a file & use sync(1) - you might get
lucky.

> * If there is a real problem with the file system: What steps do you recommend 
> to overcome this problem?
> * How safe is it to run xfs_check and xfs_repair?

If you really have zeroes over your primary superblock, xfs_repair
is your only option to fix that really (after unmounting).  You
wont get much joy from xfs_check, as its just a shell script wrapper
around the xfs_db "check" command.

> P.S.: Sorry for cross-posting, I just figure that maybe the XFS users on 
> non-linux systems might have a hint or two for me ... ;-)

Theres only one list (both addresses point to the same place).

cheers.

-- 
Nathan

Unexpected XFS SB number 0x00000000

[Chris]

Hello!

I'm running a home file server with Debian GNU/Linux 4.0 4.0r1 etch
(2.6.18-5-amd64 Kernel) and an Areca ARC-1220 hardware RAID controller.
I used to have 4 750GB HDDs connected and set up as RAID 5 array, single
volume, single XFS partition (set up during the installation of Debian). No
problems so far.

Now I added another 750GB HDD to the array, online capacity/volume expansion
by the controller finished just fine.
My plan was to add the extra space to the above mentioned XFS partition. So
I unmounted the partition, started cfdisk, removed the partition table and
wrote a new one that included the new free space. 
After rebooting the partition wasn't mounted, so I couldn't use xfs_growth
to expand the filesystem.  

xfs_check: unexpected XFS SB magic number 0x00000000

xfs_repair -n:
Phase 1 - find and verify superblock...
bad primary superblock - bad magic number !!!
attempting to find secondary superblock.......[...].............found
candidate secondary superblock...unable to verify superblock,
continuing..........[...]................
.......Sorry, could not find valid secondary superblock
Exciting now.

I realize the magic number 0x00000000 is probably not a good thing and maybe
using fdisk to write a new table was not the way to do it?
Any suggestions on restoring the old partition table / magic number or how
to proceed? Is there an easy fix or is this a serious problem?

Kind Regards,
Chris

Re: Unexpected XFS SB number 0x00000000

[Eric Sandeen]

Chris wrote:
> Hello!
> 
> I'm running a home file server with Debian GNU/Linux 4.0 4.0r1 etch
> (2.6.18-5-amd64 Kernel) and an Areca ARC-1220 hardware RAID controller.
> I used to have 4 750GB HDDs connected and set up as RAID 5 array, single
> volume, single XFS partition (set up during the installation of Debian). No
> problems so far.
> 
> Now I added another 750GB HDD to the array, online capacity/volume expansion
> by the controller finished just fine.
> My plan was to add the extra space to the above mentioned XFS partition. So
> I unmounted the partition, started cfdisk, removed the partition table and
> wrote a new one that included the new free space. 
> After rebooting the partition wasn't mounted, so I couldn't use xfs_growth
> to expand the filesystem.  
> 
> xfs_check: unexpected XFS SB magic number 0x00000000

Did your new partition table start in exactly the same place?

Can you find the string "XFSB" anywhere near where your old partition
started?

-Eric

Re: Unexpected XFS SB number 0x00000000

[Justin Piszcz]

On Mon, 10 Dec 2007, Chris wrote:

> Hello!
>
> I'm running a home file server with Debian GNU/Linux 4.0 4.0r1 etch
> (2.6.18-5-amd64 Kernel) and an Areca ARC-1220 hardware RAID controller.
> I used to have 4 750GB HDDs connected and set up as RAID 5 array, single
> volume, single XFS partition (set up during the installation of Debian). No
> problems so far.
>
> Now I added another 750GB HDD to the array, online capacity/volume expansion
> by the controller finished just fine.
> My plan was to add the extra space to the above mentioned XFS partition. So
> I unmounted the partition, started cfdisk, removed the partition table and
> wrote a new one that included the new free space.
> After rebooting the partition wasn't mounted, so I couldn't use xfs_growth
> to expand the filesystem.
>
> xfs_check: unexpected XFS SB magic number 0x00000000
>
> xfs_repair -n:
> Phase 1 - find and verify superblock...
> bad primary superblock - bad magic number !!!
> attempting to find secondary superblock.......[...].............found
> candidate secondary superblock...unable to verify superblock,
> continuing..........[...]................
> .......Sorry, could not find valid secondary superblock
> Exciting now.
>
> I realize the magic number 0x00000000 is probably not a good thing and maybe
> using fdisk to write a new table was not the way to do it?
> Any suggestions on restoring the old partition table / magic number or how
> to proceed? Is there an easy fix or is this a serious problem?
>
> Kind Regards,
> Chris
>
>

When I grew mine, I used mdadm/raid5, expanded the array and then you run 
xfs_growfs on the mounted filesystem and it worked.

Wiping out the partition is not the way to do it.

Justin.

Re: Unexpected XFS SB number 0x00000000

[Chris]

> > Did your new partition table start in exactly the same place?
> >
>
> I assumed it would be in the same place...
> I guess there is no way to find out what the old one looked like?
>
> > Can you find the string "XFSB" anywhere near where your old partition
> > started?
> >
>
> I can try to do so...how? :)
> When I look into the partition with cfdisk, I can see what
cylinders/heads/sectors it uses. But I'm > sure there are other tools?
>
> Interestingly, after a reboot cfdisk shows me a 801575.31 MB partition and
2199023.26 MB free space, > although I wrote a single partition of
3000598.57 MB into the table before rebooting.

I just tested some more and using parted found out the following:

(parted) print
Warning: /dev/sdb contains GPT signatures, indicating that is has a GPT
table. However, it does not have a valid fake msdos partition table, as it
should. Perhaps it was corrupted --  possibly by a program that doesn't
understand GPT  partition tables. Or perhaps you deleted the GPT table, and
are now using an msdos partition table. Is this a GPT partition table?
Yes/No? y

Disk /dev/sdb: 3001GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number	Start		End		Size		File system	Name
Flags
1		17.4kB 	22250GB 	22250GB 	xfs


So it seems that parted can still "see" the old table. But it doesn't have
support for resizing xfs partitions...

Re: Unexpected XFS SB number 0x00000000

[Eric Sandeen]

Chris wrote:

> I just tested some more and using parted found out the following:
> 
> (parted) print
> Warning: /dev/sdb contains GPT signatures, indicating that is has a GPT
> table. However, it does not have a valid fake msdos partition table, as it
> should. Perhaps it was corrupted --  possibly by a program that doesn't
> understand GPT  partition tables. Or perhaps you deleted the GPT table, and
> are now using an msdos partition table. Is this a GPT partition table?
> Yes/No? y
> 
> Disk /dev/sdb: 3001GB
> Sector size (logical/physical): 512B/512B
> Partition Table: gpt
> 
> Number	Start		End		Size		File system	Name
> Flags
> 1		17.4kB 	22250GB 	22250GB 	xfs
> 
> 
> So it seems that parted can still "see" the old table. But it doesn't have
> support for resizing xfs partitions...

So, did you originally have a gpt or an msdos partition table?

Re: Unexpected XFS SB number 0x00000000

[Chris]

Seems like using parted to write a new partition table did the job for me.
Used 17.4kB as start and 3000GB as end.
Now being able to mount the partition successfully I ran xfs_growfs.
Afterwards, I still had to do an xfs_repair though, because there were a lot
of (seemingly) random errors when accessing certain files.
Everthing normal now...