From: Dave B <xfs_bugs@daxxi.net>
To: xfs@oss.sgi.com
Subject: Corrupt xfs on USB HDD : sub-optimal xfs_repair
Date: Mon, 02 Apr 2012 08:45:32 +0100 [thread overview]
Message-ID: <4F79591C.6090508@daxxi.net> (raw)
[-- 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
next reply other threads:[~2012-04-02 7:45 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-02 7:45 Dave B [this message]
2012-04-03 18:39 ` Corrupt xfs on USB HDD : sub-optimal xfs_repair Eric Sandeen
2012-04-04 16:14 ` Eric Sandeen
2012-04-04 18:57 ` Dave B
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=4F79591C.6090508@daxxi.net \
--to=xfs_bugs@daxxi.net \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.