64-bit inodes and back again

64-bit inodes and back again

[Michael Cronenworth]

Hello,

I enabled 64-bit inodes on a 2.6.35.14 kernel system. I ran into some 
software that did not handle this well, so I wanted to go back to 32-bit 
inodes. When I booted into the system again, any files that were created 
while in 64-bit inode mode are inaccessable and are shown to me like this:

$ ls -l /var/lib/mock/
ls: cannot access /var/lib/mock/dist-5E-build-373-1401: Invalid argument
??????????? ? ?    ?     ?            ? dist-5E-build-373-1401

I was led[1] to believe that this would not cause problems, but it has.

I have run xfs_repair on the file system but the old files still remain.

Are there any other things I can do to fix this? One thought is to 
remount with 64-bit inodes and erase or copy the offending files, but is 
that my only option?

[1] 
http://xfs.org/index.php/XFS_FAQ#Q:_Can_I_just_try_the_inode64_option_to_see_if_it_helps_me.3F

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

Re: 64-bit inodes and back again

[Dave Chinner]

On Tue, Sep 27, 2011 at 06:28:37PM -0500, Michael Cronenworth wrote:
> Hello,
> 
> I enabled 64-bit inodes on a 2.6.35.14 kernel system. I ran into
> some software that did not handle this well, so I wanted to go back
> to 32-bit inodes. When I booted into the system again, any files
> that were created while in 64-bit inode mode are inaccessable and
> are shown to me like this:
> 
> $ ls -l /var/lib/mock/
> ls: cannot access /var/lib/mock/dist-5E-build-373-1401: Invalid argument
> ??????????? ? ?    ?     ?            ? dist-5E-build-373-1401
> 
> I was led[1] to believe that this would not cause problems, but it has.

