64-bit inodes and back again
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
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 8 lines · 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:
Quoted 5 lines
$ ls -l /var/lib/mock/ ls: cannot access /var/lib/mock/dist-5E-build-373-1401: Invalid argument ??????????? ? ? ? ? ? dist-5E-build-373-1401I 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").
Quoted 5 lines
I have run
xfs_repairon 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.
Signature · 7 lines
Dave Chinner [email protected] _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Quoted 5 lines · Dave Chinner
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_maxagicheck inxfs_iget").
OK, great. I'll be moving the system to kernel 3.0 soon.
Quoted 4 lines
xfs_renois a tool designed to move all 64 bit inodes back into the 32 bit inode space again.
I'll give this a shot first.
Thanks for the pointers.
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 1 line · 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.
Quoted 6 lines · Michael Cronenworth
Quoted 4 lines
xfs_renois a tool designed to move all 64 bit inodes back into the 32 bit inode space again.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
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 30 lines · Michael Cronenworth
Quoted 1 line · 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.
Quoted 6 lines · Michael Cronenworth
Quoted 4 lines
xfs_renois a tool designed to move all 64 bit inodes back into the 32 bit inode space again.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:
Quoted 8 lines
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.
Signature · 7 lines
Dave Chinner [email protected] _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Quoted 4 lines · Dave Chinner
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
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 18 lines · Michael Cronenworth
Quoted 4 lines · Dave Chinner
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
Quoted 8 lines
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-1416It's failing trying to copy the attributes on a directory. What are the attributes on the specific directory?
Cheers,
dave.
Signature · 7 lines
Dave Chinner [email protected] _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Quoted 2 lines · 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
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 15 lines · Michael Cronenworth
Quoted 2 lines · 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.
Quoted 14 lines
# 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?
Signature · 6 lines
Stan _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Quoted 2 lines · Stan Hoeppner
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
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 7 lines · Michael Cronenworth
Quoted 2 lines · 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.
Signature · 7 lines
Dave Chinner [email protected] _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Quoted 2 lines · Dave Chinner
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
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 7 lines · 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.
Signature · 8 lines
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/
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 2 lines · Michael Monnerie
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
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs