------- Additional Comments From Dave Jones 2005-03-09 16:37 EST -------
you're better off reporting this one to the maintainers at SGI.
---------------------------- Original Message ----------------------------
Subject: [Bug 150427] New: XFS internal error xfs_alloc_read_agf
From: bugzilla@xxxxxxxxxx
Date: Sun, March 6, 2005 12:40
--------------------------------------------------------------------------
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.
https://bugzilla.redhat.com/beta/show_bug.cgi?id=150427
Summary: XFS internal error xfs_alloc_read_agf
Product: Fedora Core
Version: fc3
Platform: i386
OS/Version: Linux
Status: NEW
Severity: high
Priority: normal
Component: kernel
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6)
Gecko/20050224 Firefox/1.0.1 Fedora/1.0.1-1.3.1
Description of problem:
I encountered the following error while working with a XFS filesystem:
Mar 3 00:40:52 tschan1 kernel: 0x0: 58 41 47 46 00 00 00 01 00 00 00 03
00 2e 4d 21 Mar 3 00:40:52 tschan1 kernel: Filesystem "md1": XFS internal
error xfs_alloc_read_agf at line 2195 of file fs/xfs/xfs_alloc.c. Caller
0xf91ca8b3 Mar 3 00:40:52 tschan1 kernel: [<f91caef8>]
xfs_alloc_read_agf+0x135/0x1d8 [xfs] Mar 3 00:40:52 tschan1 kernel:
[<f91ca8b3>] xfs_alloc_fix_freelist+0x36/0x339 [xfs] Mar 3 00:40:52
tschan1 last message repeated 2 times
Mar 3 00:40:52 tschan1 kernel: [<f9202686>]
xlog_assign_tail_lsn+0xc/0x113 [xfs] Mar 3 00:40:52 tschan1 kernel:
[<f92056ce>] xlog_state_release_iclog+0x18/0x179 [xfs] Mar 3 00:40:52
tschan1 kernel: [<f9201b74>] xfs_log_release_iclog+0xe/0x35 [xfs] Mar 3
00:40:52 tschan1 kernel: [<f9204e8b>]
xlog_regrant_write_log_space+0x324/0x6ee [xfs] Mar 3 00:40:52 tschan1
kernel: [<f91cb496>] xfs_free_extent+0xab/0xef [xfs] Mar 3 00:40:52
tschan1 kernel: [<f91da4a7>] xfs_bmap_finish+0xdd/0x14e [xfs] Mar 3
00:40:52 tschan1 kernel: [<f9217d9d>] xfs_rmdir+0x30a/0x3e2 [xfs] Mar 3
00:40:52 tschan1 kernel: [<f92205e1>] linvfs_rmdir+0x13/0x2f [xfs] Mar 3
00:40:52 tschan1 kernel: [<c016e437>] vfs_rmdir+0x18d/0x1d9 Mar 3
00:40:52 tschan1 kernel: [<c016e51a>] sys_rmdir+0x97/0xe9
Mar 3 00:40:52 tschan1 kernel: [<c015d5cc>] filp_close+0x59/0x5f Mar 3
00:40:52 tschan1 kernel: [<c0103337>] syscall_call+0x7/0xb Mar 3
00:40:52 tschan1 kernel: xfs_force_shutdown(md1,0x8) called from line 4073
of file fs/xfs/xfs_bmap.c. Return address = 0xf9222cdb Mar 3 00:40:52
tschan1 kernel: Filesystem "md1": Corruption of in-memory data detected.
Shutting down filesystem: md1 Mar 3 00:40:52 tschan1 kernel: Please
umount the filesystem, and rectify the problem(s) Mar 3 00:41:23 tschan1
kernel: xfs_force_shutdown(md1,0x1) called from line 353 of file
fs/xfs/xfs_rw.c. Return address = 0xf9222cdb
Setup:
2x Seagate Barracuda ST3200822AS connected through
Adaptec ASH-1205SA with Silicon Image SiI 3112 (driver sata_sil)
2 software raid 1 arrays, /dev/md0 100 MB XFS, /dev/md1 180 GB XFS
Special kernel modules:
nvidia 1.0-6629
fuse 2.2
At the time the corruption was detected the large filesystem was nearly
full (about 300 MB free).
The following behaviour is always reproducible, at least on FC3 rescue,
kernel-2.6.10-1.737_FC3 and kernel-2.6.10-1.770_FC3 (latest at this time)
with or without before mentioned kernel modules:
xfs_repair is unable to repair the filesystem and aborts with the
following output:
Phase 1 - find and verify superblock...
Phase 2 - using internal log
- zero log...
- 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
entry "/ost+found" at block 0 offset 776 in directory inode 128 references
invalid inode 18374686479671623679
clearing inode number in entry at offset 776...
entry at block 0 offset 776 in directory inode 128 has illegal name
"/ost+found": - agno = 1
- agno = 2
- agno = 3
- agno = 4
- agno = 5
- agno = 6
- agno = 7
imap claims a free inode 506020455 is in use, correcting imap and clearing
inode
- agno = 8
- agno = 9
- agno = 10
- agno = 11
- agno = 12
LEAFN node level is 1 inode 813219798 bno = 8388608
- agno = 13
- agno = 14
- agno = 15
- process newly discovered inodes...
Phase 4 - check for duplicate blocks...
- setting up duplicate extent list...
- clear lost+found (if it exists) ...
- check for inodes claiming duplicate blocks...
- agno = 0
inode 0x35c bmap block 0x6e4d20 claimed, state is 5
- agno = 1
data fork in regular inode 89335619 claims used block 53366048
xfs_repair: dinode.c:2436: process_dinode_int: Assertion `err == 0'
failed. Aborted
After a mount, umount, mount sequence the filesystem is fully readable
(with or without xfs_repair) but after a few write operations (create,
delete a file or write into a file) the same internal error reappears.
atime updates however do not trigger this error.
I'll keep the damaged filesystem for a few days. Please tell me if I can
provide further information.
Version-Release number of selected component (if applicable):
kernel-2.6.10-1.737_FC3
How reproducible:
Didn't try
Additional info:
|