http://oss.sgi.com/bugzilla/show_bug.cgi?id=284
Summary: Log reservation runs out with bonnie++
Product: Linux XFS
Version: Current
Platform: All
OS/Version: Linux
Status: NEW
Severity: normal
Priority: High
Component: XFS kernel code
AssignedTo: xfs-master@xxxxxxxxxxx
ReportedBy: sandeen@xxxxxxx
Soumen Chakrabarti <soumen@xxxxxxxxxxxxxx> reports:
Repeatable bug, here's how to create the situation:
1. Start with a fresh install of stock RedHat 9.
2. Download kernel 2.4.22.
3. Patch in XFS 1.3.1 and build new kernel.
4. Create an XFS file system and mount it on (say) /mnt/xfs.
5. Download and build bonnie++-1.03a
6. Run bonnie++ with these flags
bonnie++ -d /mnt/xfs -u 0:0 -s 0 -n 16
Everything goes fine. This is a test that creates, stats, and
deletes 16*1024 empty files.
7. Now up the number of files to 500*1024
bonnie++ -d /mnt/xfs -u 0:0 -s 0 -n 500
Here are the syslog entries.
Filesystem "sd(8,17)": xfs_log_write: reservation ran out. Need to up
reservation
xfs_force_shutdown(sd(8,17),0x8) called from line 1739 of file xfs_log.c.
Return address = 0xc01f4cdb
Filesystem "sd(8,17)": Corruption of in-memory data detected. Shutting down
filesystem: sd(8,17)
Please umount the filesystem, and rectify the problem(s)
xfs_force_shutdown(sd(8,17),0x2) called from line 747 of file xfs_log.c. Return
address = 0xc01f4cdb
8. You can however recover and mount again:
umount /mnt/xfs
mount /dev/sdb1 /mnt/xfs
XFS mounting filesystem sd(8,17)
Starting XFS recovery on filesystem: sd(8,17) (dev: 8/17)
Ending XFS recovery on filesystem: sd(8,17) (dev: 8/17)
Other info: Not specific to hardware, has been reproduced on two
different servers, one with SCSI, the other with SCSI RAID.
On these same servers,
9. IBM JFS with this bonnie++ benchmark requires a hard reset.
10. Reiserfs survives repeated bonnie++ tests as above.
Also, on a third server we have XFS 1.2.0 which works fine too.
So XFS 1.3.1 seems heavily implicated.
Thanks for any patches and/or fixes.
Christian Guggenberger <christian.guggenberger@xxxxxxxxxxxxxxxxxxxxxxxx>
further reports:
I also can verify this forced shutdown here on a debian/woody box (PIII, IDE)
with XFS CVS of 20031015. After umount/mount, the forced shutdown occures
again,
if I try to delete the directory created by bonnie++. An xfs_repair after
umount/mount/umount fixes this.
However, with plain 2.4.21 + xfs-1.3.1 the bonnie++-tests complete
without any errors.
The forced_shutdown occures during bonnie's "deleting files in random
order". It's 100% reproducible with xfs CVS of 20031015 (and NOT with
2.4.21-xfs-1.3.1).
Here's the output of xfs_info:
output of xfs_info:
meta-data=/mnt/testxfs isize=256 agcount=11, agsize=262144
blks
= sectsz=512
data = bsize=4096 blocks=2725017, imaxpct=25
= sunit=0 swidth=0 blks, unwritten=0
naming =version 2 bsize=4096
log =internal bsize=4096 blocks=1200, version=1
= sectsz=512 sunit=0 blks
realtime =none extsz=65536 blocks=0, rtextents=0
512 MB RAM.
xfsprogs-2.3.11.
no special options either at mkfs-time or at mount-time.
as an update, I re-ran the described bonnie test (using 400 instead of
500).
This time IO-error happens while deleting in sequential order.
Here's the logs:
bonnie77:~# bonnie++ -d /mnt/testxfs -u 0:0 -s 0 -n 400
Using uid:0, gid:0.
Create files in sequential order...done.
Stat files in sequential order...done.
Delete files in sequential order...Can't delete file 0403455YEZdqfASG
Cleaning up test directory after error.
Bonnie: drastic I/O error (rmdir): Input/output error
Filesystem "ide0(3,6)": xfs_log_write: reservation ran out. Need to up
reservation
xfs_force_shutdown(ide0(3,6),0x8) called from line 1739 of file
xfs_log.c. Return address = 0xe091484a
Filesystem "ide0(3,6)": Corruption of in-memory data detected. Shutting
down filesystem: ide0(3,6)
Please umount the filesystem, and rectify the problem(s)
xfs_force_shutdown(ide0(3,6),0x2) called from line 1321 of file
xfs_log.c. Return address = 0xe091484a
the saga continues :
in first tests, the Bonnie++ testdir was not removable, after the
forced_shutdown (after umount/mount, of course) - a xfs_repair was
needed.
This time (after an xfs_repair, though), all files in the dir could be
removed - at least all visible to me. The dir itself not. 'directory not
empty'
I decided to go ahead with xfsprogs-2.5.11, re-ran xfs_repair, and my
empty bonnie++ dir could be removed.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
|