* Corrupted filesystem: thoughts?
@ 2014-10-07 7:35 Emmanuel Florac
2014-10-07 7:59 ` Emmanuel Florac
2014-10-07 10:56 ` Dave Chinner
0 siblings, 2 replies; 6+ messages in thread
From: Emmanuel Florac @ 2014-10-07 7:35 UTC (permalink / raw)
To: xfs
Here we go again: Adaptec RAID adapters don't play well with HGST 3TB
drives for some reason. When a drive fails, the filesystem is almost
always corrupted. This one looks pretty bad according to the output of
the latest "xfs_repair -n" of the 15 TB filesystem. Here is a sample
of the 2MB log:
Phase 1 - find and verify superblock...
- reporting progress in intervals of 15 minutes
Phase 2 - using internal log
- scan filesystem freespace and inode maps...
out-of-order bno btree record 83 (332943 42) block 27/4681
out-of-order bno btree record 90 (322762 76) block 27/4681
out-of-order bno btree record 91 (331903 125) block 27/4681
out-of-order bno btree record 92 (334898 70) block 27/4681
out-of-order bno btree record 93 (335608 54) block 27/4681
out-of-order bno btree record 94 (335614 24) block 27/4681
out-of-order bno btree record 97 (338496 41) block 27/4681
out-of-order bno btree record 99 (339013 43) block 27/4681
out-of-order bno btree record 100 (339275 96) block 27/4681
out-of-order bno btree record 101 (339932 51) block 27/4681
out-of-order bno btree record 102 (339636 91) block 27/4681
out-of-order bno btree record 103 (338350 19) block 27/4681
out-of-order bno btree record 104 (339613 74) block 27/4681
block (27,339636-339636) multiply claimed by bno space tree, state - 1
out-of-order bno btree record 105 (339958 23) block 27/4681
out-of-order bno btree record 106 (340787 57) block 27/4681
out-of-order bno btree record 107 (340200 33) block 27/4681
out-of-order bno btree record 108 (340800 5) block 27/4681
invalid length 0 in record 109 of bno btree block 27/4681
out-of-order bno btree record 110 (340786 1) block 27/4681
out-of-order bno btree record 113 (345999 108) block 27/4681
out-of-order bno btree record 118 (347908 84) block 27/4681
block (27,347974-347974) multiply claimed by bno space tree, state - 1
<snip : it goes on and on>
block (27,154684-154684) multiply claimed by cnt space tree, state - 2
block (27,154824-154824) multiply claimed by cnt space tree, state - 2
block (27,164229-164229) multiply claimed by cnt space tree, state - 2
block (27,173600-173600) multiply claimed by cnt space tree, state - 2
block (27,169939-169939) multiply claimed by cnt space tree, state - 2
block (27,176207-176207) multiply claimed by cnt space tree, state - 2
block (27,9208427-9208427) multiply claimed by cnt space tree, state - 2
out-of-order cnt btree record 84 (100281231 51) block 27/201066
block (27,426944-426944) multiply claimed by cnt space tree, state - 2
block (27,605574-605574) multiply claimed by cnt space tree, state - 2
block (27,696437-696437) multiply claimed by cnt space tree, state - 2
block (27,696442-696442) multiply claimed by cnt space tree, state - 2
block (27,696452-696452) multiply claimed by cnt space tree, state - 2
<snip : it goes on and on>
data fork in ino 150375755252 claims free block 9398476839
data fork in ino 150375767332 claims free block 9398512515
data fork in ino 150375767340 claims free block 9398456218
data fork in ino 150375767362 claims free block 9401286695
data fork in ino 150375845358 claims free block 9407567857
data fork in ino 150375845377 claims free block 9398435669
data fork in ino 150376025165 claims free block 9404202405
data fork in ino 150376040962 claims free block 9401232272
data fork in ino 150376303186 claims free block 9398404549
data fork in ino 150376303188 claims free block 9398389564
data fork in ino 150376303189 claims free block 9398381926
data fork in ino 150376303194 claims free block 9398715665
data fork in ino 150376812226 claims free block 9398750726
data fork in ino 150376812272 claims free block 9398292419
data fork in ino 150376886626 claims free block 9401406274
data fork in ino 150376886648 claims free block 9401395026
data fork in ino 150377104159 claims free block 9401459056
data fork in ino 150377104269 claims free block 9401566594
data fork in ino 150377104269 claims free block 9401568444
data fork in ino 150377104296 claims free block 9401586022
<snip : it goes on and on>
- 09:14:00: process known inodes and inode discovery - 6496192 of 12523904 inodes done
- process newly discovered inodes...
- 09:14:00: process newly discovered inodes - 72 of 36 allocation groups done
Phase 4 - check for duplicate blocks...
- setting up duplicate extent list...
- 09:14:01: setting up duplicate extent list - 36 of 36 allocation groups done
- check for inodes claiming duplicate blocks...
- agno = 0
- agno = 1
- agno = 2
- agno = 4
- agno = 7
- agno = 6
- agno = 3
- agno = 5
entry "Final" in shortform directory 12884902016 references non-existent inode 115964649847
would have junked entry "Final" in directory inode 12884902016
would have corrected i8 count in directory 12884902016 from 8 to 7
entry "3D" in shortform directory 12884902017 references non-existent inode 115964347194
would have junked entry "3D" in directory inode 12884902017
would have corrected i8 count in directory 12884902017 from 5 to 4
entry "Passes" in shortform directory 21474836610 references non-existent inode 115964347193
would have junked entry "Passes" in directory inode 21474836610
would have corrected i8 count in directory 21474836610 from 5 to 4
entry "Wood_Box" at block 0 offset 48 in directory inode 8589952196 references non-existent inode 115964347511
would clear inode number in entry at offset 48...
entry "Joke_Box" at block 0 offset 184 in directory inode 8589952196 references non-existent inode 115964347512
would clear inode number in entry at offset 184...
<snip : it goes on and on>
would clear inode number in entry at offset 3224...
entry "GRFGN_SQ024_SC0046A_Depth.0274.zt" at block 2 offset 256 in directory inode 115969713211 references non-existent inode 115969746775
would clear inode number in entry at offset 256...
entry "roll_262" at block 1 offset 16 in directory inode 124557330219 references non-existent inode 115970916485
would clear inode number in entry at offset 16...
entry "GRFGN_SQ024_SC0046A_Depth.0275.zt" at block 2 offset 304 in directory inode 115969713211 references non-existent inode 115969746776
would clear inode number in entry at offset 304...
entry "roll_332" at block 1 offset 880 in directory inode 124557330219 references non-existent inode 115970916486
would clear inode number in entry at offset 880...
entry "GRFGN_SQ024_SC0046A_Depth.0276.zt" at block 2 offset 352 in directory inode 115969713211 references non-existent inode 115969746777
would clear inode number in entry at offset 352...
entry "roll_368" at block 1 offset 1744 in directory inode 124557330219 references non-existent inode 115970916487
would clear inode number in entry at offset 1744...
<snip : it goes on and on>
entry "3D" in shortform directory 151166290308 references non-existent inode 120262842426
would have junked entry "3D" in directory inode 151166290308
would have corrected i8 count in directory 151166290308 from 5 to 4
entry "3D" in shortform directory 151166290322 references non-existent inode 120262535040
would have junked entry "3D" in directory inode 151166290322
would have corrected i8 count in directory 151166290322 from 5 to 4
entry ".." at block 0 offset 32 in directory inode 151219024506 references non-existent inode 120262254536
would clear inode number in entry at offset 32...
- 09:14:02: check for inodes claiming duplicate blocks - 6496192 of 12523904 inodes done
Inode allocation btrees are too corrupted, skipping phases 6 and 7
No modify flag set, skipping filesystem flush and exiting.
xfs_info /dev/vg0/raid
meta-data=/dev/mapper/vg0-raid isize=256 agcount=36, agsize=268435455 blks
= sectsz=512 attr=2
data = bsize=4096 blocks=9505273856, imaxpct=5
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0
log =internal bsize=4096 blocks=521728, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
Kernel is a plain vanilla 3.2.54 amd64. As a precaution I've made a list of the
whole filesystem with inode numbers to be able to rename lost files in
norecovery mode... Unfortunately I cannot do a metadump because of lack of room
elsewhere.
--
------------------------------------------------------------------------
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] 6+ messages in thread* Re: Corrupted filesystem: thoughts?
2014-10-07 7:35 Corrupted filesystem: thoughts? Emmanuel Florac
@ 2014-10-07 7:59 ` Emmanuel Florac
2014-10-07 10:59 ` Dave Chinner
2014-10-07 10:56 ` Dave Chinner
1 sibling, 1 reply; 6+ messages in thread
From: Emmanuel Florac @ 2014-10-07 7:59 UTC (permalink / raw)
To: xfs
Le Tue, 7 Oct 2014 09:35:33 +0200 vous écriviez:
> Kernel is a plain vanilla 3.2.54 amd64. As a precaution I've made a
> list of the whole filesystem with inode numbers to be able to rename
> lost files in norecovery mode... Unfortunately I cannot do a metadump
> because of lack of room elsewhere.
At end of repair I've got loads of these:
libxfs_writebufr: write verifer failed on bno 0x10000f348/0x1000
Metadata corruption detected at block 0x802b2a88/0x1000
libxfs_writebufr: write verifer failed on bno 0x802b2a88/0x1000
Metadata corruption detected at block 0x800e4420/0x1000
libxfs_writebufr: write verifer failed on bno 0x800e4420/0x1000
Metadata corruption detected at block 0x9075d8/0x1000
libxfs_writebufr: write verifer failed on bno 0x9075d8/0x1000
Metadata corruption detected at block 0x143390/0x1000
libxfs_writebufr: write verifer failed on bno 0x143390/0x1000
Metadata corruption detected at block 0x142160/0x1000
libxfs_writebufr: write verifer failed on bno 0x142160/0x1000
Metadata corruption detected at block 0x197400/0x1000
libxfs_writebufr: write verifer failed on bno 0x197400/0x1000
Metadata corruption detected at block 0x10fee0/0x1000
libxfs_writebufr: write verifer failed on bno 0x10fee0/0x1000
Metadata corruption detected at block 0x145d00/0x1000
libxfs_writebufr: write verifer failed on bno 0x145d00/0x1000
Metadata corruption detected at block 0x18e658/0x1000
libxfs_writebufr: write verifer failed on bno 0x18e658/0x1000
Metadata corruption detected at block 0x192d98/0x1000
libxfs_writebufr: write verifer failed on bno 0x192d98/0x1000
Metadata corruption detected at block 0x116668/0x1000
libxfs_writebufr: write verifer failed on bno 0x116668/0x1000
Metadata corruption detected at block 0xf9428/0x1000
libxfs_writebufr: write verifer failed on bno 0xf9428/0x1000
Metadata corruption detected at block 0x42698/0x1000
libxfs_writebufr: write verifer failed on bno 0x42698/0x1000
Metadata corruption detected at block 0x44db8/0x1000
libxfs_writebufr: write verifer failed on bno 0x44db8/0x1000
and 10538 files in lost+found...
--
------------------------------------------------------------------------
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] 6+ messages in thread* Re: Corrupted filesystem: thoughts?
2014-10-07 7:59 ` Emmanuel Florac
@ 2014-10-07 10:59 ` Dave Chinner
0 siblings, 0 replies; 6+ messages in thread
From: Dave Chinner @ 2014-10-07 10:59 UTC (permalink / raw)
To: Emmanuel Florac; +Cc: xfs
On Tue, Oct 07, 2014 at 09:59:49AM +0200, Emmanuel Florac wrote:
> Le Tue, 7 Oct 2014 09:35:33 +0200 vous écriviez:
>
> > Kernel is a plain vanilla 3.2.54 amd64. As a precaution I've made a
> > list of the whole filesystem with inode numbers to be able to rename
> > lost files in norecovery mode... Unfortunately I cannot do a metadump
> > because of lack of room elsewhere.
>
> At end of repair I've got loads of these:
>
> libxfs_writebufr: write verifer failed on bno 0x10000f348/0x1000
> Metadata corruption detected at block 0x802b2a88/0x1000
Upgrade to 3.2.1 as there were a bunch of fixes for issues that
caused these messages in that release.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Corrupted filesystem: thoughts?
2014-10-07 7:35 Corrupted filesystem: thoughts? Emmanuel Florac
2014-10-07 7:59 ` Emmanuel Florac
@ 2014-10-07 10:56 ` Dave Chinner
2014-10-07 11:22 ` Emmanuel Florac
1 sibling, 1 reply; 6+ messages in thread
From: Dave Chinner @ 2014-10-07 10:56 UTC (permalink / raw)
To: Emmanuel Florac; +Cc: xfs
On Tue, Oct 07, 2014 at 09:35:33AM +0200, Emmanuel Florac wrote:
>
> Here we go again: Adaptec RAID adapters don't play well with HGST 3TB
> drives for some reason. When a drive fails, the filesystem is almost
> always corrupted. This one looks pretty bad according to the output of
> the latest "xfs_repair -n" of the 15 TB filesystem. Here is a sample
> of the 2MB log:
Is the log clean? (use xfs_logprint -t <dev> to determine that)
xfs_repair -n ignores dirty logs, so the state on disk it may be
reporting on can be inconsistent and that inconsistency is "fixed"
by running log recovery.
> Phase 1 - find and verify superblock...
> - reporting progress in intervals of 15 minutes
> Phase 2 - using internal log
> - scan filesystem freespace and inode maps...
> out-of-order bno btree record 83 (332943 42) block 27/4681
> out-of-order bno btree record 90 (322762 76) block 27/4681
> out-of-order bno btree record 91 (331903 125) block 27/4681
That implies that some updates to the btree block haven't occurred
that compact out the old entries (that are now out of order). That
can either occur due to writes going missing, or log recovery not
being run....
Most of the issues could be caused by having a dirty log that needs
recovery, so that is the first thing to check. Note that a
non-dry-run xfs_repair will warn and abort if the log is dirty,
unlike "xfs_repair -n".
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Corrupted filesystem: thoughts?
2014-10-07 10:56 ` Dave Chinner
@ 2014-10-07 11:22 ` Emmanuel Florac
2014-10-07 19:53 ` Dave Chinner
0 siblings, 1 reply; 6+ messages in thread
From: Emmanuel Florac @ 2014-10-07 11:22 UTC (permalink / raw)
To: Dave Chinner; +Cc: xfs
Le Tue, 7 Oct 2014 21:56:57 +1100
Dave Chinner <david@fromorbit.com> écrivait:
> Is the log clean? (use xfs_logprint -t <dev> to determine that)
>
No, it wasn't, that was probably the source of most of the ominous
messages. The many files in lost+found were probably deleted files
In case this may help someone, before running xfs_repair I've mounted
the volume in "ro,nonrecovery" mode, then ran this command to make a
listing of files with their inodes:
find /mnt/raid/ -print0 | xargs --null ls -di | gzip - > FILELIST.gz
Now I can reconnect manually most of the files in lost+found by
searching for them in FILELIST.
--
------------------------------------------------------------------------
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] 6+ messages in thread* Re: Corrupted filesystem: thoughts?
2014-10-07 11:22 ` Emmanuel Florac
@ 2014-10-07 19:53 ` Dave Chinner
0 siblings, 0 replies; 6+ messages in thread
From: Dave Chinner @ 2014-10-07 19:53 UTC (permalink / raw)
To: Emmanuel Florac; +Cc: xfs
On Tue, Oct 07, 2014 at 01:22:10PM +0200, Emmanuel Florac wrote:
> Le Tue, 7 Oct 2014 21:56:57 +1100
> Dave Chinner <david@fromorbit.com> écrivait:
>
> > Is the log clean? (use xfs_logprint -t <dev> to determine that)
> >
>
> No, it wasn't, that was probably the source of most of the ominous
> messages. The many files in lost+found were probably deleted files
You really, really want to recover the log before running repair if
possible.
> In case this may help someone, before running xfs_repair I've mounted
> the volume in "ro,nonrecovery" mode, then ran this command to make a
> listing of files with their inodes:
>
> find /mnt/raid/ -print0 | xargs --null ls -di | gzip - > FILELIST.gz
Generating the list before recovery is run will result in a
partial list because there will be parts of the directory heirarchy
that can't be traversed due to corruption. So there's no guarantee
that this list will be in any way complete.
Besides, we already have amore robust offline tool for generating
such a list:
$ man xfs_ncheck
....
xfs_ncheck with no -i arguments generates an inode number and
pathname list of all files on the given filesystem.
...
It will also tell you when it fails to resolve a pathname or inode
number due to corruption, so you have direct indication of what
inodes and/or paths are broken.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-10-07 19:53 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-10-07 7:35 Corrupted filesystem: thoughts? Emmanuel Florac
2014-10-07 7:59 ` Emmanuel Florac
2014-10-07 10:59 ` Dave Chinner
2014-10-07 10:56 ` Dave Chinner
2014-10-07 11:22 ` Emmanuel Florac
2014-10-07 19:53 ` Dave Chinner
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox