* xfs_repair 3.1.2 crashing
@ 2010-06-10 11:06 Michael Monnerie
2010-06-10 16:27 ` Eric Sandeen
0 siblings, 1 reply; 8+ messages in thread
From: Michael Monnerie @ 2010-06-10 11:06 UTC (permalink / raw)
To: xfs-oss
[-- Attachment #1.1: Type: text/plain, Size: 1815 bytes --]
Dear devs, I have a massive problem with a filesystem in our internal
server. We've had an overheating problem with the RAID controller CPU,
as it's very hot here and aircondition was turn off... the system "just"
stopped working. This is a XenServer with some Linuxen on it, and one of
them (of course our main server :-) reports this on xfs_repair:
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
- agno = 1
local inode 2267035928 attr too small (size = 3, min size = 4)
bad attribute fork in inode 2267035928, clearing attr fork
clearing inode 2267035928 attributes
cleared inode 2267035928
- agno = 2
- agno = 3
- agno = 4
- agno = 5
- agno = 6
- process newly discovered inodes...
Phase 4 - check for duplicate blocks...
- setting up duplicate extent list...
- check for inodes claiming duplicate blocks...
- agno = 0
- agno = 2
- agno = 1
data fork in regular inode 2267035928 claims used block 537158068
xfs_repair: dinode.c:2101: process_inode_data_fork: Assertion `err == 0'
failed.
Any ideas?
Before that, I had 3.0.3 installed, it found tons of errors before also
crashing. I'll send that log later.
--
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.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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: xfs_repair 3.1.2 crashing
2010-06-10 11:06 xfs_repair 3.1.2 crashing Michael Monnerie
@ 2010-06-10 16:27 ` Eric Sandeen
2010-06-11 23:38 ` Michael Monnerie
0 siblings, 1 reply; 8+ messages in thread
From: Eric Sandeen @ 2010-06-10 16:27 UTC (permalink / raw)
To: Michael Monnerie; +Cc: xfs-oss
Michael Monnerie wrote:
> Dear devs, I have a massive problem with a filesystem in our internal
> server. We've had an overheating problem with the RAID controller CPU,
> as it's very hot here and aircondition was turn off... the system "just"
> stopped working. This is a XenServer with some Linuxen on it, and one of
> them (of course our main server :-) reports this on xfs_repair:
>
...
> Phase 4 - check for duplicate blocks...
> - setting up duplicate extent list...
> - check for inodes claiming duplicate blocks...
> - agno = 0
> - agno = 2
> - agno = 1
> data fork in regular inode 2267035928 claims used block 537158068
> xfs_repair: dinode.c:2101: process_inode_data_fork: Assertion `err == 0'
> failed.
>
> Any ideas?
It'd be great to at least capture the issue by creating an xfs_metadump
image for analysis...
-Eric
> Before that, I had 3.0.3 installed, it found tons of errors before also
> crashing. I'll send that log later.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: xfs_repair 3.1.2 crashing
2010-06-10 16:27 ` Eric Sandeen
@ 2010-06-11 23:38 ` Michael Monnerie
2010-06-12 1:38 ` Eric Sandeen
0 siblings, 1 reply; 8+ messages in thread
From: Michael Monnerie @ 2010-06-11 23:38 UTC (permalink / raw)
To: xfs
[-- Attachment #1.1: Type: Text/Plain, Size: 2577 bytes --]
On Donnerstag, 10. Juni 2010 Eric Sandeen wrote:
> It'd be great to at least capture the issue by creating an
> xfs_metadump image for analysis...
I sent it to you in private.
But now I'm really puzzled: I bought 2 2TB drives, installed an lvm with
xfs on them to have 4TB, and copied the contents from the server to
these 4TB via rsync -aHAX. And now I have a broken XFS on that brand new
created drives, without any crash, not even a reboot!
I got this message after making a "du -s" on the new disks:
du: cannot access `samba/backup/uranus/WindowsImageBackup/uranus/Backup
2010-06-05 010014/852c2690-cf1a-11de-b09b-806e6f6e6963.vhd': Structure
needs cleaning
So I umounted and xfs_repaired (v3.1.2) it:
# xfs_repair -V
xfs_repair version 3.1.2
# xfs_repair /dev/swraid0/backup
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
- 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
- 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 = 2
- agno = 4
- agno = 5
- agno = 6
- agno = 7
- agno = 3
- agno = 1
- agno = 0
data fork in inode 2195133988 claims metadata block 537122652
xfs_repair: dinode.c:2101: process_inode_data_fork: Assertion `err == 0'
failed.
Aborted
What's this now? I copied the error from the source via rsync? ;-)
--
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.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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: xfs_repair 3.1.2 crashing
2010-06-11 23:38 ` Michael Monnerie
@ 2010-06-12 1:38 ` Eric Sandeen
2010-06-12 10:41 ` Michael Monnerie
2010-06-12 13:33 ` Michael Monnerie
0 siblings, 2 replies; 8+ messages in thread
From: Eric Sandeen @ 2010-06-12 1:38 UTC (permalink / raw)
To: Michael Monnerie; +Cc: xfs
Michael Monnerie wrote:
> On Donnerstag, 10. Juni 2010 Eric Sandeen wrote:
>> It'd be great to at least capture the issue by creating an
>> xfs_metadump image for analysis...
>
> I sent it to you in private.
>
> But now I'm really puzzled: I bought 2 2TB drives, installed an lvm with
> xfs on them to have 4TB, and copied the contents from the server to
> these 4TB via rsync -aHAX. And now I have a broken XFS on that brand new
> created drives, without any crash, not even a reboot!
>
> I got this message after making a "du -s" on the new disks:
> du: cannot access `samba/backup/uranus/WindowsImageBackup/uranus/Backup
> 2010-06-05 010014/852c2690-cf1a-11de-b09b-806e6f6e6963.vhd': Structure
> needs cleaning
dmesg would be the right thing to do here ...
> So I umounted and xfs_repaired (v3.1.2) it:
> # xfs_repair -V
> xfs_repair version 3.1.2
which kernel, again? The fork offset problems smell like something that's fixed.
-Eric
> # xfs_repair /dev/swraid0/backup
> 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
> - 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
> - 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 = 2
> - agno = 4
> - agno = 5
> - agno = 6
> - agno = 7
> - agno = 3
> - agno = 1
> - agno = 0
> data fork in inode 2195133988 claims metadata block 537122652
> xfs_repair: dinode.c:2101: process_inode_data_fork: Assertion `err == 0'
> failed.
> Aborted
>
> What's this now? I copied the error from the source via rsync? ;-)
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: xfs_repair 3.1.2 crashing
2010-06-12 1:38 ` Eric Sandeen
@ 2010-06-12 10:41 ` Michael Monnerie
2010-06-23 18:32 ` Michael Monnerie
2010-06-12 13:33 ` Michael Monnerie
1 sibling, 1 reply; 8+ messages in thread
From: Michael Monnerie @ 2010-06-12 10:41 UTC (permalink / raw)
To: xfs
[-- Attachment #1.1: Type: Text/Plain, Size: 10944 bytes --]
On Samstag, 12. Juni 2010 Eric Sandeen wrote:
> > du: cannot access
> > `samba/backup/uranus/WindowsImageBackup/uranus/Backup 2010-06-05
> > 010014/852c2690-cf1a-11de-b09b-806e6f6e6963.vhd': Structure needs
> > cleaning
> dmesg would be the right thing to do here ...
There are a lot, here the last two:
[157312.699958] XFS mounting filesystem dm-0
[157312.891010] Ending clean XFS mount for filesystem: dm-0
[157340.953238] Filesystem "dm-0": corrupt inode 2195133988 ((a)extents = 5). Unmount and run xfs_repair.
[157340.953250] ffff8800928b6400: 49 4e 81 c0 02 02 00 00 00 00 03 e8 00 00 00 64 IN.............d
[157340.953268] 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 0xffffffffa03380ad
[157340.953271]
[157340.953285] Pid: 27034, comm: du Not tainted 2.6.31.12-0.2-desktop #1
[157340.953292] Call Trace:
[157340.953308] [<ffffffff81011a19>] try_stack_unwind+0x189/0x1b0
[157340.953316] [<ffffffff8101025d>] dump_trace+0xad/0x3a0
[157340.953324] [<ffffffff81011524>] show_trace_log_lvl+0x64/0x90
[157340.953331] [<ffffffff81011573>] show_trace+0x23/0x40
[157340.953339] [<ffffffff81552b46>] dump_stack+0x81/0x9e
[157340.953369] [<ffffffffa032db4a>] xfs_error_report+0x5a/0x70 [xfs]
[157340.953427] [<ffffffffa032dbcc>] xfs_corruption_error+0x6c/0x90 [xfs]
[157340.953482] [<ffffffffa0337b84>] xfs_iformat_extents+0x234/0x280 [xfs]
[157340.953543] [<ffffffffa03380ad>] xfs_iformat+0x28d/0x5a0 [xfs]
[157340.953600] [<ffffffffa0338542>] xfs_iread+0x182/0x1c0 [xfs]
[157340.953658] [<ffffffffa0333938>] xfs_iget_cache_miss+0x78/0x250 [xfs]
[157340.953712] [<ffffffffa0333c3c>] xfs_iget+0x12c/0x1b0 [xfs]
[157340.953768] [<ffffffffa0353b8e>] xfs_lookup+0xce/0x100 [xfs]
[157340.953843] [<ffffffffa0360e6c>] xfs_vn_lookup+0x6c/0xc0 [xfs]
[157340.953922] [<ffffffff81157782>] real_lookup+0x102/0x180
[157340.953931] [<ffffffff811598c0>] do_lookup+0xd0/0x100
[157340.953938] [<ffffffff81159e12>] __link_path_walk+0x522/0x880
[157340.953945] [<ffffffff8115a6f6>] path_walk+0x66/0xd0
[157340.953953] [<ffffffff8115a7cb>] do_path_lookup+0x6b/0xb0
[157340.953957] [<ffffffff8115a9d1>] user_path_at+0x61/0xc0
[157340.953962] [<ffffffff811514d1>] vfs_fstatat+0x41/0x90
[157340.953967] [<ffffffff81151549>] sys_newfstatat+0x29/0x60
[157340.953973] [<ffffffff8100c682>] system_call_fastpath+0x16/0x1b
[157340.953986] [<00007fd51c9e50ee>] 0x7fd51c9e50ee
[157573.164556] Filesystem "dm-0": corrupt inode 2195133988 ((a)extents = 5). Unmount and run xfs_repair.
[157573.164584] ffff8800928b6400: 49 4e 81 c0 02 02 00 00 00 00 03 e8 00 00 00 64 IN.............d
[157573.164608] 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 0xffffffffa03380ad
[157573.164615]
[157573.164646] Pid: 27064, comm: du Not tainted 2.6.31.12-0.2-desktop #1
[157573.164659] Call Trace:
[157573.164688] [<ffffffff81011a19>] try_stack_unwind+0x189/0x1b0
[157573.164710] [<ffffffff8101025d>] dump_trace+0xad/0x3a0
[157573.164729] [<ffffffff81011524>] show_trace_log_lvl+0x64/0x90
[157573.164747] [<ffffffff81011573>] show_trace+0x23/0x40
[157573.164765] [<ffffffff81552b46>] dump_stack+0x81/0x9e
[157573.164833] [<ffffffffa032db4a>] xfs_error_report+0x5a/0x70 [xfs]
[157573.164988] [<ffffffffa032dbcc>] xfs_corruption_error+0x6c/0x90 [xfs]
[157573.165151] [<ffffffffa0337b84>] xfs_iformat_extents+0x234/0x280 [xfs]
[157573.165317] [<ffffffffa03380ad>] xfs_iformat+0x28d/0x5a0 [xfs]
[157573.165477] [<ffffffffa0338542>] xfs_iread+0x182/0x1c0 [xfs]
[157573.165640] [<ffffffffa0333938>] xfs_iget_cache_miss+0x78/0x250 [xfs]
[157573.165794] [<ffffffffa0333c3c>] xfs_iget+0x12c/0x1b0 [xfs]
[157573.165951] [<ffffffffa0353b8e>] xfs_lookup+0xce/0x100 [xfs]
[157573.166169] [<ffffffffa0360e6c>] xfs_vn_lookup+0x6c/0xc0 [xfs]
[157573.166366] [<ffffffff81157782>] real_lookup+0x102/0x180
[157573.166387] [<ffffffff811598c0>] do_lookup+0xd0/0x100
[157573.166406] [<ffffffff81159e12>] __link_path_walk+0x522/0x880
[157573.166425] [<ffffffff8115a6f6>] path_walk+0x66/0xd0
[157573.166443] [<ffffffff8115a7cb>] do_path_lookup+0x6b/0xb0
[157573.166461] [<ffffffff8115a9d1>] user_path_at+0x61/0xc0
[157573.166481] [<ffffffff811514d1>] vfs_fstatat+0x41/0x90
[157573.166500] [<ffffffff81151549>] sys_newfstatat+0x29/0x60
[157573.166520] [<ffffffff8100c682>] system_call_fastpath+0x16/0x1b
[157573.166551] [<00007f63d57480ee>] 0x7f63d57480ee
> > xfs_repair version 3.1.2
> which kernel, again? The fork offset problems smell like something
> that's fixed.
openSUSE 11.2 with it's latest kernel, 2.6.31.12-0.2-desktop
But as I said: fresh disks, fresh XFS, copied from another server with rsync, no crashes,
not even a reboot. Why the problems?
--
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.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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: xfs_repair 3.1.2 crashing
2010-06-12 1:38 ` Eric Sandeen
2010-06-12 10:41 ` Michael Monnerie
@ 2010-06-12 13:33 ` Michael Monnerie
2010-06-14 12:47 ` Michael Monnerie
1 sibling, 1 reply; 8+ messages in thread
From: Michael Monnerie @ 2010-06-12 13:33 UTC (permalink / raw)
To: xfs
[-- Attachment #1.1: Type: Text/Plain, Size: 9876 bytes --]
On Samstag, 12. Juni 2010 Eric Sandeen wrote:
> > I got this message after making a "du -s" on the new disks:
> > du: cannot access
> > `samba/backup/uranus/WindowsImageBackup/uranus/Backup 2010-06-05
> > 010014/852c2690-cf1a-11de-b09b-806e6f6e6963.vhd': Structure needs
> > cleaning
>
> dmesg would be the right thing to do here ...
Here a similar problem on the original server, with the file
/disks/daten/samba/tmp/installtemp/askalani-20100526.tib
This is the server that crashed, so I forgive XFS the error.
It looks the same to me, and I wonder if I triggered a bug somewhere.
dmesg says:
[167981.222124] Filesystem "dm-0": corrupt inode 2267035928 ((a)extents = 7). Unmount and run xfs_repair.
[167981.222130] ffff8800c068c800: 49 4e 81 fc 02 02 00 00 00 00 04 e5 00 00 00 64 IN.............d
[167981.222134] Filesystem "dm-0": XFS internal error xfs_iformat_extents(1) at line 558 of file /usr/src/packages/BUILD/kernel-xen-2.6.31.12/linux-2.6.31/fs/xfs/xfs_inode.c. Caller 0xffffffffa019c44d
[167981.222136]
[167981.222140] Pid: 13802, comm: ls Not tainted 2.6.31.12-0.2-xen #1
[167981.222142] Call Trace:
[167981.222156] [<ffffffff800119b9>] try_stack_unwind+0x189/0x1b0
[167981.222163] [<ffffffff8000f466>] dump_trace+0xa6/0x1e0
[167981.222167] [<ffffffff800114c4>] show_trace_log_lvl+0x64/0x90
[167981.222171] [<ffffffff80011513>] show_trace+0x23/0x40
[167981.222176] [<ffffffff8046b92c>] dump_stack+0x81/0x9e
[167981.222213] [<ffffffffa0191d5a>] xfs_error_report+0x5a/0x70 [xfs]
[167981.222309] [<ffffffffa0191ddc>] xfs_corruption_error+0x6c/0x90 [xfs]
[167981.222355] [<ffffffffa019bf24>] xfs_iformat_extents+0x234/0x280 [xfs]
[167981.222407] [<ffffffffa019c44d>] xfs_iformat+0x28d/0x5a0 [xfs]
[167981.222458] [<ffffffffa019c8e2>] xfs_iread+0x182/0x1c0 [xfs]
[167981.222541] [<ffffffffa0197cc8>] xfs_iget_cache_miss+0x78/0x200 [xfs]
[167981.222590] [<ffffffffa0197f79>] xfs_iget+0x129/0x1d0 [xfs]
[167981.222640] [<ffffffffa01b888e>] xfs_lookup+0xce/0x100 [xfs]
[167981.222711] [<ffffffffa01c5cac>] xfs_vn_lookup+0x6c/0xc0 [xfs]
[167981.222825] [<ffffffff80124702>] real_lookup+0x102/0x180
[167981.222830] [<ffffffff80126bc0>] do_lookup+0xd0/0x100
[167981.222835] [<ffffffff80127a98>] __link_path_walk+0x7f8/0xf40
[167981.222838] [<ffffffff801283f6>] path_walk+0x66/0xd0
[167981.222842] [<ffffffff801285cb>] do_path_lookup+0x6b/0xb0
[167981.222846] [<ffffffff80129531>] user_path_at+0x61/0xc0
[167981.222850] [<ffffffff8011e501>] vfs_fstatat+0x41/0x90
[167981.222853] [<ffffffff8011e5dc>] vfs_lstat+0x2c/0x50
[167981.222857] [<ffffffff8011e62e>] sys_newlstat+0x2e/0x70
[167981.222861] [<ffffffff8000c868>] system_call_fastpath+0x16/0x1b
[167981.222870] [<00007f9decb1ce65>] 0x7f9decb1ce65
[167985.423311] Filesystem "dm-0": corrupt inode 2267035928 ((a)extents = 7). Unmount and run xfs_repair.
[167985.423317] ffff8800c068c800: 49 4e 81 fc 02 02 00 00 00 00 04 e5 00 00 00 64 IN.............d
[167985.423322] Filesystem "dm-0": XFS internal error xfs_iformat_extents(1) at line 558 of file /usr/src/packages/BUILD/kernel-xen-2.6.31.12/linux-2.6.31/fs/xfs/xfs_inode.c. Caller 0xffffffffa019c44d
[167985.423324]
[167985.423328] Pid: 13803, comm: ls Not tainted 2.6.31.12-0.2-xen #1
[167985.423330] Call Trace:
[167985.423344] [<ffffffff800119b9>] try_stack_unwind+0x189/0x1b0
[167985.423397] [<ffffffff8000f466>] dump_trace+0xa6/0x1e0
[167985.423402] [<ffffffff800114c4>] show_trace_log_lvl+0x64/0x90
[167985.423406] [<ffffffff80011513>] show_trace+0x23/0x40
[167985.423411] [<ffffffff8046b92c>] dump_stack+0x81/0x9e
[167985.423446] [<ffffffffa0191d5a>] xfs_error_report+0x5a/0x70 [xfs]
[167985.423495] [<ffffffffa0191ddc>] xfs_corruption_error+0x6c/0x90 [xfs]
[167985.423538] [<ffffffffa019bf24>] xfs_iformat_extents+0x234/0x280 [xfs]
[167985.423588] [<ffffffffa019c44d>] xfs_iformat+0x28d/0x5a0 [xfs]
[167985.423636] [<ffffffffa019c8e2>] xfs_iread+0x182/0x1c0 [xfs]
[167985.423727] [<ffffffffa0197cc8>] xfs_iget_cache_miss+0x78/0x200 [xfs]
[167985.423775] [<ffffffffa0197f79>] xfs_iget+0x129/0x1d0 [xfs]
[167985.423824] [<ffffffffa01b888e>] xfs_lookup+0xce/0x100 [xfs]
[167985.423924] [<ffffffffa01c5cac>] xfs_vn_lookup+0x6c/0xc0 [xfs]
[167985.423985] [<ffffffff80124702>] real_lookup+0x102/0x180
[167985.423991] [<ffffffff80126bc0>] do_lookup+0xd0/0x100
[167985.423995] [<ffffffff80127a98>] __link_path_walk+0x7f8/0xf40
[167985.423999] [<ffffffff801283f6>] path_walk+0x66/0xd0
[167985.424003] [<ffffffff801285cb>] do_path_lookup+0x6b/0xb0
[167985.424007] [<ffffffff80129531>] user_path_at+0x61/0xc0
[167985.424011] [<ffffffff8011e501>] vfs_fstatat+0x41/0x90
[167985.424014] [<ffffffff8011e5dc>] vfs_lstat+0x2c/0x50
[167985.424018] [<ffffffff8011e62e>] sys_newlstat+0x2e/0x70
[167985.424022] [<ffffffff8000c868>] system_call_fastpath+0x16/0x1b
[167985.424031] [<00007f56f3525e65>] 0x7f56f3525e65
--
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.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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: xfs_repair 3.1.2 crashing
2010-06-12 13:33 ` Michael Monnerie
@ 2010-06-14 12:47 ` Michael Monnerie
0 siblings, 0 replies; 8+ messages in thread
From: Michael Monnerie @ 2010-06-14 12:47 UTC (permalink / raw)
To: xfs
[-- Attachment #1.1: Type: Text/Plain, Size: 1504 bytes --]
On Samstag, 12. Juni 2010 Michael Monnerie wrote:
> [167981.222861] [<ffffffff8000c868>]
> system_call_fastpath+0x16/0x1b
Now it's becoming weird. I had that crash with a directory named
/disks/daten/samba/backup/uranus/WindowsImageBackup/uranus/Backup\
2010-06-12\ 010016/ /bigbackup/Backup\ 2010-06-05\ 010014/
and the file in there is
852c2690-cf1a-11de-b09b-806e6f6e6963.vhd
I moved that broken dir away to /, and did a new rsync. And, guess what,
I got the same again: the file inside this dir is broken. The 3rd rsync
did not make the same error, it seems good. The problem is that the dump
is not the same any more, as that PC made a new image in the meantime.
But as I got the same error twice on copy via rsync from one PC to
another, it looks like I triggered the error just by copying via "rsync
-aPvHAXy source destpc::dest/".
I did an xfs_metadump and just left the 2 broken dirs inside, so you can
easily verify:
http://zmi.at/backup-metadump-20100614-broken.bz2
xfs_repair 3.1.2 can't repair that, it crashes.
The filesystem is mounted with these options:
relatime,logbufs=8,logbsize=256k,attr2,barrier,largeio,swalloc,allocsize=256k
--
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.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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: xfs_repair 3.1.2 crashing
2010-06-12 10:41 ` Michael Monnerie
@ 2010-06-23 18:32 ` Michael Monnerie
0 siblings, 0 replies; 8+ messages in thread
From: Michael Monnerie @ 2010-06-23 18:32 UTC (permalink / raw)
To: xfs, Eric Sandeen
[-- Attachment #1.1: Type: Text/Plain, Size: 2920 bytes --]
On Samstag, 12. Juni 2010 Michael Monnerie wrote:
> openSUSE 11.2 with it's latest kernel, 2.6.31.12-0.2-desktop
Any news here? I'd need a fix, is there a chance to get back the contents of this file?
[212428.619676] Filesystem "dm-0": corrupt inode 2267035928 ((a)extents = 7). Unmount and run xfs_repair.
[212428.619681] ffff8800f3a9a800: 49 4e 81 fc 02 02 00 00 00 00 04 e5 00 00 00 64 IN.............d
[212428.619686] Filesystem "dm-0": XFS internal error xfs_iformat_extents(1) at line 558 of file /usr/src/packages/BUILD/kernel-xen-2.6.31.12/linux-2.6.31/fs/xfs/xfs_inode.c. Caller 0xffffffffa019c44d
[212428.619688]
[212428.619691] Pid: 13006, comm: ls Not tainted 2.6.31.12-0.2-xen #1
[212428.619694] Call Trace:
[212428.619707] [<ffffffff800119b9>] try_stack_unwind+0x189/0x1b0
[212428.619714] [<ffffffff8000f466>] dump_trace+0xa6/0x1e0
[212428.619718] [<ffffffff800114c4>] show_trace_log_lvl+0x64/0x90
[212428.619722] [<ffffffff80011513>] show_trace+0x23/0x40
[212428.619727] [<ffffffff8046b92c>] dump_stack+0x81/0x9e
[212428.619761] [<ffffffffa0191d5a>] xfs_error_report+0x5a/0x70 [xfs]
[212428.619810] [<ffffffffa0191ddc>] xfs_corruption_error+0x6c/0x90 [xfs]
[212428.619853] [<ffffffffa019bf24>] xfs_iformat_extents+0x234/0x280 [xfs]
[212428.619903] [<ffffffffa019c44d>] xfs_iformat+0x28d/0x5a0 [xfs]
[212428.619951] [<ffffffffa019c8e2>] xfs_iread+0x182/0x1c0 [xfs]
[212428.620000] [<ffffffffa0197cc8>] xfs_iget_cache_miss+0x78/0x200 [xfs]
[212428.620046] [<ffffffffa0197f79>] xfs_iget+0x129/0x1d0 [xfs]
[212428.620094] [<ffffffffa01b888e>] xfs_lookup+0xce/0x100 [xfs]
[212428.620158] [<ffffffffa01c5cac>] xfs_vn_lookup+0x6c/0xc0 [xfs]
[212428.620220] [<ffffffff80124702>] real_lookup+0x102/0x180
[212428.620225] [<ffffffff80126bc0>] do_lookup+0xd0/0x100
[212428.620229] [<ffffffff80127a98>] __link_path_walk+0x7f8/0xf40
[212428.620233] [<ffffffff801283f6>] path_walk+0x66/0xd0
[212428.620237] [<ffffffff801285cb>] do_path_lookup+0x6b/0xb0
[212428.620240] [<ffffffff80129531>] user_path_at+0x61/0xc0
[212428.620244] [<ffffffff8011e501>] vfs_fstatat+0x41/0x90
[212428.620248] [<ffffffff8011e5dc>] vfs_lstat+0x2c/0x50
[212428.620251] [<ffffffff8011e62e>] sys_newlstat+0x2e/0x70
[212428.620254] [<ffffffff8000c868>] system_call_fastpath+0x16/0x1b
[212428.620263] [<00007fcb58264e65>] 0x7fcb58264e65
--
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.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
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2010-06-23 18:30 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-06-10 11:06 xfs_repair 3.1.2 crashing Michael Monnerie
2010-06-10 16:27 ` Eric Sandeen
2010-06-11 23:38 ` Michael Monnerie
2010-06-12 1:38 ` Eric Sandeen
2010-06-12 10:41 ` Michael Monnerie
2010-06-23 18:32 ` Michael Monnerie
2010-06-12 13:33 ` Michael Monnerie
2010-06-14 12:47 ` Michael Monnerie
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox