On Fri, 24 Oct 2003, Nathan Scott wrote:
> > I've installed 2.6.0-test8 on machine attached to HW raid, made 5.5TB
> 5.5 Tb -- are you using the LBD option, or a 64 bit platform?
> > partition (using LVM) and made XFS filesystem on this partition. This
> > partittion was exported to cca 25 nodes. I started some stress tests
> What does that mean? (cca?) thanks.
It means 'approximately'. To be more precise, there were 24 nodes copying
data to and from the partition via NFS.
> > Oct 22 13:12:56 storage2 kernel: Filesystem "dm-0": XFS internal error
> > xfs_alloc_read_agf at line 2208 of file fs/xfs/xfs_alloc.c. Caller
> > 0xc01e8f5c
> > Oct 22 13:12:56 storage2 kernel: Call Trace:
> > Oct 22 13:12:56 storage2 kernel: [<c01e93d4>]
> > xfs_alloc_read_agf+0x19e/0x214
> > Oct 22 13:12:56 storage2 kernel: [<c01e8f5c>]
> > xfs_alloc_fix_freelist+0x458/0x46e
> > Oct 22 13:12:56 storage2 last message repeated 2 times
> > Oct 22 13:12:56 storage2 kernel: [<c023cdf8>] xfs_trans_log_buf+0x6e/0xa8
> > Oct 22 13:12:56 storage2 kernel: [<c0204733>] xfs_bmbt_get_state+0x2f/0x3c
> > Oct 22 13:12:56 storage2 kernel: [<c01e973e>] xfs_alloc_vextent+0x2f4/0x520
> > Oct 22 13:12:56 storage2 kernel: [<c01f89d9>] xfs_bmap_alloc+0x8eb/0x1856
> > Oct 22 13:12:56 storage2 kernel: [<c02515b0>]
> > xfs_iomap_write_delay+0x35e/0x40a
> You're allocating real disk space for delayed allocate file data
> down this path, and the read of the allocation group header found
> something that didn't look at all like metadata on disk.
> So, you definately have corruption and will need to xfs_repair.
> Any ideas as to what operations triggered the initial problem?
> (is it reproducible for you?)
I can simply reproduce it - the only thing needed is to nfsmount this
partition from clients and start writing a file to it, as I've written
before. The crash occurs immediately after the transfer begins.
As I've said, I wouldn't blame HW failure or things like this, because
ext3 does the job flawlessly, as far as I can see.