| Summary: | XFS filesystem randomly crash with " xfs_iflush: Bad inode %d magic number" | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Il'ya <wax> |
| Component: | [OLD] Core system | Assignee: | Gentoo Linux bug wranglers <bug-wranglers> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | ||
| Priority: | High | ||
| Version: | 2008.0 | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
Current kernel config
emerge --info output copy of /var/log/messages |
||
|
Description
Il'ya
2009-04-30 09:10:29 UTC
Created attachment 189934 [details]
Current kernel config
Created attachment 189936 [details]
emerge --info output
Created attachment 189938 [details]
copy of /var/log/messages
bump I use xfs for a lot of servers, without any error. Have you tried to check or fix it? with xfs_check and xfs_repair? Your on-disk XFS is corrupted. If it's not a system-critical partition, umount and use xfs_check and xfs_repair. If it is system-critical, boot off a livecd and do the same (In reply to comment #6) > Your on-disk XFS is corrupted. If it's not a system-critical partition, umount > and use xfs_check and xfs_repair. If it is system-critical, boot off a livecd > and do the same > In this partition i have non-critical multimedia data, $CCACHE_DIR, $PORTAGE_TMPDIR and public spool. I've already remount this partition several times and reboot machine. There is only one more time identical problem have been occured. wrath ~ # mount | fgrep sdb /dev/sdb1 on /mnt/puzo type xfs (rw) wrath ~ # umount /mnt/puzo/ wrath ~ # time xfs_check /dev/sdb1 real 0m26.725s user 0m2.710s sys 0m0.997s wrath ~ # xfs_repair -v /dev/sdb1 Phase 1 - find and verify superblock... - block cache size set to 359360 entries Phase 2 - using internal log - zero log... zero_log: head block 6 tail block 6 - 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 - 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 Phase 5 - rebuild AG headers and trees... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - 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 - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... XFS_REPAIR Summary Sat May 9 01:42:27 2009 Phase Start End Duration Phase 1: 05/09 01:42:07 05/09 01:42:07 Phase 2: 05/09 01:42:07 05/09 01:42:09 2 seconds Phase 3: 05/09 01:42:09 05/09 01:42:25 16 seconds Phase 4: 05/09 01:42:25 05/09 01:42:26 1 second Phase 5: 05/09 01:42:26 05/09 01:42:26 Phase 6: 05/09 01:42:26 05/09 01:42:27 1 second Phase 7: 05/09 01:42:27 05/09 01:42:27 Total run time: 20 seconds done wrath ~ # I think this output tell us, that everything is "Ok" for now. Isn't it? I'm sorry for my terrible english. ok, now lastly mount it again and see if you still get any errors when you try to access whatever file was on that inode. (In reply to comment #8) > ok, now lastly mount it again and see if you still get any errors when you try > to access whatever file was on that inode. > I'd got no errors after remount. This bug is very rare for me and situation described in "Description" field have random conditions. It is triggered only once during last week. If you still get similar, I'd suspect something is just fractionally bad in your hardware. |
