From: Brian Foster <bfoster@redhat.com>
To: Christian Kujau <lists@nerdbynature.de>
Cc: xfs@oss.sgi.com
Subject: Re: 4.5-rc2: Torn write (CRC failure) detected
Date: Mon, 1 Feb 2016 07:34:01 -0500 [thread overview]
Message-ID: <20160201123401.GA3992@bfoster.bfoster> (raw)
In-Reply-To: <alpine.DEB.2.20.10.1602010152110.22992@trent.utfs.org>
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.
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@nongnu.org/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@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2016-02-01 12:18 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-01 10:11 4.5-rc2: Torn write (CRC failure) detected Christian Kujau
2016-02-01 12:34 ` Brian Foster [this message]
2016-02-01 19:54 ` Christian Kujau
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160201123401.GA3992@bfoster.bfoster \
--to=bfoster@redhat.com \
--cc=lists@nerdbynature.de \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.