public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
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

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox