* corruption, xfs_repair 3.1.4 segfaults
@ 2011-03-02 17:58 Marc Lehmann
2011-03-02 21:43 ` Emmanuel Florac
2011-03-04 15:07 ` corruption, xfs_repair 3.1.4 segfaults Eric Sandeen
0 siblings, 2 replies; 11+ messages in thread
From: Marc Lehmann @ 2011-03-02 17:58 UTC (permalink / raw)
To: xfs
Hi!
I had a case of filesystem corruption a day ago:
Mar 1 21:31:28 doom kernel: [566626.329885] ffff880082a8f400: f3 6e 16 9b 4e ae cd 1c 49 75 21 65 86 c0 8c 3a .n..N...Iu!e...:
2/debian/build/source_amd64_none/fs/xfs/xfs_btree.c. Caller 0xffffffffa10721d0
Mar 1 21:31:28 doom kernel: [566626.329902] Filesystem "loop18": XFS internal error xfs_btree_check_sblock at line 124 of file /build/buildd-linux-2.6_2.6.32-30-amd64-d4MbNM/linux-2.6-2.6.3
Mar 1 21:31:28 doom kernel: [566626.329909]
Mar 1 21:31:28 doom kernel: [566626.329918] Pid: 27165, comm: expire Tainted: P C 2.6.32-5-amd64 #1
Mar 1 21:31:28 doom kernel: [566626.329923] Call Trace:
Mar 1 21:31:28 doom kernel: [566626.329973] [<ffffffffa10721d0>] ? xfs_btree_read_buf_block+0x6d/0x8f [xfs]
Mar 1 21:31:28 doom kernel: [566626.330005] [<ffffffffa10720a7>] ? xfs_btree_check_sblock+0xbd/0xc4 [xfs]
Mar 1 21:31:28 doom kernel: [566626.330037] [<ffffffffa10721d0>] ? xfs_btree_read_buf_block+0x6d/0x8f [xfs]
Mar 1 21:31:28 doom kernel: [566626.330068] [<ffffffffa10721d0>] ? xfs_btree_read_buf_block+0x6d/0x8f [xfs]
Mar 1 21:31:28 doom kernel: [566626.330100] [<ffffffffa10731d7>] ? xfs_btree_lookup_get_block+0x87/0xac [xfs]
Mar 1 21:31:28 doom kernel: [566626.330132] [<ffffffffa107379d>] ? xfs_btree_lookup+0x12a/0x3cc [xfs]
Mar 1 21:31:28 doom kernel: [566626.330166] [<ffffffffa109d70e>] ? kmem_zone_zalloc+0x1e/0x2e [xfs]
Mar 1 21:31:28 doom kernel: [566626.330194] [<ffffffffa10620e2>] ? xfs_allocbt_init_cursor+0x35/0x91 [xfs]
Mar 1 21:31:28 doom kernel: [566626.330222] [<ffffffffa105fe75>] ? xfs_free_ag_extent+0x5b/0x665 [xfs]
Mar 1 21:31:28 doom kernel: [566626.330251] [<ffffffffa1061c2f>] ? xfs_free_extent+0x9a/0xb8 [xfs]
Mar 1 21:31:28 doom kernel: [566626.330284] [<ffffffffa10989fa>] ? xfs_trans_get_efd+0x21/0x29 [xfs]
Mar 1 21:31:28 doom kernel: [566626.330315] [<ffffffffa106d02a>] ? xfs_bmap_finish+0xef/0x162 [xfs]
Mar 1 21:31:28 doom kernel: [566626.330349] [<ffffffffa1087050>] ? xfs_itruncate_finish+0x17d/0x295 [xfs]
Mar 1 21:31:28 doom kernel: [566626.330383] [<ffffffffa109bf69>] ? xfs_inactive+0x1d4/0x3f0 [xfs]
Mar 1 21:31:28 doom kernel: [566626.330395] [<ffffffff810fff23>] ? clear_inode+0x79/0xd0
Mar 1 21:31:28 doom kernel: [566626.330403] [<ffffffff8110066c>] ? generic_delete_inode+0xf4/0x168
Mar 1 21:31:28 doom kernel: [566626.330411] [<ffffffff810f935c>] ? do_unlinkat+0xf7/0x149
Mar 1 21:31:28 doom kernel: [566626.330419] [<ffffffff810ef19e>] ? sys_write+0x60/0x6e
Mar 1 21:31:28 doom kernel: [566626.330428] [<ffffffff81010b42>] ? system_call_fastpath+0x16/0x1b
amd64_none/fs/xfs/xfs_bmap.c. Return address = 0xffffffffa106d05f
Mar 1 21:31:28 doom kernel: [566626.330448] xfs_force_shutdown(loop18,0x8) called from line 4341 of file /build/buildd-linux-2.6_2.6.32-30-amd64-d4MbNM/linux-2.6-2.6.32/debian/build/source_
Mar 1 21:31:28 doom kernel: [566626.342806] Filesystem "loop18": Corruption of in-memory data detected. Shutting down filesystem: loop18
Mar 1 21:31:28 doom kernel: [566626.342819] Please umount the filesystem, and rectify the problem(s)
I tried to use xfs_repair on it, but it crashes (and, as I may grudgingly
add, as usual it crashes because thats what xfsrepair does almost always).
The xfs_repair is from debians xfsprogs 3.1.4, and here is an strace just
before it crashes:
pread(4, "IN\201\200\2\2\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\6"..., 8192, 125284311040) = 8192
pread(4, "IN\201\200\2\2\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\6"..., 8192, 125284319232) = 8192
pread(4, "IN\201\200\2\2\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\6"..., 8192, 125284327424) = 8192
pread(4, "IN\201\200\2\2\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\10"..., 8192, 125284483072) = 8192
pread(4, "INA\300\2\2\0\0\0\0\0\0\0\0\0\0\0\0\0\2\0\0\0\0\0\0\0\0\0\0\0\f"..., 8192, 125284491264) = 8192
pread(4, "XD2D\0000\17\320\0\0\0\0\0\0\0\0\0\0\0\0 \17q\234\1.\\\237\321\16\0\20"..., 4096, 126276620288) = 4096
pread(4, "XD2D\0\340\0010\0\20\0\300\2\340\0\260\377\377\0\300\223\370_\347\003508\0\311\0\20"..., 4096, 126284730880) = 4096
pread(4, "XD2D\t \6\340\3`\1\200\0\240\1p\377\377\0\20\223\370\251\235\003763\0\0\0\20"..., 4096, 126284970496) = 4096
pread(4, "XD2D\0000\7\200\t\20\0\360\n\20\0\360\0\0\0\0 \17q\237\1.+\2000\214\0\20"..., 4096, 126333133824) = 4096
pread(4, "XD2D\1`\16\240\0\20\1@\0\0\0\0\377\377\1@\224\254\204,\003253\0\311\0\20"..., 4096, 126338785792) = 4096
pread(4, "XD2D\6\360\t\20\0\20\5\340\0060\0\260\377\377\5\340\224\255\7d\003508\0\0\0\20"..., 4096, 126341941760) = 4096
pread(4, "XD2D\10\340\7 \0000\4\260\6\220\2@\0\0\0\0 \17q\240\1.\21y\0\210\0\20"..., 4096, 126343030272) = 4096
pread(4, "XD2D\0\20\t\300\t\340\6 \0\0\0\0\377\377\t\300\225\37t\346\003253\0\210\0\20"..., 4096, 126343054848) = 4096
pread(4, "XD2D\0000\17\320\0\0\0\0\0\0\0\0\0\0\0\0 \17q\242\1.\0\0\0\0\0\20"..., 4096, 125026532864) = 4096
pread(4, "XD2D\7p\10\220\0\20\5@\6\360\0 \377\377\5@\226\fi\275\003508\0\0\0\20"..., 4096, 125026524672) = 4096
mmap(NULL, 3107426304, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f84388d1000
pread(4, 0x7f84388d1200, 18446744072522006528, 51859947520) = -1 EFAULT (Bad address)
open("/usr/share/locale/en_US.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en_US.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en_US/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en.utf8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
write(2, "xfs_repair: read failed: Bad add"..., 37) = 37
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
apparently an mmap goes wrong (and if mmap fails, xfs_repair crashes here
already), and then it tries to read a block beyond the end of the device,
and then crashes.
Any idea on where to go from here? I tried to build the git xfsprogs, but
they don't build due to missing -fPIC - and as usual, thanks for any help :)
Here is the output from the xfs_repair run:
xfs_repair -m 990 -P /dev/loop18
Phase 1 - find and verify superblock...
Phase 2 - using internal log
- zero log...
- scan filesystem freespace and inode maps...
bad magic # 0x103404f in btbno block 9/10857
expected level 0 got 33692 in btbno block 9/10857
bad btree nrecs (42150, min=31, max=62) in btbno block 9/10857
invalid start block 2293577425 in record 0 of 4629836 btree block 9/10857
invalid start block 2285812568 in record 1 of 4629836 btree block 9/10857
invalid start block 1881255310 in record 2 of 4629836 btree block 9/10857
invalid start block 3446559310 in record 3 of 4629836 btree block 9/10857
invalid start block 675798585 in record 4 of 4629836 btree block 9/10857
invalid start block 1988423791 in record 5 of 4629836 btree block 9/10857
invalid start block 1478079706 in record 6 of 4629836 btree block 9/10857
invalid start block 988724204 in record 7 of 4629836 btree block 9/10857
invalid start block 2507314510 in record 8 of 4629836 btree block 9/10857
invalid start block 2971518545 in record 9 of 4629836 btree block 9/10857
invalid start block 690057367 in record 10 of 4629836 btree block 9/10857
invalid start block 2865073461 in record 11 of 4629836 btree block 9/10857
invalid start block 1912136343 in record 12 of 4629836 btree block 9/10857
invalid start block 2593100555 in record 13 of 4629836 btree block 9/10857
invalid start block 1890364231 in record 14 of 4629836 btree block 9/10857
invalid start block 1138733060 in record 15 of 4629836 btree block 9/10857
invalid start block 1780107146 in record 16 of 4629836 btree block 9/10857
invalid start block 2459595538 in record 17 of 4629836 btree block 9/10857
invalid length 967647152 in record 18 of 4629836 btree block 9/10857
invalid start block 2356139990 in record 19 of 4629836 btree block 9/10857
invalid start block 3025317822 in record 20 of 4629836 btree block 9/10857
invalid start block 2576064389 in record 21 of 4629836 btree block 9/10857
invalid start block 2951059818 in record 22 of 4629836 btree block 9/10857
invalid start block 318397717 in record 23 of 4629836 btree block 9/10857
invalid start block 433828196 in record 24 of 4629836 btree block 9/10857
block (9,33424265-33424265) multiply claimed by bno space tree, state - 7
block (9,56547788-56547788) multiply claimed by bno space tree, state - 7
block (9,67118454-67118454) multiply claimed by bno space tree, state - 7
block (9,67118456-67118456) multiply claimed by bno space tree, state - 7
block (9,67118459-67118459) multiply claimed by bno space tree, state - 7
block (9,67118462-67118462) multiply claimed by bno space tree, state - 7
block (9,67118511-67118512) multiply claimed by bno space tree, state - 7
block (9,67118515-67118515) multiply claimed by bno space tree, state - 7
[... lots of similar lines snipped...]
invalid start block 3236179925 in record 57 of 4629832 btree block 9/10795
invalid start block 410235468 in record 58 of 4629832 btree block 9/10795
invalid start block 3353408206 in record 59 of 4629832 btree block 9/10795
invalid start block 1222326613 in record 60 of 4629832 btree block 9/10795
invalid start block 1521123165 in record 61 of 4629832 btree block 9/10795
cnt freespace btree block claimed (state 1), agno 9, bno 56547789, suspect 0
agf_freeblks 7328791, counted 4374413 in ag 9
agf_longest 32866, counted 4292013384 in ag 9
sb_icount 0, counted 4854528
sb_ifree 0, counted 328679
sb_fdblocks 0, counted 4487315964
- 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
- agno = 2
xfs_repair: read failed: Bad address
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / schmorp@schmorp.de
-=====/_/_//_/\_,_/ /_/\_\
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: corruption, xfs_repair 3.1.4 segfaults
2011-03-02 17:58 corruption, xfs_repair 3.1.4 segfaults Marc Lehmann
@ 2011-03-02 21:43 ` Emmanuel Florac
2011-03-04 7:11 ` Marc Lehmann
2011-03-04 15:07 ` corruption, xfs_repair 3.1.4 segfaults Eric Sandeen
1 sibling, 1 reply; 11+ messages in thread
From: Emmanuel Florac @ 2011-03-02 21:43 UTC (permalink / raw)
To: Marc Lehmann; +Cc: xfs
Le Wed, 2 Mar 2011 18:58:18 +0100 vous écriviez:
> I had a case of filesystem corruption a day ago:
>
What's the kernel version? It's apparently a loopback device, what is
mounted and how? Your log looks quite hopeless at first glance...
--
------------------------------------------------------------------------
Emmanuel Florac | Direction technique
| Intellique
| <eflorac@intellique.com>
| +33 1 78 94 84 02
------------------------------------------------------------------------
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: corruption, xfs_repair 3.1.4 segfaults
2011-03-02 21:43 ` Emmanuel Florac
@ 2011-03-04 7:11 ` Marc Lehmann
2011-03-04 7:51 ` Emmanuel Florac
0 siblings, 1 reply; 11+ messages in thread
From: Marc Lehmann @ 2011-03-04 7:11 UTC (permalink / raw)
To: xfs
On Wed, Mar 02, 2011 at 10:43:29PM +0100, Emmanuel Florac <eflorac@intellique.com> wrote:
> Le Wed, 2 Mar 2011 18:58:18 +0100 vous écriviez:
>
> > I had a case of filesystem corruption a day ago:
> >
Thanks for your reply (and sorry for apparrently submitting my mail
multiple times - the crashed machine is also the mail relay and had some
trouble).
> What's the kernel version? It's apparently a loopback device, what is
> mounted and how?
Right... it's 2.6.32-5-amd64 (the debian squeeze kernel), and it is indeed a
loopback device.
It's normally mounted like this:
mount -orelatime,biosize=28,logbufs=8,logbsize=256k,allocsize=8k,inode64,largeio ...
There are five logical volumes on this machine which are mounted via
loopback device, all XFS. The other ones seem to work fine.
> Your log looks quite hopeless at first glance...
I hope not :) I can mount the volume read-only, and apparently read a lot
of files on it. My main problem seems to be the crashing xfs_repair.
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / schmorp@schmorp.de
-=====/_/_//_/\_,_/ /_/\_\
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: corruption, xfs_repair 3.1.4 segfaults
2011-03-04 7:11 ` Marc Lehmann
@ 2011-03-04 7:51 ` Emmanuel Florac
2011-03-04 10:29 ` Marc Lehmann
0 siblings, 1 reply; 11+ messages in thread
From: Emmanuel Florac @ 2011-03-04 7:51 UTC (permalink / raw)
To: Marc Lehmann; +Cc: xfs
Le Fri, 4 Mar 2011 08:11:23 +0100 vous écriviez:
> I hope not :) I can mount the volume read-only, and apparently read a
> lot of files on it. My main problem seems to be the crashing
> xfs_repair.
>
Ah, I think the problem may lie in the loop device. Try to run
xfs_repair -f /file/path
(not using the loop device).
--
------------------------------------------------------------------------
Emmanuel Florac | Direction technique
| Intellique
| <eflorac@intellique.com>
| +33 1 78 94 84 02
------------------------------------------------------------------------
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: corruption, xfs_repair 3.1.4 segfaults
2011-03-04 7:51 ` Emmanuel Florac
@ 2011-03-04 10:29 ` Marc Lehmann
2011-03-04 11:14 ` Emmanuel Florac
0 siblings, 1 reply; 11+ messages in thread
From: Marc Lehmann @ 2011-03-04 10:29 UTC (permalink / raw)
To: xfs
On Fri, Mar 04, 2011 at 08:51:46AM +0100, Emmanuel Florac <eflorac@intellique.com> wrote:
> Ah, I think the problem may lie in the loop device. Try to run
At least the xfs_repair problem cannot be in the loop device:
>From the strace it's obvious that xfs_repair tries to read close to 2**64
bytes, and then crashes when the kernel rightly says that it can't do that.
It also shows that xfs_repair tries to allocate 3gb of memory (which is in
addition to the 1gb it already uses at that point), which is far more then
it should (specifying -m 990 didn't change that), which is another bug in
xfs_repair.
I think that, no matter what the loop device would do, xfs_repair is buggy
- it simply shouldn't crash, no matter how corrupted the filesystem is.
As a sidenote, I am now about 30% in recovering (copying) and
verifying the data, and it seems the volume isn't corrupted completely
(fortunately), so I can probably recover the important stuff, and reformat
the partition, so this might not turn out to be data loss (fortunately :).
> xfs_repair -f /file/path
>
> (not using the loop device).
that will not work, as xfs_repair has no encryption support (which is why
the loop device is used in the first place).
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / schmorp@schmorp.de
-=====/_/_//_/\_,_/ /_/\_\
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: corruption, xfs_repair 3.1.4 segfaults
2011-03-04 10:29 ` Marc Lehmann
@ 2011-03-04 11:14 ` Emmanuel Florac
2011-03-04 16:31 ` Marc Lehmann
2011-03-04 17:30 ` corruption, xfs_repair 3.1.4 segfaults, xfs_repair 2.9.8 works Marc Lehmann
0 siblings, 2 replies; 11+ messages in thread
From: Emmanuel Florac @ 2011-03-04 11:14 UTC (permalink / raw)
To: Marc Lehmann; +Cc: xfs
Le Fri, 4 Mar 2011 11:29:39 +0100
Marc Lehmann <schmorp@schmorp.de> écrivait:
> I think that, no matter what the loop device would do, xfs_repair is
> buggy
> - it simply shouldn't crash, no matter how corrupted the filesystem
> is.
>
That's true. After you've copied everything, you could try using
Lenny's xfs_repair (v 2.9.x IIRC). Just in case, it may do better.
--
------------------------------------------------------------------------
Emmanuel Florac | Direction technique
| Intellique
| <eflorac@intellique.com>
| +33 1 78 94 84 02
------------------------------------------------------------------------
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: corruption, xfs_repair 3.1.4 segfaults
2011-03-04 11:14 ` Emmanuel Florac
@ 2011-03-04 16:31 ` Marc Lehmann
2011-03-04 19:18 ` Eric Sandeen
2011-03-04 17:30 ` corruption, xfs_repair 3.1.4 segfaults, xfs_repair 2.9.8 works Marc Lehmann
1 sibling, 1 reply; 11+ messages in thread
From: Marc Lehmann @ 2011-03-04 16:31 UTC (permalink / raw)
To: xfs
On Fri, Mar 04, 2011 at 12:14:07PM +0100, Emmanuel Florac <eflorac@intellique.com> wrote:
> > I think that, no matter what the loop device would do, xfs_repair is
> > - it simply shouldn't crash, no matter how corrupted the filesystem
>
> That's true. After you've copied everything, you could try using
It seems only a single directory was not readable (which is a backup), so all
data could be recovered. I am currently checking md5sums, but it seems that's
indeed it.
Which might make sense, as xfs_repair crashes after reading a XD2D
block. The backtrace I get when using rsync to copy over files also
supports this:
http://ue.tst.eu/2bda1b4532cc66248763f723988093ce.txt
> Lenny's xfs_repair (v 2.9.x IIRC). Just in case, it may do better.
I will give that a shot, thanks for the hint, I will report back on this.
On Fri, Mar 04, 2011 at 09:07:09AM -0600, Eric Sandeen <sandeen@sandeen.net> wrote:
> > I had a case of filesystem corruption a day ago:
>
> If you provide an xfs_metadump image of the filesystem, I'd be
> happy to look into the cause of the segfault.
That is the second thing that came to my mind, but this disk contains
sensitive data, and as long as the anonymise/obfuscate option of xfs_metadump
is broken (a simple hexdump reveals most of the filenames it's supposed to
obfuscate), I unfortunately cannot.
(the xfs_metadump -o bug has been reported in the past btw., if it's fixed
in git I could give thta another try).
> In my experience xfs_repair does not almost always crash, if you
> encounter this, please do send mail/file bugs/provide images.
Well, I did (as well as other people did), in the past, and the bugs
that were reported wree fixed (For example, I stumbled over the problem
of the xfs_repair livelock with threads, I stumbled over the problem of
it not being able to repair corruption a number of times despite saying
everything is ok and so on).
So "crash" was indeed badly worded - "does not fix things or does not run to
completion" is more correct.
The fact remains that of reiserfs, ext2/3/4 and jfs, xfs has by far the
lowest quality fsck, at least for me - each time I have some problem with an
xfs filesystem, xfs_repair fails to repair it.
It fortunately doesn't happen often, and is not necessarily a problem with
xfs itself, but I am using reiserfs and ext2/3/4 and xfs all for a very
long time, and of these, it's quite obvious that xfs_repair is much worse
then the fsck tools of the others.
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / schmorp@schmorp.de
-=====/_/_//_/\_,_/ /_/\_\
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: corruption, xfs_repair 3.1.4 segfaults
2011-03-04 16:31 ` Marc Lehmann
@ 2011-03-04 19:18 ` Eric Sandeen
0 siblings, 0 replies; 11+ messages in thread
From: Eric Sandeen @ 2011-03-04 19:18 UTC (permalink / raw)
To: Marc Lehmann; +Cc: xfs
On 3/4/11 10:31 AM, Marc Lehmann wrote:
> On Fri, Mar 04, 2011 at 09:07:09AM -0600, Eric Sandeen <sandeen@sandeen.net> wrote:
>>> I had a case of filesystem corruption a day ago:
>>
>> If you provide an xfs_metadump image of the filesystem, I'd be
>> happy to look into the cause of the segfault.
>
> That is the second thing that came to my mind, but this disk contains
> sensitive data, and as long as the anonymise/obfuscate option of xfs_metadump
> is broken (a simple hexdump reveals most of the filenames it's supposed to
> obfuscate), I unfortunately cannot.
Do you have a lot of short names? It should be obfuscating the others
just fine. Otherwise, Alex has been working on the obfuscation, maybe
he can give you some pointers.
BTW no need to run hexdump; you can xfs_mdrestore the dump, and loopback
mount it, and do a find to see what filenames are there.
(unless you mean the clear names are seen in hexdump but not on the
mounted, restored fs? If so that's a new and interesting problem).
> (the xfs_metadump -o bug has been reported in the past btw., if it's fixed
> in git I could give thta another try).
well... "-o" DISABLEs obfuscation. If you use it and see all filenames,
that is exactly as it should be working ;) Don't use -o if you want
obfuscation (I know, it seems a little backwards to me too).
>> In my experience xfs_repair does not almost always crash, if you
>> encounter this, please do send mail/file bugs/provide images.
>
> Well, I did (as well as other people did), in the past, and the bugs
> that were reported wree fixed (For example, I stumbled over the problem
> of the xfs_repair livelock with threads, I stumbled over the problem of
> it not being able to repair corruption a number of times despite saying
> everything is ok and so on).
>
> So "crash" was indeed badly worded - "does not fix things or does not run to
> completion" is more correct.
well, keep reporting them, and with metadumps when possible.
> The fact remains that of reiserfs, ext2/3/4 and jfs, xfs has by far the
> lowest quality fsck, at least for me - each time I have some problem with an
> xfs filesystem, xfs_repair fails to repair it.
I think that's unique to you ;) but it also depends on your definition
of "quality."
Of course, properly completing repair is a fair definition! Really, these
things need to be reported, triaged, and fixed. If the confusion over
metadump was the proper usage of "-o" then perhaps you will be able
to submit some of your unfixable corruptions.
-Eric
> It fortunately doesn't happen often, and is not necessarily a problem with
> xfs itself, but I am using reiserfs and ext2/3/4 and xfs all for a very
> long time, and of these, it's quite obvious that xfs_repair is much worse
> then the fsck tools of the others.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: corruption, xfs_repair 3.1.4 segfaults, xfs_repair 2.9.8 works
2011-03-04 11:14 ` Emmanuel Florac
2011-03-04 16:31 ` Marc Lehmann
@ 2011-03-04 17:30 ` Marc Lehmann
2011-03-04 18:17 ` Emmanuel Florac
1 sibling, 1 reply; 11+ messages in thread
From: Marc Lehmann @ 2011-03-04 17:30 UTC (permalink / raw)
To: xfs
On Fri, Mar 04, 2011 at 12:14:07PM +0100, Emmanuel Florac <eflorac@intellique.com> wrote:
> Lenny's xfs_repair (v 2.9.x IIRC). Just in case, it may do better.
It did, and with a lot fewer scary messages (no -P or -m was necessary):
http://ue.tst.eu/f3860347ab2147d87fdf8f961d6d4358.txt
afterwards, I had the contents of the single directory that caused issues
in lost+found, and no unreadable directories left.
So definitely a regression in 3.1.4.
Thanks a lot for your all your input - I will reformat the partition soon
and restore the files, assuming that the lenny xfs_repair destroyed any
evidence.
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / schmorp@schmorp.de
-=====/_/_//_/\_,_/ /_/\_\
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: corruption, xfs_repair 3.1.4 segfaults
2011-03-02 17:58 corruption, xfs_repair 3.1.4 segfaults Marc Lehmann
2011-03-02 21:43 ` Emmanuel Florac
@ 2011-03-04 15:07 ` Eric Sandeen
1 sibling, 0 replies; 11+ messages in thread
From: Eric Sandeen @ 2011-03-04 15:07 UTC (permalink / raw)
To: Marc Lehmann; +Cc: xfs
On 3/2/11 11:58 AM, Marc Lehmann wrote:
> Hi!
>
> I had a case of filesystem corruption a day ago:
>
...
> I tried to use xfs_repair on it, but it crashes (and, as I may grudgingly
> add, as usual it crashes because thats what xfsrepair does almost always).
If you provide an xfs_metadump image of the filesystem, I'd be
happy to look into the cause of the segfault.
In my experience xfs_repair does not almost always crash, if you
encounter this, please do send mail/file bugs/provide images.
> Any idea on where to go from here? I tried to build the git xfsprogs, but
> they don't build due to missing -fPIC - and as usual, thanks for any help :)
Bug reports on build problems are welcome as well.
Thanks,
-Eric
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2011-03-04 19:15 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-03-02 17:58 corruption, xfs_repair 3.1.4 segfaults Marc Lehmann
2011-03-02 21:43 ` Emmanuel Florac
2011-03-04 7:11 ` Marc Lehmann
2011-03-04 7:51 ` Emmanuel Florac
2011-03-04 10:29 ` Marc Lehmann
2011-03-04 11:14 ` Emmanuel Florac
2011-03-04 16:31 ` Marc Lehmann
2011-03-04 19:18 ` Eric Sandeen
2011-03-04 17:30 ` corruption, xfs_repair 3.1.4 segfaults, xfs_repair 2.9.8 works Marc Lehmann
2011-03-04 18:17 ` Emmanuel Florac
2011-03-04 15:07 ` corruption, xfs_repair 3.1.4 segfaults Eric Sandeen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox