* Corrupt xfs on USB HDD : sub-optimal xfs_repair
@ 2012-04-02 7:45 Dave B
2012-04-03 18:39 ` Eric Sandeen
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: Dave B @ 2012-04-02 7:45 UTC (permalink / raw)
To: xfs
[-- Attachment #1.1: Type: text/plain, Size: 2461 bytes --]
Hi,
The two files in the root directory of a 500GB external USB HDD became
corrupt,
probably due to a power failure.
dave@K-Matrix $ ls -l /media/Galaxy/
ls: cannot access /media/Galaxy/ChnSchld_pre_4-14.tgz: No such file or
directory
ls: cannot access /media/Galaxy/dhr820xu.ext: No such file or directory
total 24
?????????? ? ? ? ? ? ChnSchld_pre_4-14.tgz
?????????? ? ? ? ? ? dhr820xu.ext
drwxr-xr-x 7 dave dave 4096 2012-02-13 12:45 DHR recordings
drwxr-xr-x 212 dave dave 12288 2008-11-30 00:21 Miles Davis
drwxr-xr-x 5 dave dave 4096 2012-02-16 06:06 PartImage
xfs_repair didn't help much; it just removed the two filenames.
At minimum, I expected two entries in L+F but the L+F directory was not
created.
dave@K-Matrix $ sudo xfs_repair /dev/sdc1
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
- 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
entry "ChnSchld_pre_4-14.tgz" in shortform directory 128 references free
inode 48145461
junking entry "ChnSchld_pre_4-14.tgz" in directory inode 128
entry "dhr820xu.ext" in shortform directory 128 references free inode
48145451
junking entry "dhr820xu.ext" in directory inode 128
- agno = 1
- agno = 2
- agno = 3
Phase 5 - rebuild AG headers and trees...
- reset superblock...
Phase 6 - check inode connectivity...
- resetting contents of realtime bitmap and summary inodes
- traversing filesystem ...
- traversal finished ...
- moving disconnected inodes to lost+found ...
Phase 7 - verify and correct link counts...
done
See longer console session and before/after metadumps in ~7MB d/l at:
http://daxxi.net/xfs/Galaxy_500GB_xfs.tar.gz
user: xfs , p/w: xfs
(please only d/l if 2x240MB metadumps will be meaningful to you)
Environment:
Linux K-Matrix 3.0.0-16-generic #29-Ubuntu SMP Tue Feb 14 12:49:42 UTC
2012 i686 athlon i386 GNU/Linux
Dave
[-- Attachment #1.2: Type: text/html, Size: 3477 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] 4+ messages in thread* Re: Corrupt xfs on USB HDD : sub-optimal xfs_repair
2012-04-02 7:45 Corrupt xfs on USB HDD : sub-optimal xfs_repair Dave B
@ 2012-04-03 18:39 ` Eric Sandeen
2012-04-04 16:14 ` Eric Sandeen
2012-04-04 18:57 ` Dave B
2 siblings, 0 replies; 4+ messages in thread
From: Eric Sandeen @ 2012-04-03 18:39 UTC (permalink / raw)
To: xfs; +Cc: Dave B
On 4/2/12 12:45 AM, Dave B wrote:
>
> Hi,
>
> The two files in the root directory of a 500GB external USB HDD became corrupt,
> probably due to a power failure.
>
> dave@K-Matrix $ ls -l /media/Galaxy/
> ls: cannot access /media/Galaxy/ChnSchld_pre_4-14.tgz: No such file or directory
> ls: cannot access /media/Galaxy/dhr820xu.ext: No such file or directory
> total 24
> ?????????? ? ? ? ? ? ChnSchld_pre_4-14.tgz
> ?????????? ? ? ? ? ? dhr820xu.ext
> drwxr-xr-x 7 dave dave 4096 2012-02-13 12:45 DHR recordings
> drwxr-xr-x 212 dave dave 12288 2008-11-30 00:21 Miles Davis
> drwxr-xr-x 5 dave dave 4096 2012-02-16 06:06 PartImage
>
>
> xfs_repair didn't help much; it just removed the two filenames.
> At minimum, I expected two entries in L+F but the L+F directory was not created.
>
> dave@K-Matrix $ sudo xfs_repair /dev/sdc1
> 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
> - 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
> entry "ChnSchld_pre_4-14.tgz" in shortform directory 128 references free inode 48145461
> junking entry "ChnSchld_pre_4-14.tgz" in directory inode 128
> entry "dhr820xu.ext" in shortform directory 128 references free inode 48145451
> junking entry "dhr820xu.ext" in directory inode 128
> - agno = 1
> - agno = 2
> - agno = 3
> Phase 5 - rebuild AG headers and trees...
> - reset superblock...
> Phase 6 - check inode connectivity...
> - resetting contents of realtime bitmap and summary inodes
> - traversing filesystem ...
> - traversal finished ...
> - moving disconnected inodes to lost+found ...
> Phase 7 - verify and correct link counts...
> done
>
>
> See longer console session and before/after metadumps in ~7MB d/l at:
> http://daxxi.net/xfs/Galaxy_500GB_xfs.tar.gz
> user: xfs , p/w: xfs
> (please only d/l if 2x240MB metadumps will be meaningful to you)
>
>
> Environment:
> Linux K-Matrix 3.0.0-16-generic #29-Ubuntu SMP Tue Feb 14 12:49:42 UTC 2012 i686 athlon i386 GNU/Linux
Thanks, I'll take a look at this, grabbing the images now.
-Eric
>
> Dave
>
>
>
> _______________________________________________
> 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] 4+ messages in thread
* Re: Corrupt xfs on USB HDD : sub-optimal xfs_repair
2012-04-02 7:45 Corrupt xfs on USB HDD : sub-optimal xfs_repair Dave B
2012-04-03 18:39 ` Eric Sandeen
@ 2012-04-04 16:14 ` Eric Sandeen
2012-04-04 18:57 ` Dave B
2 siblings, 0 replies; 4+ messages in thread
From: Eric Sandeen @ 2012-04-04 16:14 UTC (permalink / raw)
To: xfs; +Cc: Dave B
On 4/2/12 12:45 AM, Dave B wrote:
>
> Hi,
>
> The two files in the root directory of a 500GB external USB HDD became corrupt,
> probably due to a power failure.
>
> dave@K-Matrix $ ls -l /media/Galaxy/
> ls: cannot access /media/Galaxy/ChnSchld_pre_4-14.tgz: No such file or directory
> ls: cannot access /media/Galaxy/dhr820xu.ext: No such file or directory
> total 24
> ?????????? ? ? ? ? ? ChnSchld_pre_4-14.tgz
> ?????????? ? ? ? ? ? dhr820xu.ext
> drwxr-xr-x 7 dave dave 4096 2012-02-13 12:45 DHR recordings
> drwxr-xr-x 212 dave dave 12288 2008-11-30 00:21 Miles Davis
> drwxr-xr-x 5 dave dave 4096 2012-02-16 06:06 PartImage
>
>
> xfs_repair didn't help much; it just removed the two filenames.
> At minimum, I expected two entries in L+F but the L+F directory was not created.
>
> dave@K-Matrix $ sudo xfs_repair /dev/sdc1
> 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
> - 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
> entry "ChnSchld_pre_4-14.tgz" in shortform directory 128 references free inode 48145461
> junking entry "ChnSchld_pre_4-14.tgz" in directory inode 128
> entry "dhr820xu.ext" in shortform directory 128 references free inode 48145451
> junking entry "dhr820xu.ext" in directory inode 128
So, I am not sure there was really much to do here. It's not that the inode was
legit but not linked from anywhere (in which case it would have gone into l+f) -
the inodes seem to be newly initialized, such as this one is:
xfs_db> inode 48145452
xfs_db> p
core.magic = 0x494e
core.mode = 0
core.version = 2
core.format = 0 (dev)
core.nlinkv2 = 0
core.onlink = 0
core.projid = 0
core.uid = 0
core.gid = 0
core.flushiter = 0
core.atime.sec = Wed Dec 31 18:00:00 1969
core.atime.nsec = 000000000
core.mtime.sec = Wed Dec 31 18:00:00 1969
core.mtime.nsec = 000000000
core.ctime.sec = Wed Dec 31 18:00:00 1969
core.ctime.nsec = 000000000
core.size = 0
core.nblocks = 0
core.extsize = 0
core.nextents = 0
core.naextents = 0
core.forkoff = 0
core.aformat = 0 (dev)
core.dmevmask = 0
core.dmstate = 0
core.newrtbm = 0
core.prealloc = 0
core.realtime = 0
core.immutable = 0
core.append = 0
core.sync = 0
core.noatime = 0
core.nodump = 0
core.rtinherit = 0
core.projinherit = 0
core.nosymlinks = 0
core.extsz = 0
core.extszinherit = 0
core.nodefrag = 0
core.filestream = 0
core.gen = 2846323697
next_unlinked = null
u.dev = 0
Putting that inode into l+f would not have done you any good.
All the inodes in this cluster have a generation number of 2846323697, which
is due to new inode clusters being initialized with a random generation nr;
it looks for all the world like these inodes are uninitialized.
It might be possible that it's the directory which is corrupt, and therefore
points to wrong inodes... but that doesn't look like the case either,
the rest of the metadata in the dir looks just fine, and a previous version of
the dir entry contains the same inode number:
b0: 5f 34 2d 31 34 2e 74 67 7a 02 de a4 35 0c 02 30 .4.14.tgz...5..0
c0: 64 68 72 38 32 30 78 75 2e 65 78 74 02 de a4 2b dhr820xu.ext....
d0: 74 02 de a4 2a 0c 02 30 64 68 72 38 32 30 78 75 t......0dhr820xu
e0: 2e 65 78 74 02 de a4 2b 00 00 00 00 00 00 00 00 .ext............
(02DEA42B, the inode nr in question, is in there both times)
I'm really not sure what has gone wrong here, yet.
Dave (Chinner), to be honest I have forgotten what your hunch was, do you
see any hints here?
thanks,
-Eric
> - agno = 1
> - agno = 2
> - agno = 3
> Phase 5 - rebuild AG headers and trees...
> - r eset superblock...
> Phase 6 - check inode connectivity...
> - resetting contents of realtime bitmap and summary inodes
> - traversing filesystem ...
> - traversal finished ...
> - moving disconnected inodes to lost+found ...
> Phase 7 - verify and correct link counts...
> done
>
>
> See longer console session and before/after metadumps in ~7MB d/l at:
> http://daxxi.net/xfs/Galaxy_500GB_xfs.tar.gz
> user: xfs , p/w: xfs
> (please only d/l if 2x240MB metadumps will be meaningful to you)
>
>
> Environment:
> Linux K-Matrix 3.0.0-16-generic #29-Ubuntu SMP Tue Feb 14 12:49:42 UTC 2012 i686 athlon i386 GNU/Linux
>
>
> Dave
>
>
>
> _______________________________________________
> 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] 4+ messages in thread
* Re: Corrupt xfs on USB HDD : sub-optimal xfs_repair
2012-04-02 7:45 Corrupt xfs on USB HDD : sub-optimal xfs_repair Dave B
2012-04-03 18:39 ` Eric Sandeen
2012-04-04 16:14 ` Eric Sandeen
@ 2012-04-04 18:57 ` Dave B
2 siblings, 0 replies; 4+ messages in thread
From: Dave B @ 2012-04-04 18:57 UTC (permalink / raw)
To: xfs
On 02/04/12 08:45, I wrote:
>
>
> Environment:
> Linux K-Matrix 3.0.0-16-generic #29-Ubuntu SMP Tue Feb 14 12:49:42 UTC
> 2012 i686 athlon i386 GNU/Linux
>
>
I should update this ...
Environment:
Linux K-Matrix 3.0.0-16-generic #29-Ubuntu SMP Tue Feb 14 12:49:42 UTC
2012 i686 athlon i386 GNU/Linux
- AND -
Linux (none) 2.6.18-7.1 #2 SMP Wed Feb 22 04:54:47 KST 2012 7405d0-smp
unknown
http://www.dstreamtech.com/english/product/product_detail.asp?idx=37
Dave
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2012-04-04 18:57 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-04-02 7:45 Corrupt xfs on USB HDD : sub-optimal xfs_repair Dave B
2012-04-03 18:39 ` Eric Sandeen
2012-04-04 16:14 ` Eric Sandeen
2012-04-04 18:57 ` Dave B
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox