[linux-lvm] Share getting disappeared untill system is reboot

[Sagar Borikar]

Folks,
   
  I am not sure whether this is the right list for below mentioned question. If not please direct me to the right list. Thanks in advance.
   
  I am currently finding a strange issue with 2.6.18 kernel while performing the stress test with iozone on the NAS box under development. When I am trying to pump the data over iozone on the NAS box, the share on which the data transfer is progressing, gets disappeared suddenly till I reboot the system. Although this problem is seen infrequently, the frequency is quite high i.e upto 3 times out of five tests. I was able to capture following stack dump on the system. 
   
  1 input overrun(s)
zoneinfo 1725 02 1744XFS internal error XFS_WANT_CORRUPTED_GOTO at line 2191 of file fs/xfs/x
fs_bmap_btree.c. Caller 0x802b61a4
Call Trace:
[<801098a8>] dump_stack+0x18/0x44
[<802c6150>] xfs_error_report+0x58/0x64
[<802b629c>] xfs_bmbt_insert+0x16c/0x194
[<802a7674>] xfs_bmap_add_extent_delay_real+0x888/0x15e8
[<802a6c30>] xfs_bmap_add_extent+0x328/0x4e4
[<802afa40>] xfs_bmapi+0xa98/0x13e4
[<802d6e30>] xfs_iomap_write_allocate+0x340/0x5d8
[<802d5718>] xfs_iomap+0x408/0x4dc
[<803014bc>] xfs_bmap+0x30/0x3c
[<802f68ac>] xfs_map_blocks+0x50/0x84
[<802f7cdc>] xfs_page_state_convert+0x3f4/0x840
[<802f820c>] xfs_vm_writepage+0xe4/0x140
[<80198778>] mpage_writepages+0x24c/0x45c
[<802f8298>] xfs_vm_writepages+0x30/0x3c
[<801507d4>] do_writepages+0x44/0x84
[<80196648>] __sync_single_inode+0x68/0x234
[<801969a0>] __writeback_single_inode+0x18c/0x1ac
[<80196bc8>] sync_sb_inodes+0x208/0x2f0
[<80196d34>] writeback_inodes+0x84/0xd0
[<80150400>] background_writeout+0xac/0xfc
[<80151350>] __pdflush+0x130/0x228
[<80151478>] pdflush+0x30/0x3c
[<801398dc>] kthread+0x98/0xe0
[<80104c58>] kernel_thread_helper+0x10/0x18

Filesystem "dm-3": XFS internal error xfs_trans_cancel at line 1138 of file fs/xfs/xfs_trans.c. Caller 0x802d7084
Call Trace:
[<801098a8>] dump_stack+0x18/0x44
[<802c6150>] xfs_error_report+0x58/0x64
[<802e89a4>] xfs_trans_cancel+0x98/0x150
[<802d7084>] xfs_iomap_write_allocate+0x594/0x5d8
[<802d5718>] xfs_iomap+0x408/0x4dc
[<803014bc>] xfs_bmap+0x30/0x3c
[<802f68ac>] xfs_map_blocks+0x50/0x84
[<802f7cdc>] xfs_page_state_convert+0x3f4/0x840
[<802f820c>] xfs_vm_writepage+0xe4/0x140
[<80198778>] mpage_writepages+0x24c/0x45c
[<802f8298>] xfs_vm_writepages+0x30/0x3c
[<801507d4>] do_writepages+0x44/0x84
[<80196648>] __sync_single_inode+0x68/0x234
[<801969a0>] __writeback_single_inode+0x18c/0x1ac
[<80196bc8>] sync_sb_inodes+0x208/0x2f0
[<80196d34>] writeback_inodes+0x84/0xd0
[<80150400>] background_writeout+0xac/0xfc
[<80151350>] __pdflush+0x130/0x228
[<80151478>] pdflush+0x30/0x3c
[<801398dc>] kthread+0x98/0xe0
[<80104c58>] kernel_thread_helper+0x10/0x18

xfs_force_shutdown(dm-3,0x8) called from line 1139 of file fs/xfs/xfs_trans.c. Return address = 0x80302eec
Filesystem "dm-3": Corruption of in-memory data detected. Shutting down filesystem: dm-3
Please umount the filesystem, and rectify the problem(s)

  After googling, I figured out that 2.6.19 has fixed this issue.  Any pointers on that?
   
  Thanks
  Sagar

       
---------------------------------
Be a better friend, newshound, and know-it-all with Yahoo! Mobile.  Try it now.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-lvm/attachments/20080504/c8ed75e2/attachment.htm>