On Mon, 1 Feb 2016, Brian Foster wrote: > On Mon, Feb 01, 2016 at 02:11:18AM -0800, Christian Kujau wrote: > > I tried to upgrade from 4.4.0-rc5 to 4.5.0-rc2 but I'm currently unable to > > mount my XFS filesystems any more on this PowerPC G4 machine: > > > > You most likely need Darrick's recent fix, posted here: > > http://oss.sgi.com/pipermail/xfs/2016-January/046437.html > > The original patch had some endian conversion brokenness that wasn't > detected on x86-64. Thanks! The patch helps and the XFS file systems can be mounted again! Tested-by: Christian Kujau <lists@xxxxxxxxxxxxxxx> C. > > Brian > > > # mount -t xfs -o ro /dev/mapper/wdc1 /mnt/disk > > mount: mount /dev/mapper/wdc1 on /mnt/disk failed: Bad message > > > > # dmesg | tail > > [ 2035.937165] XFS (dm-2): Mounting V4 Filesystem > > [ 2036.357198] XFS (dm-2): Torn write (CRC failure) detected at log block 0x296e4. Truncating head block from 0x296e8. > > [ 2036.360155] XFS (dm-2): failed to locate log tail > > [ 2036.360222] XFS (dm-2): log mount/recovery failed: error -74 > > [ 2036.360751] XFS (dm-2): log mount failed > > > > AFAICS the message got introduced by "xfs: detect and trim torn writes > > during log recovery" - however, there is no crash involved here. The > > system was running 4.4.0-rc5 just fine and rebooted properly into > > 4.5.0-rc2. The underlying storage is an external disk attached via > > Firewire and dm-crypt on top of that. > > > > Running "xfs_repair -n" on the device came back with error code 1 (see > > below for its log[0]). > > > > This is all on Debian/stable with xfs_repair v3.2.1 - but I was unable to > > compile xfsprogs from the current git tree, because of a compilation error[1] > > > > Would it be safe to run xfs_repair without -n on that device? > > > > Christian. > > > > [0] xfs_repair > > # file -Ls /dev/mapper/wdc1 > > /dev/mapper/wdc1: SGI XFS filesystem data (blksz 4096, inosz 256, v2 dirs) > > > > # cryptsetup status wdc1 > > /dev/mapper/wdc1 is active. > > type: LUKS1 > > cipher: aes-cbc-essiv:sha256 > > keysize: 128 bits > > device: /dev/sde1 > > offset: 1032 sectors > > size: 1953524069 sectors > > mode: read/write > > > > # time xfs_repair -n /dev/mapper/wdc1; echo $? > > Phase 1 - find and verify superblock... > > Phase 2 - using internal log > > - scan filesystem freespace and inode maps... > > sb_fdblocks 15681968, counted 15731120 > > - 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. > > > > real 1m24.829s > > user 0m5.012s > > sys 0m1.200s > > 1 == Exit code > > > > > > > > [1] xfsprogs/v4.3.0 > > ==================================================== > > Building io > > [CC] fiemap.o > > In file included from ../include/xfs.h:58:0, > > from io.h:19, > > from fiemap.c:24: > > ../include/xfs/xfs_fs.h:42:8: error: redefinition of ‘struct fsxattr’ > > struct fsxattr { > > ^ > > In file included from fiemap.c:22:0: > > /usr/include/linux/fs.h:155:8: note: originally defined here > > struct fsxattr { > > ^ > > ../include/buildrules:59: recipe for target 'fiemap.o' failed > > make[2]: *** [fiemap.o] Error 1 > > include/buildrules:35: recipe for target 'io' failed > > make[1]: *** [io] Error 2 > > Makefile:70: recipe for target 'default' failed > > make: *** [default] Error 2 > > ==================================================== > > > > And indeed, "struct fsxattr" is already defined in /usr/include/linux/fs.h > > which is provided by linux-libc-dev, which cannot be removed that easily: > > > > $ sudo apt-get purge linux-libc-dev > > The following packages will be REMOVED: > > build-essential* dh-autoreconf* g++* g++-4.9* libblkid-dev* libbz2-dev* > > libc6-dev* libexpat1-dev* libicu-dev* libmysqlclient-dev* libncurses5-dev* > > libncursesw5-dev* libpam0g-dev* libpcre3-dev* libperl-dev* libpython-dev* > > libpython2.7-dev* libssl-dev* libstdc++-4.9-dev* libtool* libxmlrpc-core-c3-dev* > > linux-libc-dev* python-dev* python2.7-dev* uuid-dev* zlib1g-dev* > > > > Note: the compilation error was reported a few days ago on the qemu-devel > > mailing list too: > > > > [Qemu-devel] qemu fails to build on 4.5-rc1 > > https://www.mail-archive.com/qemu-devel@xxxxxxxxxx/msg348756.html > > > > -- > > BOFH excuse #154: > > > > You can tune a file system, but you can't tune a fish (from most tunefs man pages) > > > > _______________________________________________ > > xfs mailing list > > xfs@xxxxxxxxxxx > > http://oss.sgi.com/mailman/listinfo/xfs > -- BOFH excuse #354: Chewing gum on /dev/sd3c _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
