From: Michael Monnerie <michael.monnerie@is.it-management.at>
To: xfs@oss.sgi.com
Subject: Re: xfs file system in process of becoming corrupt; though xfs_repair thinks it's fine! ; -/ (was xfs_dump problem...)
Date: Wed, 30 Jun 2010 20:25:20 +0200 [thread overview]
Message-ID: <201006302025.20289@zmi.at> (raw)
In-Reply-To: <4C2A749E.4060006@tlinx.org>
[-- Attachment #1.1.1: Type: Text/Plain, Size: 8441 bytes --]
On Mittwoch, 30. Juni 2010 Linda Walsh wrote:
> But have another XFS problem that is much more reliably persistent.
> I don't know if they are at all related, but since I have this
> problem that's a bit "stuck", it's easier to "reproduce".
I think my problem is similar. I have a Linux ("orion") running Samba.
A Win7 client uses it to store it's "Windows Backup". That's OK.
From another Linux ("saturn"), I do an rsync via an rsync-module,
and have already 4 Versions where the ".vhd" file of that Windows Backup
is destroyed on "saturn". So the corruption happens when starting
rsync @saturn, copying orion->saturn, both having XFS.
As I cannot delete the broken files, I moved the whole dir away,
and did an rsync again. The same file destroyed again on saturn.
Some days later, again 2 versions which are destroyed.
The difference to Linda is, I get:
drwx------+ 2 zmi users 4096 Jun 12 03:15 ./
drwxr-xr-x 7 root root 154 Jun 30 04:00 ../
-rwx------+ 1 zmi users 56640000 Jun 12 03:05 852c268f-cf1a-11de-b09b-806e6f6e6963.vhd*
??????????? ? ? ? ? ? 852c2690-cf1a-11de-b09b-806e6f6e6963.vhd
and on dmesg:
[125903.343714] Filesystem "dm-0": corrupt inode 649642 ((a)extents = 5). Unmount and run xfs_repair.
[125903.343735] ffff88011e34ca00: 49 4e 81 c0 02 02 00 00 00 00 03 e8 00 00 00 64 IN.............d
[125903.343756] Filesystem "dm-0": XFS internal error xfs_iformat_extents(1) at line 558 of file /usr/src/packages/BUILD/kernel-desktop-2.6.31.12/linux-2.6.31/fs/xfs/xfs_inode.c. Caller 0xffffffffa032c0ad
[125903.343763]
[125903.343791] Pid: 17696, comm: ls Not tainted 2.6.31.12-0.2-desktop #1
[125903.343803] Call Trace:
[125903.343821] [<ffffffff81011a19>] try_stack_unwind+0x189/0x1b0
[125903.343840] [<ffffffff8101025d>] dump_trace+0xad/0x3a0
[125903.343858] [<ffffffff81011524>] show_trace_log_lvl+0x64/0x90
[125903.343876] [<ffffffff81011573>] show_trace+0x23/0x40
[125903.343894] [<ffffffff81552b46>] dump_stack+0x81/0x9e
[125903.343947] [<ffffffffa0321b4a>] xfs_error_report+0x5a/0x70 [xfs]
[125903.344085] [<ffffffffa0321bcc>] xfs_corruption_error+0x6c/0x90 [xfs]
[125903.344248] [<ffffffffa032bb84>] xfs_iformat_extents+0x234/0x280 [xfs]
[125903.344409] [<ffffffffa032c0ad>] xfs_iformat+0x28d/0x5a0 [xfs]
[125903.344569] [<ffffffffa032c542>] xfs_iread+0x182/0x1c0 [xfs]
[125903.344729] [<ffffffffa0327938>] xfs_iget_cache_miss+0x78/0x250 [xfs]
[125903.344882] [<ffffffffa0327c3c>] xfs_iget+0x12c/0x1b0 [xfs]
[125903.345036] [<ffffffffa0347b8e>] xfs_lookup+0xce/0x100 [xfs]
[125903.345256] [<ffffffffa0354e6c>] xfs_vn_lookup+0x6c/0xc0 [xfs]
[125903.345453] [<ffffffff81157782>] real_lookup+0x102/0x180
[125903.345473] [<ffffffff811598c0>] do_lookup+0xd0/0x100
[125903.345491] [<ffffffff81159e12>] __link_path_walk+0x522/0x880
[125903.345510] [<ffffffff8115a6f6>] path_walk+0x66/0xd0
[125903.345528] [<ffffffff8115a7cb>] do_path_lookup+0x6b/0xb0
[125903.345546] [<ffffffff8115a9d1>] user_path_at+0x61/0xc0
[125903.345565] [<ffffffff811514d1>] vfs_fstatat+0x41/0x90
[125903.345584] [<ffffffff811515ac>] vfs_lstat+0x2c/0x50
[125903.345602] [<ffffffff811515fe>] sys_newlstat+0x2e/0x70
[125903.345621] [<ffffffff8100c682>] system_call_fastpath+0x16/0x1b
[125903.345645] [<00007f72dc451e65>] 0x7f72dc451e65
Trying to "xfs_repair -n" seems to find errors, see attachment "repair1.log"
Trying to "xfs_repair" crashes, see attachment "repair2.log"
Saturns kernel is 2.6.31.12-0.2-desktop from openSUSE 11.2,
xfs_repair is 3.1.2 (I tried down several versions down to 3.0.1, all without success).
Even after xfs_metadump and xfs_mdrestore the error exists, and cannot be
repaired with xfs_repair, because that crashes.
I've put a new metadump containing only the broken stuff for public review:
http://zmi.at/saturn_bigdata.metadump.only_broken.bz2 (197 MB)
What should I do, apart of ripping the whole filesystem and copying new?
The problem is, would be destroyed again, just like it did 4 times now.
--
mit freundlichen Grüssen,
Michael Monnerie, Ing. BSc
it-management Internet Services
http://proteger.at [gesprochen: Prot-e-schee]
Tel: 0660 / 415 65 31
// Wir haben im Moment zwei Häuser zu verkaufen:
// http://zmi.at/langegg/
// http://zmi.at/haus2009/
[-- Attachment #1.1.2: repair1.log --]
[-- Type: text/x-log, Size: 1919 bytes --]
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
would have corrected attribute entry count in inode 649642 from 40 to 0
local inode 649790 attr too small (size = 1, min size = 4)
bad attribute fork in inode 649790, would clear attr fork
would have cleared inode 649790
- agno = 1
local inode 2195133988 attr too small (size = 3, min size = 4)
bad attribute fork in inode 2195133988, would clear attr fork
would have cleared inode 2195133988
would have corrected attribute entry count in inode 2902971474 from 163 to 0
would have corrected attribute totsize in inode 2902971474 from 6 to 4
- agno = 2
- agno = 3
- agno = 4
- agno = 5
- agno = 6
- agno = 7
- 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
- agno = 4
- agno = 5
- agno = 6
- agno = 7
local inode 2195133988 attr too small (size = 3, min size = 4)
bad attribute fork in inode 2195133988, would clear attr fork
would have cleared inode 2195133988
local inode 649790 attr too small (size = 1, min size = 4)
bad attribute fork in inode 649790, would clear attr fork
would have cleared inode 649790
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.
[-- Attachment #1.1.3: repair2.log --]
[-- Type: text/x-log, Size: 1597 bytes --]
Phase 1 - find and verify superblock...
Phase 2 - using internal log
- zero log...
- scan filesystem freespace and inode maps...
- found root inode chunk
Phase 3 - for each AG...
- scan and clear agi unlinked lists...
- process known inodes and perform inode discovery...
- agno = 0
corrected attribute entry count in inode 649642, was 40, now 0
problem with attribute contents in inode 649642
local inode 649790 attr too small (size = 1, min size = 4)
bad attribute fork in inode 649790, clearing attr fork
clearing inode 649790 attributes
cleared inode 649790
- agno = 1
local inode 2195133988 attr too small (size = 3, min size = 4)
bad attribute fork in inode 2195133988, clearing attr fork
clearing inode 2195133988 attributes
cleared inode 2195133988
corrected attribute entry count in inode 2902971474, was 163, now 0
corrected attribute entry totsize in inode 2902971474, was 6, now 4
problem with attribute contents in inode 2902971474
- agno = 2
- agno = 3
- agno = 4
- agno = 5
- agno = 6
- agno = 7
- 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
- agno = 4
- agno = 5
- agno = 6
- agno = 7
data fork in inode 2195133988 claims metadata block 537122652
xfs_repair: dinode.c:2101: process_inode_data_fork: Assertion `err == 0' failed.
[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
[-- Attachment #2: Type: text/plain, Size: 121 bytes --]
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2010-06-30 18:22 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-27 1:10 WARNING xfsdump [still] Cannot allocate memory for list of [root|non-root] attributes for nondir ino xxyz Linda A. Walsh
2010-06-28 2:27 ` Dave Chinner
2010-06-29 22:33 ` xfs file system in process of becoming corrupt; though xfs_repair thinks it's fine! ; -/ (was xfs_dump problem...) Linda Walsh
2010-06-29 23:25 ` xfs file system in process of becoming corrupt; though xfs_repair thinks it's fine! ;-/ " Dave Chinner
2010-06-29 23:55 ` Michael Weissenbacher
2010-06-30 0:42 ` xfs file system in process of becoming corrupt; though xfs_repair thinks it's fine! ; -/ " Linda A. Walsh
2010-06-30 1:16 ` Dave Chinner
2010-06-30 2:45 ` Linda A. Walsh
2010-07-01 23:58 ` Dave Chinner
2010-07-07 3:18 ` Linda A. Walsh
2010-07-07 5:56 ` Linda Walsh
2010-07-07 6:36 ` Dave Chinner
2010-07-07 9:30 ` Linda A. Walsh
2010-07-07 21:01 ` Linda Walsh
2010-06-30 0:01 ` Linda A. Walsh
2010-06-30 1:06 ` xfs file system in process of becoming corrupt; though xfs_repair thinks it's fine! ;-/ " Dave Chinner
2010-06-30 1:52 ` xfs file system in process of becoming corrupt; though xfs_repair thinks it's fine! ; -/ " Linda A. Walsh
2010-06-30 21:01 ` Stan Hoeppner
2010-07-07 21:40 ` utf-8' chars from Winxp machine may be problem related (was Re: xfs file system in process of becoming corrupt; though xfs_repair...) Linda A. Walsh
2010-07-07 23:40 ` Stan Hoeppner
2010-07-08 0:38 ` Linda A. Walsh
2010-06-30 18:25 ` Michael Monnerie [this message]
2010-06-30 23:30 ` rsync and corrupt inodes (was xfs_dump problem) Dave Chinner
2010-07-01 8:25 ` Michael Monnerie
2010-07-02 2:42 ` Dave Chinner
2010-07-02 6:21 ` Michael Monnerie
2010-07-04 22:53 ` Dave Chinner
2010-07-12 11:28 ` Michael Monnerie
2010-07-07 21:56 ` Linda Walsh
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=201006302025.20289@zmi.at \
--to=michael.monnerie@is.it-management.at \
--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