Re: xfs_db problem

[Eric Sandeen <sandeen@sandeen.net>]

aluno wrote:
> Hello,
> 
> Recently we've noticed that xfs_admin (xfs_db ver. 2.10.2) causes
> segfault or FP traps while trying
> to use following command on FAT partition:
> 
> # xfs_admin -u /dev/sda1
> xfs_admin: unexpected XFS SB magic number 0xeb58906d
> Floating point exception
> 
> and then makes error in dmesg:
> 
> xfs_db[10385] trap divide error ip:80b32b0 sp:fffbd900 error:0 in
> xfs_db[8048000+7f000]
> 
> We know that xfs_admin is dedicated tool for XFS only not for FAT or
> other filesystems,
> but we would like to have xfs_db which will be able to cope with non-xfs
> filesystems also.
> 
> After some investigations we've found some place and put there exit(1) -
> in xfsprogs-2.10.2/db/init.c
> 
> in init() procedure:
> 
>     (...)
>         sbp = &xmount.m_sb;
>         if (sbp->sb_magicnum != XFS_SB_MAGIC) {
>                 fprintf(stderr, _("%s: unexpected XFS SB magic number
> 0x%08x\n"),
>                         progname, sbp->sb_magicnum);
>                 exit(1);
>         }
>     (...)
> 
> 
> 
> Is it the right way to fix this problem?

The thing is, xfs_db could in theory be used to *fix* the bad magic
number, so refusing to continue might be a problem.  But perhaps when
invoked as xfs_admin, it should just bail out.  It would be interesting
to find where the actual failure is, though...

FWIW, I see a slightly different failure on a 128M vfat fs:

[root@host tmp]# file fsfile
fsfile: x86 boot sector, mkdosfs boot message display
[root@host tmp]# xfs_admin -u fsfile
xfs_admin: unexpected XFS SB magic number 0xeb3c906d
xfs_admin: size check failed
xfs_admin: failed to alloc 20875030464 bytes: Cannot allocate memory

It probably depends on the details of the (non-xfs) filesystem it's
pointed at.

-Eric

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