Hi,
this PowerBook G4 crashed (power supply failed) and now I have to wait a
few days until the new PSU arrives. In the meantime I attached its
external disks to an Intel Atom machine (i686) and wanted to mount the
disks:
# mount -t xfs /dev/mapper/wdc1 /mnt/media
mount: /dev/mapper/wdc1: can't read superblock
In dmesg:
XFS (dm-3): Mounting Filesystem
XFS (dm-3): Starting recovery (logdev: internal)
XFS (dm-3): log record CRC mismatch: found 0x10a71f1d, expected 0xe012d25f.
f8808000: 00 00 00 01 00 00 00 00 69 01 00 00 76 63 5a 10 ........i...vcZ.
f8808010: 00 00 00 10 69 00 00 00 54 52 41 4e 00 00 00 2a ....i...TRAN...*
XFS (dm-3): dirty log written in incompatible format - can't recover
XFS (dm-3): log mount/recovery failed: error 5
XFS (dm-3): log mount failed
Note: /dev/mapper/wdc1 is a dm-crypt device, not sure if this matters
though.
Running "xfs_repair -n /dev/mapper/wdc1" came back with an exit code of
"0" and did not report anything unusual (attached below).
Running xfs_repair (v3.2.0 from Fedora 20) *without* "-n" warns that the
filesystem has valuable metadata changes and advises to mount it first. Or
use "xfs_repair -L" to clear the log, but I have not done this just yet.
I *think* I have mounted the same filesystem before on this i686 system
(some weeks ago) but then the filesystem got umounted cleanly from the
PowerPC system, where this disk is attached to usually.
The PowerPC box is running the latest vanilla kernel (sometimes a few -rc
versions behind) and was running 3.15.0 when the power supply failed. This
i686 system (an IdeaPad S10 Laptop) is running a semi-current Fedora 20
installation (with 3.14.5-200.fc20.i686 right now).
Could it be that endianess has something to do with it? The PowerPC is
big-endian I think, and the i686 Laptop is little-endian. Even though I'm
almost certain that I've mounted the disk before, now that the filesystem
needs to be recovered first, maybe endianess matters now?
Ideas welcome :)
Thanks,
Christian.
# xfs_repair -n /dev/mapper/wdc1
Phase 1 - find and verify superblock...
Phase 2 - using internal log
- scan filesystem freespace and inode maps...
- found root inode chunk
Phase 3 - for each AG...
- scan (but don't clear) agi unlinked lists...
- process known inodes and perform inode discovery...
- agno = 0
- agno = 1
- agno = 2
- agno = 3
- process newly discovered inodes...
Phase 4 - check for duplicate blocks...
- setting up duplicate extent list...
- check for inodes claiming duplicate blocks...
- agno = 0
- agno = 1
- agno = 2
- agno = 3
No modify flag set, skipping phase 5
Phase 6 - check inode connectivity...
- traversing filesystem ...
- traversal finished ...
- moving disconnected inodes to lost+found ...
Phase 7 - verify link counts...
No modify flag set, skipping filesystem flush and exiting.
# echo $?
0
# file -Ls /dev/mapper/wdc1
/dev/mapper/wdc1: SGI XFS filesystem data (blksz 4096, inosz 256, v2 dirs)
# blockdev --getsize64 /dev/mapper/wdc1
1000204323328
# cryptsetup status wdc1
/dev/mapper/wdc1 is active.
type: LUKS1
cipher: aes-cbc-essiv:sha256
keysize: 128 bits
device: /dev/sdc1
offset: 1032 sectors
size: 1953524069 sectors
mode: read/write
--
BOFH excuse #121:
halon system went off and killed the operators.
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
