XFS: SB validate failed

XFS: SB validate failed

[Spam Magnet]

Hello there :)

I have a Iomega Jaz cartrdige which seems to be formatted in xfs under
Irix 6.5.
When I insert the cartridge in a drive attached to an Octane machine
(running IRIX 6.5) I get an error message saying that the drive could not
be mounted:
The file system on device: /dev/dsk/dks1d3s7 cannot be mounted

I connected the Jaz drive to a Linux box using a SCSI-to-USB
adapter. When I do a fdisk I get:

$ sudo fdisk -l /dev/sdb

Disk /dev/sdb (SGI disk label): 33 heads, 62 sectors, 1022 cylinders
Units = cylinders of 2046 * 512 bytes

----- partitions -----
Pt#    Device  Info     Start       End   Sectors  Id  System
 8: /dev/sdb1               2      1021   2087936   a  SGI xfs
 9: /dev/sdb2               0         1      3072   0  SGI volhdr
11: /dev/sdb3               0      1021   2091008   6  SGI volume
----- Bootinfo -----
Bootfile: /unix
----- Directory Entries -----
 0: sgilabel   sector    3 size     512

But trying to mount the device fails:

$ sudo mount -t xfs /dev/sdb /mnt
$ sudo mount -t xfs /dev/sdb8 /mnt
$ sudo mount -t xfs /dev/sdb11 /mnt

Checking the log messages, I get:
[6815277.617579] XFS: bad magic number
[6815277.617587] XFS: SB validate failed

(I found similar problems reported here
http://osdir.com/ml/security.forensics/2006-04/msg00025.html)
# /usr/sysadm/privbin/getDiskParts -d dks1d3vol
7:10:3072:2087936;8:0:0:3072;10:6:0:2091008;

I also tried to use xfs_check and xfs_repair.
xfs_check crashes:
/usr/sbin/xfs_check: line 28: 25216 Segmentation fault
(core dumped) xfs_db$DBOPTS -i -p xfs_check -c "check$OPTS" $1

and xfs_repair reports that:
bad primary superblock - bad magic number !!!
attempting to find secondary superblock
Sorry, could not find valid secondary superblock
Exiting now.

My questions:
1-Is this related to the information stated in FAQ regarding
XLV support or v2 directories under Irix ?
2-Do I need to be concerned about byte ordering when it comes
to how the partition table info are stored on my Jaz cartridge ?
3-If this is a corrupt partition problem, would you suggest that
I attempt to fix it under Irix or the Linux xfs tools will be sufficient ?

I'd really appreciate any input that can help me resolve this issue.

thanks in advance.

Re: XFS: SB validate failed

[Eric Sandeen]

Spam Magnet wrote:
> Hello there :)
> 
> I have a Iomega Jaz cartrdige which seems to be formatted in xfs under
> Irix 6.5.
> When I insert the cartridge in a drive attached to an Octane machine
> (running IRIX 6.5) I get an error message saying that the drive could not
> be mounted:
> The file system on device: /dev/dsk/dks1d3s7 cannot be mounted
> 
> I connected the Jaz drive to a Linux box using a SCSI-to-USB
> adapter. When I do a fdisk I get:
> 
> $ sudo fdisk -l /dev/sdb
> 
> Disk /dev/sdb (SGI disk label): 33 heads, 62 sectors, 1022 cylinders
> Units = cylinders of 2046 * 512 bytes
> 
> ----- partitions -----
> Pt#    Device  Info     Start       End   Sectors  Id  System
>  8: /dev/sdb1               2      1021   2087936   a  SGI xfs
>  9: /dev/sdb2               0         1      3072   0  SGI volhdr
> 11: /dev/sdb3               0      1021   2091008   6  SGI volume

I can't remember how sgi disklabels work under linux; does this show up
as /dev/sdb8 /dev/sdb9 /dev/sdb11 or  as /dev/sdb1 /dev/sdb2 /dev/sdb3
in linux?

Look at /proc/partitions...

point file -s at /dev/sdb$WHATEVER

see if any of them say "xfs"

and try to mount that :)

-Eric

Re: XFS: SB validate failed

[Spam Magnet]

On Thu, May 29, 2008 at 1:19 PM, Eric Sandeen <sandeen@sandeen.net> wrote:
> Spam Magnet wrote:
>> Hello there :)
>>
>> I have a Iomega Jaz cartrdige which seems to be formatted in xfs under
>> Irix 6.5.
>> When I insert the cartridge in a drive attached to an Octane machine
>> (running IRIX 6.5) I get an error message saying that the drive could not
>> be mounted:
>> The file system on device: /dev/dsk/dks1d3s7 cannot be mounted
>>
>> I connected the Jaz drive to a Linux box using a SCSI-to-USB
>> adapter. When I do a fdisk I get:
>>
>> $ sudo fdisk -l /dev/sdb
>>
>> Disk /dev/sdb (SGI disk label): 33 heads, 62 sectors, 1022 cylinders
>> Units = cylinders of 2046 * 512 bytes
>>
>> ----- partitions -----
>> Pt#    Device  Info     Start       End   Sectors  Id  System
>>  8: /dev/sdb1               2      1021   2087936   a  SGI xfs
>>  9: /dev/sdb2               0         1      3072   0  SGI volhdr
>> 11: /dev/sdb3               0      1021   2091008   6  SGI volume
>
> I can't remember how sgi disklabels work under linux; does this show up
> as /dev/sdb8 /dev/sdb9 /dev/sdb11 or  as /dev/sdb1 /dev/sdb2 /dev/sdb3
> in linux?
>
> Look at /proc/partitions...
>
> point file -s at /dev/sdb$WHATEVER
>
> see if any of them say "xfs"
>
> and try to mount that :)

Thanks for your response.
Linux shows them as /dev/sdb8 /dev/sdb9 and /dev/sdb11
and none of them are mountable :(

To narrow down the problem, I formatted a clean, error free disk
under SGI(Irix 6.5). Its partition table looks like:

#  prtvtoc /dev/dsk/dks1d3vol
* /dev/dsk/dks1d3vol (bootfile "/unix")
*     512 bytes/sector
Partition  Type  Fs   Start: sec    Size: sec   Mount Directory
 7          xfs  yes        4096      3911504
 8       volhdr                0         4096
10       volume                0      3915600

Now if I connect the same disk to Linux and run fdisk I get the
similar info:
Disk /dev/sdb (SGI disk label): 255 heads, 63 sectors, 0 cylinders
Units = sectors of 1 * 512 bytes

----- partitions -----
Pt#   Device  Info     Start       End   Sectors  Id  System
 8: /dev/sdb1            4096   3915599   3911504   a  SGI xfs
 9: /dev/sdb2               0      4095      4096   0  SGI volhdr
11: /dev/sdb3               0   3915599   3915600   6  SGI volume
----- Bootinfo -----
Bootfile: /unix
----- Directory Entries -----
 0: sgilabel   sector    2 size     512

Again mounting /dev/sdb1 or /dev/sdb8 gives error:
mount: wrong fs type, bad option, bad superblock on /dev/sdb8

and system logs:
XFS: bad magic number
XFS: SB validate failed

So can this be related to the byte ordering or any of the other
issues mentioned in the FAQ regarding xfs under Linux ?
How can I figure out if my disk is using XLV or is a v2 directory ?

Thanks again

Re: XFS: SB validate failed

[Eric Sandeen]

Spam Magnet wrote:

> So can this be related to the byte ordering or any of the other
> issues mentioned in the FAQ regarding xfs under Linux ?
> How can I figure out if my disk is using XLV or is a v2 directory ?

Byte ordering is only an issue for the log replay; you'd get a message
about that if it were the issue.

Does file -s /dev/sdb? say that any of those things even look like an
xfs filesystem?

If so point xfs_db at it like:

xfs_db -r -c "sb 0" -c "p" /dev/sdb<whatever>

that'll tell you if it has v1 dirs I think.

-Eric

Re: XFS: SB validate failed

[Spam Magnet]

> Byte ordering is only an issue for the log replay; you'd get a message
> about that if it were the issue.
>
> Does file -s /dev/sdb? say that any of those things even look like an
> xfs filesystem?
>
> If so point xfs_db at it like:
>
> xfs_db -r -c "sb 0" -c "p" /dev/sdb<whatever>
>
it's indeed an xfs filesystem:
$ sudo file -s /dev/sdb8
/dev/sdb8: SGI XFS filesystem data (blksz 4096, inosz 256, v2 dirs)

And this is output of xfs_db:

magicnum = 0x58465342
blocksize = 4096
dblocks = 488936
rblocks = 0
rextents = 0
uuid = bc45ebf5-b625-102c-8d9d-0800690be5b3
logstart = 262148
rootino = 128
rbmino = 129
rsumino = 130
rextsize = 16
agblocks = 61117
agcount = 8
rbmblocks = 0
logblocks = 1200
versionnum = 0x3084
sectsize = 512
inodesize = 256
inopblock = 16
fname = "\000\000\000\000\000\000\000\000\000\000\000\000"
blocklog = 12
sectlog = 9
inodelog = 8
inopblog = 4
agblklog = 16
rextslog = 0
inprogress = 0
imax_pct = 25
icount = 64
ifree = 53
fdblocks = 486371
frextents = 0
uquotino = 0
gquotino = 0
qflags = 0
flags = 0
shared_vn = 0
inoalignmt = 2
unit = 0
width = 0
dirblklog = 0
logsectlog = 0
logsectsize = 0
logsunit = 0
features2 = 0

I can mount and see the content of this disk: using:
mount -t xfs /dev/sdb8 /mnt

But xfs_check still crashes on me :(
/usr/sbin/xfs_check: line 28: 26782 Segmentation fault (core dumped)
xfs_db$DBOPTS -i -p xfs_check -c "check$OPTS" $1

Will it be ok if I made a 1:1 image of my disks under Irix (using dd):

$ dd if=/dev/dsk/dks1d3vol of=disk.img bs=512 conv=ignerror,sync

And tried to use xfs module in Linux to mount them ? or this programs
are only meant to work with actual device rather than an image file ?

thanks for your patience

Re: XFS: SB validate failed

[Eric Sandeen]

Spam Magnet wrote:
>> Byte ordering is only an issue for the log replay; you'd get a message
>> about that if it were the issue.
>>
>> Does file -s /dev/sdb? say that any of those things even look like an
>> xfs filesystem?
>>
>> If so point xfs_db at it like:
>>
>> xfs_db -r -c "sb 0" -c "p" /dev/sdb<whatever>
>>
> it's indeed an xfs filesystem:
> $ sudo file -s /dev/sdb8
> /dev/sdb8: SGI XFS filesystem data (blksz 4096, inosz 256, v2 dirs)
> 

...

> 
> I can mount and see the content of this disk: using:
> mount -t xfs /dev/sdb8 /mnt

oh, I thought you couldn't mount it :)

> But xfs_check still crashes on me :(
> /usr/sbin/xfs_check: line 28: 26782 Segmentation fault (core dumped)
> xfs_db$DBOPTS -i -p xfs_check -c "check$OPTS" $1

try xfs_repair -n then maybe.  Or update xfsprogs.  check shouldn't
segfault, regardless of the fs state.

> Will it be ok if I made a 1:1 image of my disks under Irix (using dd):
> 
> $ dd if=/dev/dsk/dks1d3vol of=disk.img bs=512 conv=ignerror,sync
> 
> And tried to use xfs module in Linux to mount them ? or this programs
> are only meant to work with actual device rather than an image file ?

nah that's fine, images or disks, whichever.

-Eric

> thanks for your patience
> 

Re: XFS: SB validate failed

[Spam Magnet]

> try xfs_repair -n then maybe.  Or update xfsprogs.  check shouldn't
> segfault, regardless of the fs state.
>

I updated xfsprogs to the latest version (cvs checkout) and it solved
the segfault.

>
> nah that's fine, images or disks, whichever.
>

So I guess it doesn't matter if I do the image either using dd or xfsdump.
I'd prefer dd since I get a lot of issues trying to compile xfsprogs under Irix.

Assuming that I get an image using dd, would a simple mount command suffice
to use the xfs utils ? :
$ mount -t xfs -o loop disk.img /mnt

Or there are some intermediate steps that I need to take in order to
mount an xfs disk
image file on Linux ?

Re: XFS: SB validate failed

[Eric Sandeen]

Spam Magnet wrote:
>> try xfs_repair -n then maybe.  Or update xfsprogs.  check shouldn't
>> segfault, regardless of the fs state.
>>
> 
> I updated xfsprogs to the latest version (cvs checkout) and it solved
> the segfault.
> 
>> nah that's fine, images or disks, whichever.
>>
> 
> So I guess it doesn't matter if I do the image either using dd or xfsdump.
> I'd prefer dd since I get a lot of issues trying to compile xfsprogs under Irix.
> 
> Assuming that I get an image using dd, would a simple mount command suffice
> to use the xfs utils ? :
> $ mount -t xfs -o loop disk.img /mnt

that's fine, assuming your dd was of the partition that actually held
the xfs fs.

-Eric

Re: XFS: SB validate failed

[Stefan Smietanowski]

Hi!

Spam Magnet wrote:

> So I guess it doesn't matter if I do the image either using dd or xfsdump.
> I'd prefer dd since I get a lot of issues trying to compile xfsprogs under Irix.
> 
> Assuming that I get an image using dd, would a simple mount command suffice
> to use the xfs utils ? :
> $ mount -t xfs -o loop disk.img /mnt
> 
> Or there are some intermediate steps that I need to take in order to
> mount an xfs disk
> image file on Linux ?

I would add ",ro" after loop like this :

$ mount -t xfs -o loop,ro disk.img /mnt

But that's just a precaution and not necessary. This way if you
manage to mess something up some way you can just try again since
you're then mounting readonly.

Unless you were planning on updating the image and then dd'ing it back
to the original device of course.

// Stefan

Re: XFS: SB validate failed

[Timothy Shimmin]

Spam Magnet wrote:
>> try xfs_repair -n then maybe.  Or update xfsprogs.  check shouldn't
>> segfault, regardless of the fs state.
>>
> 
> I updated xfsprogs to the latest version (cvs checkout) and it solved
> the segfault.
> 
>> nah that's fine, images or disks, whichever.
>>
> 
> So I guess it doesn't matter if I do the image either using dd or xfsdump.

xfsdump won't give you an image.
xfsdump has its own format (with a bunch of overhead) which can just
be read by xfsrestore. And restore then just writes out the files
using mostly standard posix calls.
You'll want dd or xfs_copy if you want it as an image.

>> ----- partitions -----
>> >> Pt#    Device  Info     Start       End   Sectors  Id  System
>> >>  8: /dev/sdb1               2      1021   2087936   a  SGI xfs
>> >>  9: /dev/sdb2               0         1      3072   0  SGI volhdr
>> >> 11: /dev/sdb3               0      1021   2091008   6  SGI volume
>>
Certainly partition 8 here.
You can tell by the name (System) and the sizes.
The SGI Volume is for the whole volume including the hdr and the
filesystem and the SGI volhdr has the partition info.

> So can this be related to the byte ordering or any of the other
>> issues mentioned in the FAQ regarding xfs under Linux ?
As Eric said.
We chose the ondisk format to have the byte ordering of IRIX so
it should not be a problem. However, parts of the log code in Linux
does not do the necessary endian conversion (due to lack of info at
the relevant points - it only knows as blobs of data) and so you
need the log to be clean. i.e. byte ordering problem just for the log.

OOI, as Eric asked, how were you able to mount it all of a sudden?

--Tim

Re: XFS: SB validate failed

[Spam Magnet]

> As Eric said.
> We chose the ondisk format to have the byte ordering of IRIX so
> it should not be a problem. However, parts of the log code in Linux
> does not do the necessary endian conversion (due to lack of info at
> the relevant points - it only knows as blobs of data) and so you
> need the log to be clean. i.e. byte ordering problem just for the log.
>

Thanks for this info, it's good to have 1 less problem to worry about :)

> OOI, as Eric asked, how were you able to mount it all of a sudden?
>

I am not sure, as I said, to narrow down the problem I am experiencing
with other disks, I decided to format an empty, healthy disk under Irix and
try to mount it under Linux. The first try was not successful but the
second was.

Right now I am making an image of the good/healthy disk using dd to
see if I can mount that
image under Linux. (It's not fun to copy 2GB disks through a
USB1.1-SCSI adapter :)
My ultimate goal is to make image of the disks that do have
partition table but refuse to mount under either OS (magic number and
SB validattion failure).
I am hoping I can edit the disk image in order to get the data back.

Again I'd like to thank Eric, you and Stephen, you guys have been very helpful.

Re: XFS: SB validate failed

[Stefan Smietanowski]

Spam Magnet wrote:
>> As Eric said.
>> We chose the ondisk format to have the byte ordering of IRIX so
>> it should not be a problem. However, parts of the log code in Linux
>> does not do the necessary endian conversion (due to lack of info at
>> the relevant points - it only knows as blobs of data) and so you
>> need the log to be clean. i.e. byte ordering problem just for the log.
>>
> 
> Thanks for this info, it's good to have 1 less problem to worry about :)
> 
>> OOI, as Eric asked, how were you able to mount it all of a sudden?
>>
> 
> I am not sure, as I said, to narrow down the problem I am experiencing
> with other disks, I decided to format an empty, healthy disk under Irix and
> try to mount it under Linux. The first try was not successful but the
> second was.
> 
> Right now I am making an image of the good/healthy disk using dd to
> see if I can mount that
> image under Linux. (It's not fun to copy 2GB disks through a
> USB1.1-SCSI adapter :)
> My ultimate goal is to make image of the disks that do have
> partition table but refuse to mount under either OS (magic number and
> SB validattion failure).
> I am hoping I can edit the disk image in order to get the data back.

Are you dd'ing the whole disk or just the partition(s) you want ? I
recommend just doing the partition(s) into seperate files. I'm uncertain
if loopback nowadays handles partitions or not. I know it didn't before
but there were patches back then.

// Stefan

Re: XFS: SB validate failed

[Hamid]

Stefan Smietanowski wrote:
>
> Are you dd'ing the whole disk or just the partition(s) you want ? I
> recommend just doing the partition(s) into seperate files. I'm uncertain
> if loopback nowadays handles partitions or not. I know it didn't before
> but there were patches back then.
>
> // Stefan
>
I did the whole disk under Linux:

$ dd if=/dev/sdb of=disk.img conv=noerror,sync

This is how fdisk sees my image:

$ sudo fdisk -ul disk.img
Disk disk.img (SGI disk label): 255 heads, 63 sectors, 0 cylinders
Units = sectors of 1 * 512 bytes

----- partitions -----
Pt#    Device  Info     Start       End   Sectors  Id  System
 8: disk.img1            4096   3915599   3911504   a  SGI xfs
 9: disk.img2               0      4095      4096   0  SGI volhdr
11: disk.img3               0   3915599   3915600   6  SGI volume
----- Bootinfo -----
Bootfile: /unix
----- Directory Entries -----
 0: sgilabel   sector    2 size     512

I could mount the image of the healthy disk using:

$ sudo mount -t xfs -o loop,offset=$((512*4096)) disk.img /mnt

and I was able to browse the content of /mnt :)
Trying to mount the whole image didn't work. I was hoping I could do 
that so it gives me the possibility of modifying the partition table of 
the bad disks that refuse to mount under either OS.
Basically I want to play with bad disks' images to see if I can recover 
any data without actually modifying the disks.
Is there any work around for this ?
Should I create a device (rather than a loop) for the whole image ?

I should mention that creating the whole disk image by using dd under 
Irix6.5 and using the same mount command as above in Linux didn't work! 
Something might have gone wrong during the file transfer from Irix to 
Linux. If I get a chance I'll try it again.

Thanks again

Re: XFS: SB validate failed

[Stefan Smietanowski]

Hamid wrote:
> Stefan Smietanowski wrote:
>>
>> Are you dd'ing the whole disk or just the partition(s) you want ? I
>> recommend just doing the partition(s) into seperate files. I'm uncertain
>> if loopback nowadays handles partitions or not. I know it didn't before
>> but there were patches back then.
>>
>> // Stefan
>>
> I did the whole disk under Linux:
> 
> $ dd if=/dev/sdb of=disk.img conv=noerror,sync
> 
> This is how fdisk sees my image:
> 
> $ sudo fdisk -ul disk.img
> Disk disk.img (SGI disk label): 255 heads, 63 sectors, 0 cylinders
> Units = sectors of 1 * 512 bytes
> 
> ----- partitions -----
> Pt#    Device  Info     Start       End   Sectors  Id  System
> 8: disk.img1            4096   3915599   3911504   a  SGI xfs
> 9: disk.img2               0      4095      4096   0  SGI volhdr
> 11: disk.img3               0   3915599   3915600   6  SGI volume
> ----- Bootinfo -----
> Bootfile: /unix
> ----- Directory Entries -----
> 0: sgilabel   sector    2 size     512
> 
> I could mount the image of the healthy disk using:
> 
> $ sudo mount -t xfs -o loop,offset=$((512*4096)) disk.img /mnt
> 
> and I was able to browse the content of /mnt :)

Excellent, that's one step on the way.

> Trying to mount the whole image didn't work. I was hoping I could do 

Well of course, since "mounting" implies a filesystem and how is
the mount command to know which partition you want to mount and
what filesystem it is to mount? For all it knows you can have 4
partitions with 4 different filesystems on it and how is it to
choose the correct one?

Remember mounting = enabling a filesystem (in a device or file or...)
to be used via a filesystem driver and exported to a mountpoint (/mnt
for example).

In order to do what you're really after you either use your offset
trickery OR use a kernel that can mount partitioned loopback OR write
the image to another disk.

> that so it gives me the possibility of modifying the partition table of 
> the bad disks that refuse to mount under either OS.

If you want to play with the whole device (ie not files) then you can
just run your favorite partition program on your image file or your
favorite binary patching program on the image file.

> Basically I want to play with bad disks' images to see if I can recover 
> any data without actually modifying the disks.
> Is there any work around for this ?
> Should I create a device (rather than a loop) for the whole image ?

I think you have the terminology a little mixed up.

If you mount a something without supplying -o loop "mount" will assume
the filesystem resides in a DEVICE.

If you mount a something WHILE supplying -o loop you tell "mount" that
it should mount it using a loop device. Note device here, it's trickery
really as what it does is that "mount" will FIRST create a new device
node "/dev/loop0" for example and then it will mount from that device
node.

So "should I create a device .." is a little mixed up as that's what
mount is doing deep inside.

> I should mention that creating the whole disk image by using dd under 
> Irix6.5 and using the same mount command as above in Linux didn't work! 
> Something might have gone wrong during the file transfer from Irix to 
> Linux. If I get a chance I'll try it again.

If you do, then create a checksum (sha1sum och md5sum or something) and
compare the image before and after transfer to make sure it's identical.

// Stefan

Re: XFS: SB validate failed

[Stefan Smietanowski]

Stefan Smietanowski wrote:
> Hamid wrote:
>> Stefan Smietanowski wrote:
>>>
>>> Are you dd'ing the whole disk or just the partition(s) you want ? I
>>> recommend just doing the partition(s) into seperate files. I'm uncertain
>>> if loopback nowadays handles partitions or not. I know it didn't before
>>> but there were patches back then.
>>>
>>> // Stefan
>>>
>> I did the whole disk under Linux:
>>
>> $ dd if=/dev/sdb of=disk.img conv=noerror,sync
>>
>> This is how fdisk sees my image:
>>
>> $ sudo fdisk -ul disk.img
>> Disk disk.img (SGI disk label): 255 heads, 63 sectors, 0 cylinders
>> Units = sectors of 1 * 512 bytes
>>
>> ----- partitions -----
>> Pt#    Device  Info     Start       End   Sectors  Id  System
>> 8: disk.img1            4096   3915599   3911504   a  SGI xfs
>> 9: disk.img2               0      4095      4096   0  SGI volhdr
>> 11: disk.img3               0   3915599   3915600   6  SGI volume
>> ----- Bootinfo -----
>> Bootfile: /unix
>> ----- Directory Entries -----
>> 0: sgilabel   sector    2 size     512
>>
>> I could mount the image of the healthy disk using:
>>
>> $ sudo mount -t xfs -o loop,offset=$((512*4096)) disk.img /mnt
>>
>> and I was able to browse the content of /mnt :)
> 
> Excellent, that's one step on the way.
> 
>> Trying to mount the whole image didn't work. I was hoping I could do 
> 
> Well of course, since "mounting" implies a filesystem and how is
> the mount command to know which partition you want to mount and
> what filesystem it is to mount? For all it knows you can have 4
> partitions with 4 different filesystems on it and how is it to
> choose the correct one?
> 
> Remember mounting = enabling a filesystem (in a device or file or...)
> to be used via a filesystem driver and exported to a mountpoint (/mnt
> for example).
> 
> In order to do what you're really after you either use your offset
> trickery OR use a kernel that can mount partitioned loopback OR write
> the image to another disk.
> 
>> that so it gives me the possibility of modifying the partition table 
>> of the bad disks that refuse to mount under either OS.
> 
> If you want to play with the whole device (ie not files) then you can
> just run your favorite partition program on your image file or your
> favorite binary patching program on the image file.
> 
>> Basically I want to play with bad disks' images to see if I can 
>> recover any data without actually modifying the disks.
>> Is there any work around for this ?
>> Should I create a device (rather than a loop) for the whole image ?
> 
> I think you have the terminology a little mixed up.
> 
> If you mount a something without supplying -o loop "mount" will assume
> the filesystem resides in a DEVICE.
> 
> If you mount a something WHILE supplying -o loop you tell "mount" that
> it should mount it using a loop device. Note device here, it's trickery
> really as what it does is that "mount" will FIRST create a new device
> node "/dev/loop0" for example and then it will mount from that device
> node.
> 
> So "should I create a device .." is a little mixed up as that's what
> mount is doing deep inside.
> 
>> I should mention that creating the whole disk image by using dd under 
>> Irix6.5 and using the same mount command as above in Linux didn't 
>> work! Something might have gone wrong during the file transfer from 
>> Irix to Linux. If I get a chance I'll try it again.
> 
> If you do, then create a checksum (sha1sum och md5sum or something) and