I'm pretty sure this was fixed in 2.6.37. There's nothing wrong with
the filesystem, just the kernel code had an arbitrary restriction on
where inodes code be read from in 32-bit inode mode. That was
removed in commit d276734 ("xfs: fix bogus m_maxagi check in
xfs_iget").

> I have run xfs_repair on the file system but the old files still remain.
> 
> Are there any other things I can do to fix this? One thought is to
> remount with 64-bit inodes and erase or copy the offending files,
> but is that my only option?

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

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

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

Re: 64-bit inodes and back again

[Michael Cronenworth]

On 09/27/2011 08:10 PM, Dave Chinner wrote:
> I'm pretty sure this was fixed in 2.6.37. There's nothing wrong with
> the filesystem, just the kernel code had an arbitrary restriction on
> where inodes code be read from in 32-bit inode mode. That was
> removed in commit d276734 ("xfs: fix bogus m_maxagi check in
> xfs_iget").

OK, great. I'll be moving the system to kernel 3.0 soon.

> 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.

Thanks for the pointers.

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

Re: 64-bit inodes and back again

[Michael Cronenworth]

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

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

Re: 64-bit inodes and back again

[Dave Chinner]

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

Re: 64-bit inodes and back again

[Michael Monnerie]

[-- Attachment #1.1: Type: Text/Plain, Size: 629 bytes --]

On Mittwoch, 28. September 2011 Michael Cronenworth wrote:
> 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.f
> c14-x86_64 
> 
> xfs_reno: Cannot stat 

I guess you'd need to mount with inode64 enabled so you can access the 
files, and after the tool finished to back to 32bit inodes.

-- 
mit freundlichen Grüssen,
Michael Monnerie, Ing. BSc

it-management Internet Services: Protéger
http://proteger.at [gesprochen: Prot-e-schee]
Tel: +43 660 / 415 6531

// Haus zu verkaufen: http://zmi.at/langegg/

[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

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

Re: 64-bit inodes and back again

[Michael Cronenworth]

On 09/28/2011 12:48 AM, Michael Monnerie wrote:
> I guess you'd need to mount with inode64 enabled so you can access the
> files, and after the tool finished to back to 32bit inodes.

No. The xfs_reno manpage specifically says to *not* mount with 64-bit 
inodes enabled. It uses the kernel to generate a new inode.

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

Re: 64-bit inodes and back again

[Michael Cronenworth]

On 09/28/2011 12:35 AM, Dave Chinner wrote:
> 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.

I tried that. It fails on the newer kernel, too. (32-bit inode mode)

# xfs_reno -vv /var/lib/mock.save
Scanning directory tree...
Processing 31 directories...
xfs_reno: directory: 4298768443 1 /var/lib/mock.save/dist-5E-build-377-1401
xfs_reno: unable to duplicate directory attributes: 
/var/lib/mock.save/dist-5E-build-377-1401
0 seconds elapsed
Done.
# ls -i
12884946465 dist-5E-build-373-1401   17200292312 dist-f15-build-383-1416
  8612299211 dist-5E-build-375-1401    8626045248 dist-f15-build-384-1416
  4298768443 dist-5E-build-377-1401   12884946478 dist-f15-build-385-1417
17196739302 dist-5E-build-378-1401   12885555358 dist-f15-build-386-1417
     3226235 dist-5E-build-379-1401    4298161997 dist-f15-build-387-1417
17197934889 dist-5E-build-380-1401   30082488692 dist-f15-build-388-1417
12917432680 dist-5E-build-381-1415   17196807090 dist-f15-build-389-1417
  4295007704 dist-6E-build-374-1403          1460 xfs_reno.recover
21502499833 dist-f15-build-382-1416

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

Re: 64-bit inodes and back again

[Dave Chinner]

On Wed, Sep 28, 2011 at 01:58:55AM -0500, Michael Cronenworth wrote:
> On 09/28/2011 12:35 AM, Dave Chinner wrote:
> >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.
> 
> I tried that. It fails on the newer kernel, too. (32-bit inode mode)
> 
> # xfs_reno -vv /var/lib/mock.save
> Scanning directory tree...
> Processing 31 directories...
> xfs_reno: directory: 4298768443 1 /var/lib/mock.save/dist-5E-build-377-1401
> xfs_reno: unable to duplicate directory attributes:
> /var/lib/mock.save/dist-5E-build-377-1401
> 0 seconds elapsed
> Done.
> # ls -i
> 12884946465 dist-5E-build-373-1401   17200292312 dist-f15-build-383-1416
>  8612299211 dist-5E-build-375-1401    8626045248 dist-f15-build-384-1416
>  4298768443 dist-5E-build-377-1401   12884946478 dist-f15-build-385-1417
> 17196739302 dist-5E-build-378-1401   12885555358 dist-f15-build-386-1417
>     3226235 dist-5E-build-379-1401    4298161997 dist-f15-build-387-1417
> 17197934889 dist-5E-build-380-1401   30082488692 dist-f15-build-388-1417
> 12917432680 dist-5E-build-381-1415   17196807090 dist-f15-build-389-1417
>  4295007704 dist-6E-build-374-1403          1460 xfs_reno.recover
> 21502499833 dist-f15-build-382-1416

It's failing trying to copy the attributes on a directory. What are
the attributes on the specific directory?

Cheers,

dave.
-- 
Dave Chinner
david@fromorbit.com

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

Re: 64-bit inodes and back again

[Michael Cronenworth]

Dave Chinner on 09/28/2011 06:07 AM wrote:
> It's failing trying to copy the attributes on a directory. What are
> the attributes on the specific directory?

That particular directory was

drwxrwsr-x  root:mock

However, I tried it on a number of other directories that had plain 
attributes like:

drwxr-xr-x  root:root

It failed the same way on those directories.

# ls -lid /usr/share/doc/xfsdump-3.0.4
4295007717 drwxr-xr-x. 2 root root 4096 Sep 28 02:58 
/usr/share/doc/xfsdump-3.0.4
# xfs_reno -vv /usr/share/doc/xfsdump-3.0.4
Scanning directory tree...
Processing 1 directory...
xfs_reno: directory: 4295007717 1 /usr/share/doc/xfsdump-3.0.4
xfs_reno: unable to duplicate directory attributes: 
/usr/share/doc/xfsdump-3.0.4
0 seconds elapsed
Done.
# ls -lid /usr/share/doc/xfsdump-3.0.4
4295007717 drwxr-xr-x. 2 root root 4096 Sep 28 09:12 
/usr/share/doc/xfsdump-3.0.4

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

Re: 64-bit inodes and back again

[Stan Hoeppner]

On 9/28/2011 8:13 AM, Michael Cronenworth wrote:
> Dave Chinner on 09/28/2011 06:07 AM wrote:
>> It's failing trying to copy the attributes on a directory. What are
>> the attributes on the specific directory?
>
> That particular directory was
>
> drwxrwsr-x root:mock
>
> However, I tried it on a number of other directories that had plain
> attributes like:
>
> drwxr-xr-x root:root
>
> It failed the same way on those directories.
>
> # ls -lid /usr/share/doc/xfsdump-3.0.4
> 4295007717 drwxr-xr-x. 2 root root 4096 Sep 28 02:58
> /usr/share/doc/xfsdump-3.0.4
> # xfs_reno -vv /usr/share/doc/xfsdump-3.0.4
> Scanning directory tree...
> Processing 1 directory...
> xfs_reno: directory: 4295007717 1 /usr/share/doc/xfsdump-3.0.4
> xfs_reno: unable to duplicate directory attributes:
> /usr/share/doc/xfsdump-3.0.4
> 0 seconds elapsed
> Done.
> # ls -lid /usr/share/doc/xfsdump-3.0.4
> 4295007717 drwxr-xr-x. 2 root root 4096 Sep 28 09:12
> /usr/share/doc/xfsdump-3.0.4

When you removed the inode64 mount option in fstab, did you change any 
other mount options on this filesystem?

-- 
Stan

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

Re: 64-bit inodes and back again

[Michael Cronenworth]

Stan Hoeppner wrote:
> When you removed the inode64 mount option in fstab, did you change any
> other mount options on this filesystem?

No. I do have quotas enabled, but they have been enabled all during this 
time from switching 64-bit inodes on and off.

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

Re: 64-bit inodes and back again

[Dave Chinner]

On Wed, Sep 28, 2011 at 08:13:37AM -0500, Michael Cronenworth wrote:
> Dave Chinner on 09/28/2011 06:07 AM wrote:
> >It's failing trying to copy the attributes on a directory. What are
> >the attributes on the specific directory?
> 
> That particular directory was
> 
> drwxrwsr-x  root:mock

I was asking about stuff like selinux attributes, not modes and
owners. i.e:

$ lsattr /usr/sbin/xfs_db
-------------e- /usr/sbin/xfs_db
$ attr -l /usr/sbin/xfs_db
Attribute "selinux" has a 27 byte value for /usr/sbin/xfs_db
$

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

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

Re: 64-bit inodes and back again

[Michael Cronenworth]

On 09/28/2011 07:25 PM, Dave Chinner wrote:
> I was asking about stuff like selinux attributes, not modes and
> owners. i.e:

SELinux is enabled and in Enforcing mode. It's the default Fedora policy.

$ lsattr /var/lib/mock.save/dist-5E-build-377-1401
--------------- /var/lib/mock.save/dist-5E-build-377-1401/root

$ attr -l /var/lib/mock.save/dist-5E-build-377-1401
Attribute "selinux" has a 40 byte value for 
/var/lib/mock.save/dist-5E-build-377-1401

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