xfs_repair 3.1.1 doesnt repair broken filesystem
I do a repair on a broken filesystem, which reports no problems. Then I mount and "ls -l", and you can easily see all those broken entries, which should be directories. They are not repaired. What could I do?
# xfs_repair -v /dev/bigbak/bigbak
Phase 1 - find and verify superblock...
- block cache size set to 8536 entries
Phase 2 - using internal log
- zero log...
XFS: totally zeroed log
zero_log: head block 0 tail block 0
- 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
- agno = 4
- agno = 5
- agno = 6
- agno = 7
- agno = 8
- agno = 9
- agno = 10
- agno = 11
- agno = 12
- agno = 13
- agno = 14
- agno = 15
- agno = 16
- agno = 17
- agno = 18
- agno = 19
- agno = 20
- agno = 21
- agno = 22
- agno = 23
- agno = 24
- agno = 25
- agno = 26
- agno = 27
- agno = 28
- agno = 29
- agno = 30
- agno = 31
- 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
- agno = 4
- agno = 5
- agno = 6
- agno = 7
- agno = 8
- agno = 9
- agno = 10
- agno = 11
- agno = 12
- agno = 13
- agno = 14
- agno = 15
- agno = 16
- agno = 17
- agno = 18
- agno = 19
- agno = 20
- agno = 21
- agno = 22
- agno = 23
- agno = 24
- agno = 25
- agno = 26
- agno = 27
- agno = 28
- agno = 29
- agno = 30
- agno = 31
Phase 5 - rebuild AG headers and trees...
- agno = 0
- agno = 1
- agno = 2
- agno = 3
- agno = 4
- agno = 5
- agno = 6
- agno = 7
- agno = 8
- agno = 9
- agno = 10
- agno = 11
- agno = 12
- agno = 13
- agno = 14
- agno = 15
- agno = 16
- agno = 17
- agno = 18
- agno = 19
- agno = 20
- agno = 21
- agno = 22
- agno = 23
- agno = 24
- agno = 25
- agno = 26
- agno = 27
- agno = 28
- agno = 29
- agno = 30
- agno = 31
- reset superblock...
Phase 6 - check inode connectivity...
- resetting contents of realtime bitmap and summary inodes
- traversing filesystem ...
- agno = 0
- agno = 1
- agno = 2
- agno = 3
- agno = 4
- agno = 5
- agno = 6
- agno = 7
- agno = 8
- agno = 9
- agno = 10
- agno = 11
- agno = 12
- agno = 13
- agno = 14
- agno = 15
- agno = 16
- agno = 17
- agno = 18
- agno = 19
- agno = 20
- agno = 21
- agno = 22
- agno = 23
- agno = 24
- agno = 25
- agno = 26
- agno = 27
- agno = 28
- agno = 29
- agno = 30
- agno = 31
- traversal finished ...
- moving disconnected inodes to lost+found ...
Phase 7 - verify and correct link counts... XFS_REPAIR Summary Tue May 18 09:50:35 2010
Phase Start End Duration Phase 1: 05/18 09:48:12 05/18 09:48:12 Phase 2: 05/18 09:48:12 05/18 09:48:44 32 seconds Phase 3: 05/18 09:48:44 05/18 09:49:39 55 seconds Phase 4: 05/18 09:49:39 05/18 09:49:54 15 seconds Phase 5: 05/18 09:49:54 05/18 09:49:54 Phase 6: 05/18 09:49:54 05/18 09:50:35 41 seconds Phase 7: 05/18 09:50:35 05/18 09:50:35
Total run time: 2 minutes, 23 seconds
done
# mount /dev/bigbak/bigbak /disks/bigbak/ # l /disks/bigbak/ ls: Zugriff auf /disks/bigbak/lama nicht möglich: Das Argument ist ungültig ls: Zugriff auf /disks/bigbak/maza nicht möglich: Das Argument ist ungültig ls: Zugriff auf /disks/bigbak/paan nicht möglich: Das Argument ist ungültig ls: Zugriff auf /disks/bigbak/public nicht möglich: Das Argument ist ungültig ls: Zugriff auf /disks/bigbak/tmp nicht möglich: Das Argument ist ungültig ls: Zugriff auf /disks/bigbak/upload nicht möglich: Das Argument ist ungültig ls: Zugriff auf /disks/bigbak/vop nicht möglich: Das Argument ist ungültig ls: Zugriff auf /disks/bigbak/zmi nicht möglich: Das Argument ist ungültig insgesamt 20 drwxrwx--- 14 root 1000 4096 12. Mai 09:36 ./ drwxr-xr-x 7 root root 184 17. Mai 12:40 ../ drwx------ 6 1007 nogroup 4096 9. Jan 15:51 anse/ -rw-r--r-- 1 root root 155 12. Mai 09:42 du.20100512 -rwx------ 1 root root 141 26. Mär 14:51 find-inode.sh* drwx------ 2 1006 nogroup 68 23. Nov 15:15 hope/ drwxrwxr-x+ 4 1007 nogroup 49 29. Nov 12:32 itm/ drwx------ 2 1002 nogroup 68 23. Nov 15:14 jog/ ??????????? ? ? ? ? ? lama ??????????? ? ? ? ? ? maza ??????????? ? ? ? ? ? paan ??????????? ? ? ? ? ? public ??????????? ? ? ? ? ? tmp ??????????? ? ? ? ? ? upload ??????????? ? ? ? ? ? vop ??????????? ? ? ? ? ? zmi
Signature · 10 lines
mit freundlichen Grüssen, Michael Monnerie, Ing. BSc it-management Internet Services http://proteger.at [gesprochen: Prot-e-schee] Tel: 0660 / 415 65 31 // Wir haben im Moment zwei Häuser zu verkaufen: // http://zmi.at/langegg/ // http://zmi.at/haus2009/
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Le Tue, 18 May 2010 09:53:47 +0200
Michael Monnerie <[email protected]> écrivait:
Quoted 3 lines
I do a repair on a broken filesystem, which reports no problems. Then I mount and "ls -l", and you can easily see all those broken entries, which should be directories. They are not repaired. What could I do?
What is your xfs_repair version? (-V option). I guess 3.0.1 or more should be better.
Signature · 6 lines
------------------------------------------------------------------------
Emmanuel Florac | Direction technique
| Intellique
| <[email protected]>
| +33 1 78 94 84 02
------------------------------------------------------------------------_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 4 lines · Michael Monnerie
I do a repair on a broken filesystem, which reports no problems. Then I mount and "ls -l", and you can easily see all those broken entries, which should be directories. They are not repaired. What could I do?
I think you have created the filesystem with -o inode64 and now you are remounting it without -o inode64.
After you created one file or directory with the inode64 option you NEED to always specify inode64 option at subsequent mounts or you won't be able to access such files/directories. (Not sure if forgetting to use the option can even cause data corruption upon write. Might inode32 writes overwrite the inaccessible inode64 files/dirs? XFS developers might know this.)
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Re: xfs_repair 3.1.1 doesnt repair broken filesystem [solved]
Quoted 8 lines · On Dienstag, 18. Mai 2010 Default User wrote:
I think you have created the filesystem with -o inode64 and now you
are remounting it without -o inode64.
After you created one file or directory with the inode64 option you
NEED to always specify inode64 option at subsequent mounts or you won't be able to access such files/directories.
(Not sure if forgetting to use the option can even cause data
corruption upon write. Might inode32 writes overwrite the inaccessible inode64 files/dirs? XFS developers might know this.)
Ah! You're absolutely right, inode64 did the trick.
Isn't it a kind of bug? Of course normally you would mount filesystems from fstab, but for a temporary one like this I didn't do that. Still, having xfs issuing not even a warning smells like a bug, even if they might say it's a "feature by design".
So if you have an external 2TB drive from a friend and mount it on your PC, you can't tell if inode64 was used or not? And if you mount without that option you could destroy contents? In my case it was "easy" to see there are fs problems, but what if such inodes are only used in subdirs? Even with this "easy seeable" problem I didn't have the idea of a missing inode64 option.
Signature · 10 lines
mit freundlichen Grüssen, Michael Monnerie, Ing. BSc it-management Internet Services http://proteger.at [gesprochen: Prot-e-schee] Tel: 0660 / 415 65 31 // Wir haben im Moment zwei Häuser zu verkaufen: // http://zmi.at/langegg/ // http://zmi.at/haus2009/
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs