From: Dave Chinner <david@fromorbit.com>
To: Michael Cronenworth <mike@cchtml.com>
Cc: xfs@oss.sgi.com
Subject: Re: 64-bit inodes and back again
Date: Wed, 28 Sep 2011 15:35:39 +1000 [thread overview]
Message-ID: <20110928053539.GF3159@dastard> (raw)
In-Reply-To: <4E828BE1.8030003@cchtml.com>
On Tue, Sep 27, 2011 at 09:52:17PM -0500, Michael Cronenworth wrote:
> Dave Chinner on 09/27/2011 08:10 PM wrote:
> > I'm pretty sure this was fixed in 2.6.37.
>
> I upgraded to kernel 2.6.38. The files are now visible.
>
> Michael Cronenworth wrote:
> >>xfs_reno is a tool designed to move all 64 bit inodes back into the
> >>32 bit inode space again.
> >>
> >>http://xfs.org/index.php/Unfinished_work#The_xfs_reno_tool
> >
> >I'll give this a shot first.
>
> I did try this tool first, but it didn't seem to work for me:
>
> # xfs_reno -vv /tmp/q.save/7074d797d8cd5965224f21a778924aa44a0871f4-qt-x11-4.7.4-2.fc14-x86_64
>
> xfs_reno: Cannot stat /tmp/q.save/7074d797d8cd5965224f21a778924aa44a0871f4-qt-x11-4.7.4-2.fc14-x86_64:
> Invalid argument
> # xfs_reno -fvv /tmp/q.save
> Scanning directory tree...
> Processing 1 directory...
> xfs_reno: directory: 97367 1 /tmp/q.save
> xfs_reno: unable to duplicate directory attributes: /tmp/q.save
> 0 seconds elapsed
> Done.
> # ls -l /tmp/q.save/
> ls: cannot access /tmp/q.save/b0afb399c40e9a45061b5cee73770def741d270e-qt-4.7.4-2.fc14-x86_64:
> Invalid argument
> ls: cannot access /tmp/q.save/7074d797d8cd5965224f21a778924aa44a0871f4-qt-x11-4.7.4-2.fc14-x86_64:
> Invalid argument
> total 8
> drwxr-xr-x. 2 root root 4096 Sep 27 22:33 310514e5d8aff198342a469b59311b7fa3af0d28-qt-webkit-4.7.4-2.fc14-x86_64
> ??????????? ? ? ? ? ?
> 7074d797d8cd5965224f21a778924aa44a0871f4-qt-x11-4.7.4-2.fc14-x86_64
> ??????????? ? ? ? ? ?
> b0afb399c40e9a45061b5cee73770def741d270e-qt-4.7.4-2.fc14-x86_64
> -rw-------. 1 root root 83 Sep 27 22:38 xfs_reno.recover
It has to be able to access the files with inode numbers > 32 bit,
so you need to run it on the 2.6.38 kernel. Once you've done that,
you should be able to read all the files back on the .35 kernel,
too.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2011-09-28 5:35 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-27 23:28 64-bit inodes and back again Michael Cronenworth
2011-09-28 1:10 ` Dave Chinner
2011-09-28 1:31 ` Michael Cronenworth
2011-09-28 2:52 ` Michael Cronenworth
2011-09-28 5:35 ` Dave Chinner [this message]
2011-09-28 6:58 ` Michael Cronenworth
2011-09-28 11:07 ` Dave Chinner
2011-09-28 13:13 ` Michael Cronenworth
2011-09-28 17:37 ` Stan Hoeppner
2011-09-28 18:05 ` Michael Cronenworth
2011-09-29 0:25 ` Dave Chinner
2011-09-29 0:37 ` Michael Cronenworth
2011-09-28 5:48 ` Michael Monnerie
2011-09-28 6:55 ` Michael Cronenworth
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=20110928053539.GF3159@dastard \
--to=david@fromorbit.com \
--cc=mike@cchtml.com \
--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.