And here's me replying to myself...

The command that's really use deep down inside is losetup, have a look
at the manpage.

// Stefan

Re: XFS: SB validate failed

[Hamid]

> I think you have the terminology a little mixed up.
>
> If you mount a something without supplying -o loop "mount" will assume
> the filesystem resides in a DEVICE.
>
> If you mount a something WHILE supplying -o loop you tell "mount" that
> it should mount it using a loop device. Note device here, it's trickery
> really as what it does is that "mount" will FIRST create a new device
> node "/dev/loop0" for example and then it will mount from that device
> node.
>
Thanks Stefan, Now it makes real sense.

I guess I am back to my original question:
What does 'SB validate failed' indicate and what it really means to my 
case ?

fdisk reports the structure of the Jaz disk as:

$ sudo fdisk -ul jaz7.img

Disk jaz7.img (SGI disk label): 255 heads, 63 sectors, 0 cylinders
Units = sectors of 1 * 512 bytes

----- partitions -----
Pt#    Device  Info     Start       End   Sectors  Id  System
 8: jaz7.img1            3072   2091007   2087936   a  SGI xfs
 9: jaz7.img2               0      3071      3072   0  SGI volhdr
11: jaz7.img3               0   2091007   2091008   6  SGI volume
----- Bootinfo -----
Bootfile: /unix
----- Directory Entries -----
 0: sgilabel   sector    3 size     512

I went ahead and tried to mount Partition 8 from image using the offset 
and loop options of the mount command:

$ sudo mount -t xfs -o loop,offset=$((512*3072)) jaz7-partition.img /mnt
mount: wrong fs type, bad option, bad superblock on /dev/loop1,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

And system log says:

XFS: bad magic number
XFS: SB validate failed

So I am guessing I have one of these 3 cases:
1- Bad partition table, good file system
2- Good partition table, corrupt file system
3- Or both gone south!!!

I checked the man pages of 'vh' on Irix. It seems that the volhdr
partition is 'usually' 2 megabytes but the disk in question has 3072*512 
bytes ?
Can this be a sign of corruption ?

So where would you start looking at if you wanted to fix this problem ?
Partition table or the file system ?

Re: XFS: SB validate failed

[Stefan Smietanowski]

Hamid wrote:
> 
>> I think you have the terminology a little mixed up.
>>
>> If you mount a something without supplying -o loop "mount" will assume
>> the filesystem resides in a DEVICE.
>>
>> If you mount a something WHILE supplying -o loop you tell "mount" that
>> it should mount it using a loop device. Note device here, it's trickery
>> really as what it does is that "mount" will FIRST create a new device
>> node "/dev/loop0" for example and then it will mount from that device
>> node.
>>
> Thanks Stefan, Now it makes real sense.
> 
> I guess I am back to my original question:
> What does 'SB validate failed' indicate and what it really means to my 
> case ?
> 
> fdisk reports the structure of the Jaz disk as:
> 
> $ sudo fdisk -ul jaz7.img
> 
> Disk jaz7.img (SGI disk label): 255 heads, 63 sectors, 0 cylinders
> Units = sectors of 1 * 512 bytes
> 
> ----- partitions -----
> Pt#    Device  Info     Start       End   Sectors  Id  System
> 8: jaz7.img1            3072   2091007   2087936   a  SGI xfs
> 9: jaz7.img2               0      3071      3072   0  SGI volhdr
> 11: jaz7.img3               0   2091007   2091008   6  SGI volume
> ----- Bootinfo -----
> Bootfile: /unix
> ----- Directory Entries -----
> 0: sgilabel   sector    3 size     512
> 
> I went ahead and tried to mount Partition 8 from image using the offset 
> and loop options of the mount command:
> 
> $ sudo mount -t xfs -o loop,offset=$((512*3072)) jaz7-partition.img /mnt
> mount: wrong fs type, bad option, bad superblock on /dev/loop1,
>       missing codepage or helper program, or other error
>       In some cases useful info is found in syslog - try
>       dmesg | tail  or so
> 
> And system log says:
> 
> XFS: bad magic number
> XFS: SB validate failed
> 
> So I am guessing I have one of these 3 cases:
> 1- Bad partition table, good file system
> 2- Good partition table, corrupt file system
> 3- Or both gone south!!!
> 
> I checked the man pages of 'vh' on Irix. It seems that the volhdr
> partition is 'usually' 2 megabytes but the disk in question has 3072*512 
> bytes ?
> Can this be a sign of corruption ?
> 
> So where would you start looking at if you wanted to fix this problem ?
> Partition table or the file system ?

Personally I would hexdump the beginning of the disk looking for
the xfs magic of the partition and then try to use that offset
in mount.

One way is : od -t c jaz7.img | grep X | head

Look for X   F   S   B, may be split on two lines for you.

This is what my disk looks like but of course, it's on a DOS
partition:

0077000   X   F   S   B  \0  \0 020  \0  \0  \0  \0  \0  \0  \0   `  \0

Then you have the offset (OCTAL!!) on the left, convert it to decimal,
feed that to mount and see if it mounts. Also check if it's the same
offset as the partition table is telling you or not.

// Stefan

Re: XFS: SB validate failed

[Spam Magnet]

On Sun, Jun 1, 2008 at 6:46 AM, Stefan Smietanowski <stesmi@stesmi.com> wrote:
> One way is : od -t c jaz7.img | grep X | head
>
> Look for X   F   S   B, may be split on two lines for you.
>
> This is what my disk looks like but of course, it's on a DOS
> partition:
>
> 0077000   X   F   S   B  \0  \0 020  \0  \0  \0  \0  \0  \0  \0   `  \0
>

I couldn't find any XFS by using the full dump of the disk:
$ od -t c jaz7.img | grep X | head
0040000 353   > 220   (   j   0   X   ]   I   H   C  \0 002     001  \0
0040240 003 303   H 367 363 001   F 374 021   N 376   Z   X 273  \0  \a
0040560 023   Y   Z   X   r  \t   @   u 001   B 003   ^  \v 342 314 303
1041040   5   0                           E   X   E   !  \0   K   -   H
1141360 031  \0   t  \b   P  \r 362  \t   .  \0 265   P   X  \f 026   z
1141400   # 001 353  \n   X 034 022 020   D 001   I 016   X 034   @ 023

(The healthy disk image also doesn't have any XFS but it has: 'S f x'
(capital s))
50.exe at offset 1041040 made me check the image file using a Windows
utility called : UFS Explorer.
(www.ufsexplorer.com) They claim that they can recover XFS partitions.
To my surprise that software
recognized the image as a FAT16 file system containing only one single
file called "50.exe"
I am more inclined to believe 'fdisk' rather than UFS Explorer:
Most likely the original format that Iomega had shipped the Jaz disk
with was a FAT16 and then
somebody in our lab had decided to format it to xfs.

I am beginning to feel that I will need to recover my data manually,
one file at a time :(
(It's really frustrating that I can see all my beautiful file names
through hexdump but can't access them).

So is there a preferred way of hard disk/partition recovery for XFS
file system ?
And if I end up doing that, where can I get more info about the
underwork of xfs ?

thank you all for your patience and help.

Re: XFS: SB validate failed

[Spam Magnet]

> (The healthy disk image also doesn't have any XFS but it has: 'S f x'
> (capital s))

Correcting my mistake:

The healthy image file does have the X F S B at 10000000  (octal) as
fdisk had reported:
Pt#          Device  Info     Start       End   Sectors  Id  System
 8: 2gb-ubuntu.img1            4096   3915599   3911504   a  SGI xfs

4096*512=2097152 (10000000 octal):
$ od -t c 2gb-ubuntu.img | grep 10000000
10000000   X   F   S   B  \0  \0 020  \0  \0  \0  \0  \0  \0  \a   u 350

I tried to see if I can find do the same thing for jaz7.img:
Pt#    Device  Info     Start       End   Sectors  Id  System
 8: jaz7.img1            3072   2091007   2087936   a  SGI xfs

$ od -t c jaz7.img | grep 6000000
6000000  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0

I guess all those zeros are not good signs.

Re: XFS: SB validate failed

[Stefan Smietanowski]

Spam Magnet wrote:
>> (The healthy disk image also doesn't have any XFS but it has: 'S f x'
>> (capital s))
> 
> Correcting my mistake:
> 
> The healthy image file does have the X F S B at 10000000  (octal) as
> fdisk had reported:
> Pt#          Device  Info     Start       End   Sectors  Id  System
>  8: 2gb-ubuntu.img1            4096   3915599   3911504   a  SGI xfs
> 
> 4096*512=2097152 (10000000 octal):
> $ od -t c 2gb-ubuntu.img | grep 10000000
> 10000000   X   F   S   B  \0  \0 020  \0  \0  \0  \0  \0  \0  \a   u 350
> 
> I tried to see if I can find do the same thing for jaz7.img:
> Pt#    Device  Info     Start       End   Sectors  Id  System
>  8: jaz7.img1            3072   2091007   2087936   a  SGI xfs
> 
> $ od -t c jaz7.img | grep 6000000
> 6000000  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
> 
> I guess all those zeros are not good signs.

Wait a moment. Aren't jaz sectors 2k each?

Try at 3072*2048 instead.

// Stefan

Re: XFS: SB validate failed

[Spam Magnet]

On Tue, Jun 3, 2008 at 2:59 PM, Stefan Smietanowski <stesmi@stesmi.com> wrote:
> Spam Magnet wrote:
>>>
>>> (The healthy disk image also doesn't have any XFS but it has: 'S f x'
>>> (capital s))
>>
>> Correcting my mistake:
>>
>> The healthy image file does have the X F S B at 10000000  (octal) as
>> fdisk had reported:
>> Pt#          Device  Info     Start       End   Sectors  Id  System
>>  8: 2gb-ubuntu.img1            4096   3915599   3911504   a  SGI xfs
>>
>> 4096*512=2097152 (10000000 octal):
>> $ od -t c 2gb-ubuntu.img | grep 10000000
>> 10000000   X   F   S   B  \0  \0 020  \0  \0  \0  \0  \0  \0  \a   u 350
>>
>> I tried to see if I can find do the same thing for jaz7.img:
>> Pt#    Device  Info     Start       End   Sectors  Id  System
>>  8: jaz7.img1            3072   2091007   2087936   a  SGI xfs
>>
>> $ od -t c jaz7.img | grep 6000000
>> 6000000  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
>>
>> I guess all those zeros are not good signs.
>
> Wait a moment. Aren't jaz sectors 2k each?
>
> Try at 3072*2048 instead.
>
> // Stefan
>

I think they are but I used -u option of fdisk:
$ fdisk -ul jaz7.img
Disk jaz7.img (SGI disk label): 255 heads, 63 sectors, 0 cylinders
Units = sectors of 1 * 512 bytes
----- partitions -----
Pt#    Device  Info     Start       End   Sectors  Id  System
 8: jaz7.img1            3072   2091007   2087936   a  SGI xfs
 9: jaz7.img2               0      3071      3072   0  SGI volhdr
11: jaz7.img3               0   2091007   2091008   6  SGI volume

which lists partitions in sector units. As oppose to:

$ fdisk -l jaz7.img

Disk jaz7.img (SGI disk label): 255 heads, 63 sectors, 0 cylinders
Units = cylinders of 16065 * 512 bytes

----- partitions -----
Pt#    Device  Info     Start       End   Sectors  Id  System
 8: jaz7.img1               1       130   2087936   a  SGI xfs
 9: jaz7.img2               0         0      3072   0  SGI volhdr
11: jaz7.img3               0       130   2091008   6  SGI volume

Re: XFS: SB validate failed

[Stefan Smietanowski]

Spam Magnet wrote:
> On Tue, Jun 3, 2008 at 2:59 PM, Stefan Smietanowski <stesmi@stesmi.com> wrote:
>> Spam Magnet wrote:
>>>> (The healthy disk image also doesn't have any XFS but it has: 'S f x'
>>>> (capital s))
>>> Correcting my mistake:
>>>
>>> The healthy image file does have the X F S B at 10000000  (octal) as
>>> fdisk had reported:
>>> Pt#          Device  Info     Start       End   Sectors  Id  System
>>>  8: 2gb-ubuntu.img1            4096   3915599   3911504   a  SGI xfs
>>>
>>> 4096*512=2097152 (10000000 octal):
>>> $ od -t c 2gb-ubuntu.img | grep 10000000
>>> 10000000   X   F   S   B  \0  \0 020  \0  \0  \0  \0  \0  \0  \a   u 350
>>>
>>> I tried to see if I can find do the same thing for jaz7.img:
>>> Pt#    Device  Info     Start       End   Sectors  Id  System
>>>  8: jaz7.img1            3072   2091007   2087936   a  SGI xfs
>>>
>>> $ od -t c jaz7.img | grep 6000000
>>> 6000000  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
>>>
>>> I guess all those zeros are not good signs.
>> Wait a moment. Aren't jaz sectors 2k each?
>>
>> Try at 3072*2048 instead.
>>
>> // Stefan
>>
> 
> I think they are but I used -u option of fdisk:
> $ fdisk -ul jaz7.img
> Disk jaz7.img (SGI disk label): 255 heads, 63 sectors, 0 cylinders
> Units = sectors of 1 * 512 bytes
> ----- partitions -----
> Pt#    Device  Info     Start       End   Sectors  Id  System
>  8: jaz7.img1            3072   2091007   2087936   a  SGI xfs
>  9: jaz7.img2               0      3071      3072   0  SGI volhdr
> 11: jaz7.img3               0   2091007   2091008   6  SGI volume
> 
> which lists partitions in sector units. As oppose to:
> 
> $ fdisk -l jaz7.img
> 
> Disk jaz7.img (SGI disk label): 255 heads, 63 sectors, 0 cylinders
> Units = cylinders of 16065 * 512 bytes
> 
> ----- partitions -----
> Pt#    Device  Info     Start       End   Sectors  Id  System
>  8: jaz7.img1               1       130   2087936   a  SGI xfs
>  9: jaz7.img2               0         0      3072   0  SGI volhdr
> 11: jaz7.img3               0       130   2091008   6  SGI volume

I'd give it a shot regardless as I don't remember if the sector size is
actually IN the partition table and if it's NOT then it'll show the
native blocksize of the device, which is 512bytes!

Just try it, what do you have to lose? I mean do the od ..
Worst case you get garbage or zeroes.

// Stefan

Re: XFS: SB validate failed

[Spam Magnet]

On Tue, Jun 3, 2008 at 4:23 PM, Stefan Smietanowski <stesmi@stesmi.com> wrote:

>> I think they are but I used -u option of fdisk:
>> $ fdisk -ul jaz7.img
>> Disk jaz7.img (SGI disk label): 255 heads, 63 sectors, 0 cylinders
>> Units = sectors of 1 * 512 bytes
>> ----- partitions -----
>> Pt#    Device  Info     Start       End   Sectors  Id  System
>>  8: jaz7.img1            3072   2091007   2087936   a  SGI xfs
>>  9: jaz7.img2               0      3071      3072   0  SGI volhdr
>> 11: jaz7.img3               0   2091007   2091008   6  SGI volume
>>
>> which lists partitions in sector units. As oppose to:
>>
>> $ fdisk -l jaz7.img
>>
>> Disk jaz7.img (SGI disk label): 255 heads, 63 sectors, 0 cylinders
>> Units = cylinders of 16065 * 512 bytes
>>
>> ----- partitions -----
>> Pt#    Device  Info     Start       End   Sectors  Id  System
>>  8: jaz7.img1               1       130   2087936   a  SGI xfs
>>  9: jaz7.img2               0         0      3072   0  SGI volhdr
>> 11: jaz7.img3               0       130   2091008   6  SGI volume
>
> I'd give it a shot regardless as I don't remember if the sector size is
> actually IN the partition table and if it's NOT then it'll show the
> native blocksize of the device, which is 512bytes!
>
> Just try it, what do you have to lose? I mean do the od ..
> Worst case you get garbage or zeroes.

3072*2048=6,291,456 (30000000 octal)

$ od -t c jaz7.img | grep 30000000
30000000 377 377 367 371  \0  \0   0 365  \0  \0   ?   y  \0  \0 004 016
130000000 201 244  \0 001  \0  \0  \0  \0  \0  \0 006 201   B 373 306 307

So I guess that didn't work either :(

Re: XFS: SB validate failed

[Timothy Shimmin]

Spam Magnet wrote:
>> As Eric said.
>> We chose the ondisk format to have the byte ordering of IRIX so
>> it should not be a problem. However, parts of the log code in Linux
>> does not do the necessary endian conversion (due to lack of info at
>> the relevant points - it only knows as blobs of data) and so you
>> need the log to be clean. i.e. byte ordering problem just for the log.
>>
> 
> Thanks for this info, it's good to have 1 less problem to worry about :)
> 
>> OOI, as Eric asked, how were you able to mount it all of a sudden?
>>
> 
> I am not sure, as I said, to narrow down the problem I am experiencing
> with other disks, I decided to format an empty, healthy disk under Irix and
> try to mount it under Linux. The first try was not successful but the
> second was.
> 
> Right now I am making an image of the good/healthy disk using dd to
> see if I can mount that
> image under Linux. (It's not fun to copy 2GB disks through a
> USB1.1-SCSI adapter :)

:-)
If the fs is not too full then xfs_copy would be good I suppose as
it won't copy freespace.

--Tim