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?