public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: "Michael L. Semon" <mlsemon35@gmail.com>
To: benediktibk@aon.at
Cc: Benedikt Schmidt <benedikt.schmidt@tum.de>, xfs@oss.sgi.com
Subject: Re: xfs_repair force_geometry
Date: Mon, 13 May 2013 12:58:36 -0400	[thread overview]
Message-ID: <51911BBC.9080208@gmail.com> (raw)
In-Reply-To: <5190DB7F.2050505@tum.de>

Ordinary user comments follow...

On 05/13/2013 08:24 AM, Benedikt Schmidt wrote:
> Hi,
> currently I'm looking for the correct usage of the force_geometry option
> of xfs_repair. I wasn't able to find more documentation on this option
> beside that it exists. Could please somebody explain it to me?

According to the xfs_repair man page, it just means to skip the geometry 
test.  In other words, it's not a place to place CHS values or specify 
that your new drive has 4k sectors.  Usage is '-o force_geometry'.

> For a more detailed description of my problem: I've got here a hard disk
> which is dying at the moment, so I copied all the content with dd_rescue
> to a new and bigger one. To use xfs_copy wasn't possible as the
> filesystem was already corrupted. So now I've got nearly everything on
> the second hard disk (dd_rescue could'nt copy something around 6 or 7
> MB), but I can not mount the filesystem or even run xfs_repair on it, as
> it fails to find a superblock. I think the problem lies in the fact that
> the new disk has a different geometry than the previous one.
>
> Kind regards,
> Benedikt Schmidt

Did you ddrescue to a regular file or to a new partition?  In my case, 
ddrescue didn't let me do a simple `ddrescue /dev/sda8 /dev/sdb6`, so I 
passed on using ddrescue's suggested '--force' flag and instead did 
something like this:

root@plbearer:~# ddrescue /dev/sda8 /mnt/xfstests-test/fs_as_file

GNU ddrescue 1.16
Press Ctrl-C to interrupt
rescued:   671088 kB,  errsize:       0 B,  current rate:    9043 kB/s
    ipos:   671023 kB,   errors:       0,    average rate:   31956 kB/s
    opos:   671023 kB,     time since last successful read:       0 s
Finished

# -f means "check a regular file"
# -n means "do not modify filesystem"
root@plbearer:~# xfs_repair -f -n -o force_geometry 
/mnt/xfstests-test/fs_as_file
Phase 1 - find and verify superblock...
Phase 2 - using internal log
         - scan filesystem freespace and inode maps...
         - found root inode chunk
Phase 3 - for each AG...
         - scan (but don't 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
         - agno = 1
         - agno = 2
         - agno = 3
No modify flag set, skipping phase 5
Phase 6 - check inode connectivity...
         - traversing filesystem ...
         - traversal finished ...
         - moving disconnected inodes to lost+found ...
Phase 7 - verify link counts...
No modify flag set, skipping filesystem flush and exiting.

root@plbearer:~# mount -t xfs -o loop /mnt/xfstests-test/fs_as_file 
/mnt/loopback/

With the regular file mounted loopback, this is the part where I would 
somehow get the data to a freshly-made XFS filesystem somewhere else, 
then verify that the data that I need is indeed still intact and valid. 
  There are lots of tools to do such operations.  I lean on 
xfsdump/xfsrestore because I have longstanding good experience with the 
programs and see such situations as a really bad time to learn new tools.

If this is your last copy of important data, you should a) use the '-n' 
flag of xfs_repair before deciding to modify the ddrescued filesystem, 
and/or b) duplicate your recovered filesystem to another place so you 
have at least one good emergency backup.

Good luck, and be careful!

Michael

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2013-05-13 16:59 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-13 12:24 xfs_repair force_geometry Benedikt Schmidt
2013-05-13 16:58 ` Michael L. Semon [this message]
2013-05-13 17:56 ` Stan Hoeppner
2013-05-13 22:15 ` Eric Sandeen
2013-05-14  5:11   ` Benedikt Schmidt
2013-05-14  7:50     ` Michael L. Semon
2013-05-14  8:56       ` Benedikt Schmidt
2013-05-14 12:35         ` Stan Hoeppner
2013-05-14 17:54           ` Michael L. Semon

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=51911BBC.9080208@gmail.com \
    --to=mlsemon35@gmail.com \
    --cc=benedikt.schmidt@tum.de \
    --cc=benediktibk@aon.at \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox