From owner-linux-xfs@oss.sgi.com Thu Apr 1 09:16:48 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 01 Apr 2004 09:16:52 -0800 (PST) Received: from vsmtp3alice.tin.it (vsmtp3alice.tin.it [212.216.176.143]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i31HGkKO003783 for ; Thu, 1 Apr 2004 09:16:47 -0800 Received: from wind.it (80.182.79.45) by vsmtp3alice.tin.it (7.0.027) id 4061BAA60008FAE0 for linux-xfs@oss.sgi.com; Thu, 1 Apr 2004 18:53:36 +0200 Message-ID: <406C4916.3040806@wind.it> Date: Thu, 01 Apr 2004 18:53:42 +0200 From: Matteo Croce <3297627799@wind.it> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: XFS_WANT_CORRUPTED_RETURN Content-type: text/plain Content-Transfer-Encoding: 8bit X-archive-position: 2683 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: 3297627799@wind.it Precedence: bulk X-list: linux-xfs Hi, I'm using XFS on my root partition with linux (2.6.4 kernel). The partition is 15976000k length and formatted with: mkfs.xfs -f -bsize=512 -nsize=512 -lsize=65536s /dev/hda2 I was downloading some files from internet when i get many messages from the kernel saing: XFS_WANT_CORRUPTED_RETURN I cancelled the download and freezed the filesystem with xfs_freeze. The pc is still freezed, i dont think that shutting down will be a good idea... I also attach the output of dmesg. What did happen? What I have to do? Shut down and run xfs_repair? Please reply because that pc is still freezed. Bye. -- Attached file included as plaintext by Ecartis -- -- File: dmesg.xfs 4> [] xfs_alloc_vextent+0x2f0/0x391 [] xfs_bmap_alloc+0x847/0x131e [] __copy_to_user_ll+0x68/0x6c [] file_read_actor+0xd9/0xea [] xfs_bmbt_get_state+0x2f/0x3b [] xfs_bmapi+0x519/0x141b [] _pagebuf_lookup_pages+0x17b/0x39b [] xfs_bmbt_get_state+0x2f/0x3b [] xfs_bmap_do_search_extents+0xb4/0x3ce [] pagebuf_get+0xd1/0x150 [] xfs_dir2_grow_inode+0xf2/0x485 [] xfs_dir2_leaf_to_node+0x30/0x17d [] xfs_da_read_buf+0x57/0x5b [] xfs_dir2_leaf_addname+0x271/0xabe [] xfs_bmap_last_offset+0xbe/0x115 [] xfs_dir2_isleaf+0x2e/0x6e [] xfs_dir2_createname+0x152/0x179 [] xfs_trans_ijoin+0x35/0x7f [] xfs_rename+0x395/0xb4b [] linvfs_rename+0x49/0x87 [] vfs_rename_other+0xa0/0xd5 [] vfs_rename+0x12f/0x358 [] sys_rename+0x1f1/0x220 [] vfs_read+0xc9/0x119 [] sys_read+0x42/0x63 [] syscall_call+0x7/0xb XFS internal error XFS_WANT_CORRUPTED_RETURN at line 295 of file fs/xfs/xfs_alloc.c. Caller 0xc0181759 Call Trace: [] xfs_alloc_fixup_trees+0x1fe/0x34a [] xfs_alloc_ag_vextent_near+0x4aa/0xc61 [] xfs_alloc_ag_vextent_near+0x4aa/0xc61 [] update_wall_time+0xd/0x36 [] xfs_alloc_ag_vextent+0x113/0x115 [] xfs_alloc_vextent+0x2f0/0x391 [] xfs_bmap_alloc+0x847/0x131e [] dev_queue_xmit+0x209/0x296 [] ip_finish_output+0xb2/0x1b5 [] xfs_bmapi+0x26a/0x141b [] xfs_bmbt_get_state+0x2f/0x3b [] xfs_bmapi+0x519/0x141b [] _pagebuf_lookup_pages+0x17b/0x39b [] xfs_bmbt_get_state+0x2f/0x3b [] xfs_bmap_do_search_extents+0xb4/0x3ce [] pagebuf_get+0xd1/0x150 [] xfs_dir2_grow_inode+0xf2/0x485 [] xfs_dir2_leaf_to_node+0x30/0x17d [] xfs_da_read_buf+0x57/0x5b [] xfs_dir2_leaf_addname+0x271/0xabe [] xfs_bmap_last_offset+0xbe/0x115 [] xfs_dir2_isleaf+0x2e/0x6e [] xfs_dir2_createname+0x152/0x179 [] xfs_trans_ijoin+0x35/0x7f [] xfs_rename+0x395/0xb4b [] linvfs_rename+0x49/0x87 [] vfs_rename_other+0xa0/0xd5 [] vfs_rename+0x12f/0x358 [] sys_rename+0x1f1/0x220 [] vfs_read+0xc9/0x119 [] sys_read+0x42/0x63 [] syscall_call+0x7/0xb XFS internal error XFS_WANT_CORRUPTED_RETURN at line 295 of file fs/xfs/xfs_alloc.c. Caller 0xc0181759 Call Trace: [] xfs_alloc_fixup_trees+0x1fe/0x34a [] xfs_alloc_ag_vextent_near+0x4aa/0xc61 [] xfs_alloc_ag_vextent_near+0x4aa/0xc61 [] update_wall_time+0xd/0x36 [] xfs_alloc_ag_vextent+0x113/0x115 [] xfs_alloc_vextent+0x2f0/0x391 [] xfs_bmap_alloc+0x847/0x131e [] dev_queue_xmit+0x209/0x296 [] ip_finish_output+0xb2/0x1b5 [] xfs_bmapi+0x26a/0x141b [] xfs_bmbt_get_state+0x2f/0x3b [] xfs_bmapi+0x519/0x141b [] _pagebuf_lookup_pages+0x17b/0x39b [] xfs_bmbt_get_state+0x2f/0x3b [] xfs_bmap_do_search_extents+0xb4/0x3ce [] pagebuf_get+0xd1/0x150 [] xfs_dir2_grow_inode+0xf2/0x485 [] xfs_dir2_leaf_to_node+0x30/0x17d [] xfs_da_read_buf+0x57/0x5b [] xfs_dir2_leaf_addname+0x271/0xabe [] xfs_bmap_last_offset+0xbe/0x115 [] xfs_dir2_isleaf+0x2e/0x6e [] xfs_dir2_createname+0x152/0x179 [] xfs_trans_ijoin+0x35/0x7f [] xfs_rename+0x395/0xb4b [] linvfs_rename+0x49/0x87 [] vfs_rename_other+0xa0/0xd5 [] vfs_rename+0x12f/0x358 [] sys_rename+0x1f1/0x220 [] syscall_call+0x7/0xb XFS internal error XFS_WANT_CORRUPTED_RETURN at line 295 of file fs/xfs/xfs_alloc.c. Caller 0xc0181759 Call Trace: [] xfs_alloc_fixup_trees+0x1fe/0x34a [] xfs_alloc_ag_vextent_near+0x4aa/0xc61 [] xfs_alloc_ag_vextent_near+0x4aa/0xc61 [] update_wall_time+0xd/0x36 [] xfs_alloc_ag_vextent+0x113/0x115 [] xfs_alloc_vextent+0x2f0/0x391 [] xfs_bmap_alloc+0x847/0x131e [] dev_queue_xmit+0x209/0x296 [] ip_finish_output+0xb2/0x1b5 [] xfs_bmapi+0x26a/0x141b [] xfs_bmbt_get_state+0x2f/0x3b [] xfs_bmapi+0x519/0x141b [] _pagebuf_lookup_pages+0x17b/0x39b [] xfs_bmbt_get_state+0x2f/0x3b [] xfs_bmap_do_search_extents+0xb4/0x3ce [] pagebuf_get+0xd1/0x150 [] xfs_dir2_grow_inode+0xf2/0x485 [] xfs_dir2_leaf_to_node+0x30/0x17d [] xfs_da_read_buf+0x57/0x5b [] xfs_dir2_leaf_addname+0x271/0xabe [] xfs_bmap_last_offset+0xbe/0x115 [] xfs_dir2_isleaf+0x2e/0x6e [] xfs_dir2_createname+0x152/0x179 [] xfs_trans_ijoin+0x35/0x7f [] xfs_rename+0x395/0xb4b [] linvfs_rename+0x49/0x87 [] vfs_rename_other+0xa0/0xd5 [] vfs_rename+0x12f/0x358 [] sys_rename+0x1f1/0x220 [] vfs_read+0xc9/0x119 [] sys_read+0x42/0x63 [] syscall_call+0x7/0xb XFS internal error XFS_WANT_CORRUPTED_RETURN at line 295 of file fs/xfs/xfs_alloc.c. Caller 0xc0181759 Call Trace: [] xfs_alloc_fixup_trees+0x1fe/0x34a [] xfs_alloc_ag_vextent_near+0x4aa/0xc61 [] xfs_alloc_ag_vextent_near+0x4aa/0xc61 [] update_wall_time+0xd/0x36 [] xfs_alloc_ag_vextent+0x113/0x115 [] xfs_alloc_vextent+0x2f0/0x391 [] xfs_bmap_alloc+0x847/0x131e [] dev_queue_xmit+0x209/0x296 [] ip_finish_output+0xb2/0x1b5 [] xfs_bmapi+0x26a/0x141b [] xfs_bmbt_get_state+0x2f/0x3b [] xfs_bmapi+0x519/0x141b [] _pagebuf_lookup_pages+0x17b/0x39b [] xfs_bmbt_get_state+0x2f/0x3b [] xfs_bmap_do_search_extents+0xb4/0x3ce [] pagebuf_get+0xd1/0x150 [] xfs_dir2_grow_inode+0xf2/0x485 [] do_timer+0xdf/0xe4 [] do_IRQ+0x103/0x136 [] xfs_dir2_leaf_to_node+0x30/0x17d [] common_interrupt+0x18/0x20 [] xfs_dir2_leaf_addname+0x271/0xabe [] xfs_bmap_last_offset+0xbe/0x115 [] xfs_dir2_isleaf+0x2e/0x6e [] xfs_dir2_createname+0x152/0x179 [] xfs_trans_ijoin+0x35/0x7f [] xfs_rename+0x395/0xb4b [] linvfs_rename+0x49/0x87 [] vfs_rename_other+0xa0/0xd5 [] vfs_rename+0x12f/0x358 [] sys_rename+0x1f1/0x220 [] syscall_call+0x7/0xb XFS internal error XFS_WANT_CORRUPTED_RETURN at line 295 of file fs/xfs/xfs_alloc.c. Caller 0xc0181759 Call Trace: [] xfs_alloc_fixup_trees+0x1fe/0x34a [] xfs_alloc_ag_vextent_near+0x4aa/0xc61 [] xfs_alloc_ag_vextent_near+0x4aa/0xc61 [] update_wall_time+0xd/0x36 [] xfs_alloc_ag_vextent+0x113/0x115 [] xfs_alloc_vextent+0x2f0/0x391 [] xfs_bmap_alloc+0x847/0x131e [] dev_queue_xmit+0x209/0x296 [] ip_finish_output+0xb2/0x1b5 [] xfs_bmapi+0x26a/0x141b [] xfs_bmbt_get_state+0x2f/0x3b [] xfs_bmapi+0x519/0x141b [] _pagebuf_lookup_pages+0x17b/0x39b [] xfs_bmbt_get_state+0x2f/0x3b [] xfs_bmap_do_search_extents+0xb4/0x3ce [] pagebuf_get+0xd1/0x150 [] xfs_dir2_grow_inode+0xf2/0x485 [] xfs_dir2_leaf_to_node+0x30/0x17d [] xfs_da_read_buf+0x57/0x5b [] xfs_dir2_leaf_addname+0x271/0xabe [] xfs_bmap_last_offset+0xbe/0x115 [] xfs_dir2_isleaf+0x2e/0x6e [] xfs_dir2_createname+0x152/0x179 [] xfs_trans_ijoin+0x35/0x7f [] xfs_rename+0x395/0xb4b [] linvfs_rename+0x49/0x87 [] vfs_rename_other+0xa0/0xd5 [] vfs_rename+0x12f/0x358 [] sys_rename+0x1f1/0x220 [] do_IRQ+0x103/0x136 [] syscall_call+0x7/0xb XFS internal error XFS_WANT_CORRUPTED_RETURN at line 295 of file fs/xfs/xfs_alloc.c. Caller 0xc0181759 Call Trace: [] xfs_alloc_fixup_trees+0x1fe/0x34a [] xfs_alloc_ag_vextent_near+0x4aa/0xc61 [] xfs_alloc_ag_vextent_near+0x4aa/0xc61 [] xfs_alloc_ag_vextent+0x113/0x115 [] xfs_alloc_vextent+0x2f0/0x391 [] xfs_bmap_alloc+0x847/0x131e [] dev_queue_xmit+0x209/0x296 [] ip_finish_output+0xb2/0x1b5 [] xfs_bmapi+0x26a/0x141b [] xfs_bmbt_get_state+0x2f/0x3b [] xfs_bmapi+0x519/0x141b [] _pagebuf_lookup_pages+0x36d/0x39b [] xfs_bmbt_get_state+0x2f/0x3b [] xfs_bmap_do_search_extents+0xb4/0x3ce [] xfs_dir2_grow_inode+0xf2/0x485 [] xfs_dir2_leaf_to_node+0x30/0x17d [] xfs_da_read_buf+0x57/0x5b [] xfs_dir2_leaf_addname+0x271/0xabe [] xfs_bmap_last_offset+0xbe/0x115 [] xfs_dir2_isleaf+0x2e/0x6e [] xfs_dir2_createname+0x152/0x179 [] xfs_trans_ijoin+0x35/0x7f [] xfs_rename+0x395/0xb4b [] linvfs_rename+0x49/0x87 [] vfs_rename_other+0xa0/0xd5 [] vfs_rename+0x12f/0x358 [] sys_rename+0x1f1/0x220 [] vfs_read+0xc9/0x119 [] sys_read+0x42/0x63 [] syscall_call+0x7/0xb XFS internal error XFS_WANT_CORRUPTED_RETURN at line 295 of file fs/xfs/xfs_alloc.c. Caller 0xc0181759 Call Trace: [] xfs_alloc_fixup_trees+0x1fe/0x34a [] xfs_alloc_ag_vextent_near+0x4aa/0xc61 [] xfs_alloc_ag_vextent_near+0x4aa/0xc61 [] xfs_alloc_ag_vextent+0x113/0x115 [] xfs_alloc_vextent+0x2f0/0x391 [] xfs_bmap_alloc+0x847/0x131e [] dev_queue_xmit+0x209/0x296 [] ip_finish_output+0xb2/0x1b5 [] xfs_bmapi+0x26a/0x141b [] xfs_bmbt_get_state+0x2f/0x3b [] xfs_bmapi+0x519/0x141b [] _pagebuf_lookup_pages+0x36d/0x39b [] xfs_bmbt_get_state+0x2f/0x3b [] xfs_bmap_do_search_extents+0xb4/0x3ce [] xfs_dir2_grow_inode+0xf2/0x485 [] xfs_dir2_leaf_to_node+0x30/0x17d [] xfs_da_read_buf+0x57/0x5b [] xfs_dir2_leaf_addname+0x271/0xabe [] xfs_bmap_last_offset+0xbe/0x115 [] xfs_dir2_isleaf+0x2e/0x6e [] xfs_dir2_createname+0x152/0x179 [] xfs_trans_ijoin+0x35/0x7f [] xfs_rename+0x395/0xb4b [] run_timer_softirq+0xce/0x1ae [] linvfs_rename+0x49/0x87 [] vfs_rename_other+0xa0/0xd5 [] vfs_rename+0x12f/0x358 [] sys_rename+0x1f1/0x220 [] vfs_read+0xc9/0x119 [] sys_read+0x42/0x63 [] syscall_call+0x7/0xb XFS internal error XFS_WANT_CORRUPTED_RETURN at line 295 of file fs/xfs/xfs_alloc.c. Caller 0xc0181759 Call Trace: [] xfs_alloc_fixup_trees+0x1fe/0x34a [] xfs_alloc_ag_vextent_near+0x4aa/0xc61 [] xfs_alloc_ag_vextent_near+0x4aa/0xc61 [] xfs_alloc_ag_vextent+0x113/0x115 [] xfs_alloc_vextent+0x2f0/0x391 [] xfs_bmap_alloc+0x847/0x131e [] dev_queue_xmit+0x209/0x296 [] ip_finish_output+0xb2/0x1b5 [] xfs_bmapi+0x26a/0x141b [] xfs_bmbt_get_state+0x2f/0x3b [] xfs_bmapi+0x519/0x141b [] _pagebuf_lookup_pages+0x36d/0x39b [] xfs_bmbt_get_state+0x2f/0x3b [] xfs_bmap_do_search_extents+0xb4/0x3ce [] xfs_dir2_grow_inode+0xf2/0x485 [] xfs_dir2_leaf_to_node+0x30/0x17d [] xfs_da_read_buf+0x57/0x5b [] xfs_dir2_leaf_addname+0x271/0xabe [] xfs_bmap_last_offset+0xbe/0x115 [] xfs_dir2_isleaf+0x2e/0x6e [] xfs_dir2_createname+0x152/0x179 [] xfs_trans_ijoin+0x35/0x7f [] xfs_rename+0x395/0xb4b [] linvfs_rename+0x49/0x87 [] vfs_rename_other+0xa0/0xd5 [] vfs_rename+0x12f/0x358 [] sys_rename+0x1f1/0x220 [] vfs_read+0xc9/0x119 [] sys_read+0x42/0x63 [] syscall_call+0x7/0xb XFS internal error XFS_WANT_CORRUPTED_RETURN at line 295 of file fs/xfs/xfs_alloc.c. Caller 0xc0181759 Call Trace: [] xfs_alloc_fixup_trees+0x1fe/0x34a [] xfs_alloc_ag_vextent_near+0x4aa/0xc61 [] xfs_alloc_ag_vextent_near+0x4aa/0xc61 [] xfs_alloc_ag_vextent+0x113/0x115 [] xfs_alloc_vextent+0x2f0/0x391 [] xfs_bmap_alloc+0x847/0x131e [] dev_queue_xmit+0x209/0x296 [] ip_finish_output+0xb2/0x1b5 [] xfs_bmapi+0x26a/0x141b [] xfs_bmbt_get_state+0x2f/0x3b [] xfs_bmapi+0x519/0x141b [] _pagebuf_lookup_pages+0x36d/0x39b [] xfs_bmbt_get_state+0x2f/0x3b [] xfs_bmap_do_search_extents+0xb4/0x3ce [] xfs_dir2_grow_inode+0xf2/0x485 [] xfs_dir2_leaf_to_node+0x30/0x17d [] xfs_da_read_buf+0x57/0x5b [] xfs_dir2_leaf_addname+0x271/0xabe [] xfs_bmap_last_offset+0xbe/0x115 [] xfs_dir2_isleaf+0x2e/0x6e [] xfs_dir2_createname+0x152/0x179 [] xfs_trans_ijoin+0x35/0x7f [] xfs_rename+0x395/0xb4b [] linvfs_rename+0x49/0x87 [] vfs_rename_other+0xa0/0xd5 [] vfs_rename+0x12f/0x358 [] sys_rename+0x1f1/0x220 [] vfs_read+0xc9/0x119 [] sys_read+0x42/0x63 [] syscall_call+0x7/0xb XFS internal error XFS_WANT_CORRUPTED_RETURN at line 295 of file fs/xfs/xfs_alloc.c. Caller 0xc0181759 Call Trace: [] xfs_alloc_fixup_trees+0x1fe/0x34a [] xfs_alloc_ag_vextent_near+0x4aa/0xc61 [] xfs_alloc_ag_vextent_near+0x4aa/0xc61 [] xfs_alloc_ag_vextent+0x113/0x115 [] xfs_alloc_vextent+0x2f0/0x391 [] xfs_bmap_alloc+0x847/0x131e [] dev_queue_xmit+0x209/0x296 [] ip_finish_output+0xb2/0x1b5 [] xfs_bmapi+0x26a/0x141b [] xfs_bmbt_get_state+0x2f/0x3b [] xfs_bmapi+0x519/0x141b [] _pagebuf_lookup_pages+0x36d/0x39b [] xfs_bmbt_get_state+0x2f/0x3b [] xfs_bmap_do_search_extents+0xb4/0x3ce [] xfs_dir2_grow_inode+0xf2/0x485 [] xfs_dir2_leaf_to_node+0x30/0x17d [] xfs_da_read_buf+0x57/0x5b [] xfs_dir2_leaf_addname+0x271/0xabe [] xfs_bmap_last_offset+0xbe/0x115 [] xfs_dir2_isleaf+0x2e/0x6e [] xfs_dir2_createname+0x152/0x179 [] xfs_trans_ijoin+0x35/0x7f [] xfs_rename+0x395/0xb4b [] linvfs_rename+0x49/0x87 [] vfs_rename_other+0xa0/0xd5 [] vfs_rename+0x12f/0x358 [] sys_rename+0x1f1/0x220 [] vfs_read+0xc9/0x119 [] sys_read+0x42/0x63 [] syscall_call+0x7/0xb From owner-linux-xfs@oss.sgi.com Thu Apr 1 14:33:56 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 01 Apr 2004 14:33:57 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i31MXuKO030173 for ; Thu, 1 Apr 2004 14:33:56 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i31MXunD030172 for linux-xfs@oss.sgi.com; Thu, 1 Apr 2004 14:33:56 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i31MXsKQ030157 for ; Thu, 1 Apr 2004 14:33:54 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i31LfshB027409; Thu, 1 Apr 2004 13:41:54 -0800 Date: Thu, 1 Apr 2004 13:41:54 -0800 Message-Id: <200404012141.i31LfshB027409@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 311] ioctl hang in 2.6.x kernels with quota support X-Bugzilla-Reason: AssignedTo X-archive-position: 2684 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=311 ------- Additional Comments From cattelan@thebarn.com 2004-01-04 13:41 PDT ------- We really need some more info. gdb backtraces and or kdb backtraces. kbd in in the tree on oss so grab that tree and compile with kdb support. from kdb do a ps to find the process id and btp to get the backtrace or a particular process. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Apr 1 16:18:08 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 01 Apr 2004 16:18:15 -0800 (PST) Received: from dingdong.cryptoapps.com (postfix@uslink-66.173.43-133.uslink.net [66.173.43.133] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i320I7KO001034 for ; Thu, 1 Apr 2004 16:18:08 -0800 Received: by dingdong.cryptoapps.com (Postfix, from userid 1001) id DD934FB839; Thu, 1 Apr 2004 18:18:01 -0600 (CST) Date: Thu, 1 Apr 2004 16:18:01 -0800 From: Chris Wedgwood To: Dmitry Nikiforov Cc: linux-xfs@oss.sgi.com Subject: Re: file corruption Message-ID: <20040402001801.GA24900@dingdong.cryptoapps.com> References: <406AF7B6.6030405@dniq-online.com> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <406AF7B6.6030405@dniq-online.com> Content-Transfer-Encoding: 8bit X-archive-position: 2685 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Wed, Mar 31, 2004 at 10:54:14AM -0600, Dmitry Nikiforov wrote: > I currently am running kernel 2.6.3 on my system, and virtually > every time my system gets rebooted without shutdown (which happens > sometime), I get corrupted files. Define corrupted. > Most often I get just random garbage _within_ a file, even though > there are no complaints while checking filesystem. Random garbage? As someone else pointed out you can get nulls in files at times, but I wouldn't expect it to be that common or problematic --- it's also arguably the correct behavior. > virtually every time I get power failure or unconditional reboot for > whatever reason - I get corrupted files with random garbage inside. which files are these? > I'm reformatting my partitions to JFS later this week, but still > would like to know if there is a cure for this problem on XFS. Knowing which files this happens to and what the garbage is would help. Also knowing if it still happens with a kernel built from oss.sgi.com CVS with a known-good gcc is important. --cw From owner-linux-xfs@oss.sgi.com Thu Apr 1 16:22:54 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 01 Apr 2004 16:22:55 -0800 (PST) Received: from dingdong.cryptoapps.com (postfix@uslink-66.173.43-133.uslink.net [66.173.43.133] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i320MpKO006645 for ; Thu, 1 Apr 2004 16:22:54 -0800 Received: by dingdong.cryptoapps.com (Postfix, from userid 1001) id 1BF94FB839; Thu, 1 Apr 2004 18:22:47 -0600 (CST) Date: Thu, 1 Apr 2004 16:22:47 -0800 From: Chris Wedgwood To: Matteo Croce <3297627799@wind.it> Cc: linux-xfs@oss.sgi.com Subject: Re: XFS_WANT_CORRUPTED_RETURN Message-ID: <20040402002247.GB24900@dingdong.cryptoapps.com> References: <406C4916.3040806@wind.it> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <406C4916.3040806@wind.it> Content-Transfer-Encoding: 8bit X-archive-position: 2686 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Thu, Apr 01, 2004 at 06:53:42PM +0200, Matteo Croce wrote: > I'm using XFS on my root partition with linux (2.6.4 kernel). > The partition is 15976000k length and formatted with: > mkfs.xfs -f -bsize=512 -nsize=512 -lsize=65536s /dev/hda2 -bsize=512 makes me wonder if this is a problem with code paths that aren't used/tested often as I'm guessing few people use such a small block size. --cw From owner-linux-xfs@oss.sgi.com Thu Apr 1 16:52:48 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 01 Apr 2004 16:52:54 -0800 (PST) Received: from mail.dniq-online.com (dniq-online.com [209.172.191.129]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i320qlKO010924 for ; Thu, 1 Apr 2004 16:52:47 -0800 Received: from dniq-online.com (firewall.mc.net [209.172.181.98]) by mail.dniq-online.com (Postfix) with ESMTP id D33ED202201; Thu, 1 Apr 2004 18:52:43 -0600 (CST) Message-ID: <406CB95B.4040500@dniq-online.com> Date: Thu, 01 Apr 2004 18:52:43 -0600 From: Dmitry Nikiforov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040115 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Wedgwood Cc: Dmitry Nikiforov , linux-xfs@oss.sgi.com Subject: Re: file corruption References: <406AF7B6.6030405@dniq-online.com> <20040402001801.GA24900@dingdong.cryptoapps.com> In-Reply-To: <20040402001801.GA24900@dingdong.cryptoapps.com> Content-type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i320qmKO010926 X-archive-position: 2687 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dniq_kraft@dniq-online.com Precedence: bulk X-list: linux-xfs Chris Wedgwood wrote: >>I currently am running kernel 2.6.3 on my system, and virtually >>every time my system gets rebooted without shutdown (which happens >>sometime), I get corrupted files. >> >> > >Define corrupted. > > 'Corrupted' as in 'incorrect data in them'. Besides, a few files were lost (Mozilla bookmarks.html, for example, is one of them). >>Most often I get just random garbage _within_ a file, even though >>there are no complaints while checking filesystem. >> >> > >Random garbage? As someone else pointed out you can get nulls in >files at times, but I wouldn't expect it to be that common or >problematic --- it's also arguably the correct behavior. > > Well, it looks like a random garbage. Last time it happened to /var/log/messages - there was some random binary data at the end of it. At the same time, there were no error messages nor warnings when the system was being started and fsck was running, which I find very odd... >>virtually every time I get power failure or unconditional reboot for >>whatever reason - I get corrupted files with random garbage inside. >> >> > >which files are these? > > Open files, as far as I can tell right now. Some files I find just later that they were corrupted, so I can't tell what was happening to them at that very moment :( While I don't have too many crashes (about 4-5 in total so far) - it always involves something missing. On my office machine (which is 100% linux box with XFS all over it :) ) every time it gets unconditionally rebooted, I loose most of my KDE settings and most of Mozilla settings (these are that I can notice immediately after the reboot). And, like I said, there were a couple of times when there was some random garbage in /var/log/messages, for example: Mar 31 19:01:00 dniq CROND[23308]: (root) CMD (nice -n 19 run-parts /etc/cron.hourly) Mar 31 20:01:00 dniq CROND[23803]: (root) CMD (nice -n 19 run-parts /etc/cron.hourly) Mar 31 21:01:00 dniq CROND[24300]: (root) CMD (nice -n 19 run-parts /etc/cron.hourly) Mar 31 22:01:00 dniq CROND[24797]: (root) CMDL$|.?..?.??. ?.?#..?L$.??.?L$.??..$..A.?..$.L$|#A..?L$ ??.?L $$??..$...D$|A..$.H...$!?.???.???..@;\$t..$s.;t$(r..t&..?'....?D$0.D$4.T$,).$.L$x.?9L$0...???.?T[^_]??.....T$.)\$.?????©.....|$.)\$.?.????.....D$.)\$.?t???.v.UW1?VS.?. .L$(.|$..D$,.T$8.l$0.?.\R?.D$..T$4.D$4.??..R.?.?.??.?.?..T$..T$89T$.......?..$..?&....1?;t$4..?....l$..?.9?..?....T$4.???F.<..?..?.A.D$..?.A.?.A..C..C.?T$...C;t$4......9?.......?t2.?.FA.D$..?.A.?.A..C..C.?T$...C;t$4s]9?sY.?.?'.....?.FA.D $..?.A.?.A..C..C.?T$...C9?s-.?.FA.D$..?.A.?.A..C..C.?T$...C;t$4s.9?r?.t&.?D$..4$.T$..D$8)?.?9D$....???.?.[^_]?.t&..?'....UWVS.?P.t$d.D$h.T$t.L$l.?.TR?.D$4.D$p.??.D$x.. .?..$.?u.?...?.?..?..T$x.R..?.T$.u..L$x?.?...D$.?A..?...D$x.@..?.D$.u..T$x??....D$.?B.?....?.??????t@1??.u8??B?.u1??B?.u*??B?.u#??B?.u.??B?.u.??B?.u.??B?.u.??B?.t?.?.l $L.?.???1?1?.D$.??..?t$.?...?.............??C??.t.....?.~?.?........D+?.D$ (this is just a simulation, not the actual file fragment). -- Regards, DNiq. From owner-linux-xfs@oss.sgi.com Thu Apr 1 17:16:23 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 01 Apr 2004 17:16:28 -0800 (PST) Received: from dingdong.cryptoapps.com (postfix@uslink-66.173.43-133.uslink.net [66.173.43.133] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i321GNKO012317 for ; Thu, 1 Apr 2004 17:16:23 -0800 Received: by dingdong.cryptoapps.com (Postfix, from userid 1001) id 87E5AFB839; Thu, 1 Apr 2004 19:16:18 -0600 (CST) Date: Thu, 1 Apr 2004 17:16:18 -0800 From: Chris Wedgwood To: Dmitry Nikiforov Cc: linux-xfs@oss.sgi.com Subject: Re: file corruption Message-ID: <20040402011618.GA25511@dingdong.cryptoapps.com> References: <406AF7B6.6030405@dniq-online.com> <20040402001801.GA24900@dingdong.cryptoapps.com> <406CB95B.4040500@dniq-online.com> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <406CB95B.4040500@dniq-online.com> Content-Transfer-Encoding: 8bit X-archive-position: 2688 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Thu, Apr 01, 2004 at 06:52:43PM -0600, Dmitry Nikiforov wrote: > 'Corrupted' as in 'incorrect data in them'. Besides, a few files > were lost (Mozilla bookmarks.html, for example, is one of them). Incorrect data can/will happen for some files. XFS journals metadata not data so this is expected unless applications take sufficient care (MTAs like postfix a good example of applications which do the right thing). But _what_ incorrect data are we talking about? > Well, it looks like a random garbage. Last time it happened to > /var/log/messages - there was some random binary data at the end of > it. That shouldn't happen (nulls might though). Can you reproduce this? > At the same time, there were no error messages nor warnings when the > system was being started and fsck was running, which I find very > odd... I don't see why there should be.... journal replay and fsck have no way of knowing what files should look like. They don't look at file contents. > Open files, as far as I can tell right now. Such as? You mentioned log files, what else? > Some files I find just later that they were corrupted, so I can't > tell what was happening to them at that very moment :( It would be good to know what these files are and when they were last used relative to the crash. > While I don't have too many crashes (about 4-5 in total so far) - it > always involves something missing. What causes these crashes? > On my office machine (which is 100% linux box with XFS all over it > :) ) every time it gets unconditionally rebooted, I loose most of my > KDE settings and most of Mozilla settings (these are that I can > notice immediately after the reboot). I've seen this (I use KDE here). As best as I can tell it's KDE and Mozilla making dumb assumptions. I'm not sure I blame them but they aren't exactly careful about their configuration files either which bugs me a little. There might going on here than is apparent so it's possible there is a filesystem bug, but I've not been able to reproduce something I can blame XFS when it comes to KDE configuration files. I'll try again later. > And, like I said, there were a couple of times when there was some > random garbage in /var/log/messages, for example: [...] > Mar 31 22:01:00 dniq CROND[24797]: (root) CMDL$|.?..?.??. [... non-NULL cruft deleted ...] Is that common and/or reproducible? That doesn't seem right. --cw From owner-linux-xfs@oss.sgi.com Thu Apr 1 17:42:50 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 01 Apr 2004 17:42:52 -0800 (PST) Received: from mail.dniq-online.com (dniq-online.com [209.172.191.129]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i321goKO013517 for ; Thu, 1 Apr 2004 17:42:50 -0800 Received: from dniq-online.com (firewall.mc.net [209.172.181.98]) by mail.dniq-online.com (Postfix) with ESMTP id 8BFB8202201; Thu, 1 Apr 2004 19:42:49 -0600 (CST) Message-ID: <406CC518.1090204@dniq-online.com> Date: Thu, 01 Apr 2004 19:42:48 -0600 From: Dmitry Nikiforov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040115 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Wedgwood Cc: Dmitry Nikiforov , linux-xfs@oss.sgi.com Subject: Re: file corruption References: <406AF7B6.6030405@dniq-online.com> <20040402001801.GA24900@dingdong.cryptoapps.com> <406CB95B.4040500@dniq-online.com> <20040402011618.GA25511@dingdong.cryptoapps.com> In-Reply-To: <20040402011618.GA25511@dingdong.cryptoapps.com> Content-type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-archive-position: 2689 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dniq_kraft@dniq-online.com Precedence: bulk X-list: linux-xfs Chris Wedgwood wrote: >Incorrect data can/will happen for some files. XFS journals metadata >not data so this is expected unless applications take sufficient care >(MTAs like postfix a good example of applications which do the right >thing). > > So technically the whole purpose of this is to provide faster startup time after crash and not the consistency of data, correct? >>Well, it looks like a random garbage. Last time it happened to >>/var/log/messages - there was some random binary data at the end of >>it. >> >> > >That shouldn't happen (nulls might though). Can you reproduce this? > > I'll try to experiment a little bit... >Such as? You mentioned log files, what else? > > I can't tell you right now, since I have never paid too much attention to this (it just wasn't too critical to me). The reason I've sent my original message was that I've just lost all my KDE settings and Mozilla settings (all bookmarks, all e-mail accounts and all cookies). In case of Mozilla and its e-mail accounts - subdirectories and files were there, but Mozilla didn't have the mailbox configuration, so I've had to create it again and then copy the mailbox data files over the newly created ones. >It would be good to know what these files are and when they were last >used relative to the crash. > > As far as I can tell, they were being used at the moment of crash. >>While I don't have too many crashes (about 4-5 in total so far) - it >>always involves something missing. >> >> > >What causes these crashes? > > Power outage, or me being impatient when I need to restart my system (never caused any problems while I was using EXT3). >I've seen this (I use KDE here). As best as I can tell it's KDE and >Mozilla making dumb assumptions. > Unfortunately I didn't get a chance to look at what was in its config files after the crash... :( >>And, like I said, there were a couple of times when there was some >>random garbage in /var/log/messages, for example: >> >> > >[...] > > > >>Mar 31 22:01:00 dniq CROND[24797]: (root) CMDL$|.?..?.??. >> >> > >[... non-NULL cruft deleted ...] > >Is that common and/or reproducible? That doesn't seem right. > > Well. I didn't try to get this problem specifically, but I've had at least two occasions when I've had such situation. I'll try this weekend and see if this is something I can reproduce intentionally :) -- Regards, DNiq. From owner-linux-xfs@oss.sgi.com Thu Apr 1 17:50:24 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 01 Apr 2004 17:50:25 -0800 (PST) Received: from dingdong.cryptoapps.com (postfix@uslink-66.173.43-133.uslink.net [66.173.43.133] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i321oNKO014098 for ; Thu, 1 Apr 2004 17:50:23 -0800 Received: by dingdong.cryptoapps.com (Postfix, from userid 1001) id DC8C9FB839; Thu, 1 Apr 2004 19:50:22 -0600 (CST) Date: Thu, 1 Apr 2004 17:50:22 -0800 From: Chris Wedgwood To: Dmitry Nikiforov Cc: linux-xfs@oss.sgi.com Subject: Re: file corruption Message-ID: <20040402015022.GA25936@dingdong.cryptoapps.com> References: <406AF7B6.6030405@dniq-online.com> <20040402001801.GA24900@dingdong.cryptoapps.com> <406CB95B.4040500@dniq-online.com> <20040402011618.GA25511@dingdong.cryptoapps.com> <406CC518.1090204@dniq-online.com> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <406CC518.1090204@dniq-online.com> Content-Transfer-Encoding: 8bit X-archive-position: 2690 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Thu, Apr 01, 2004 at 07:42:48PM -0600, Dmitry Nikiforov wrote: > So technically the whole purpose of this is to provide faster > startup time after crash and not the consistency of data, correct? yes some fs' will journal all data though (reiserfs and ext3 can do this), but it often comes at a significant performance penalty for no real gain (and sometimes causes other problems like seeing old/stale data) > In case of Mozilla and its e-mail accounts - subdirectories and > files were there, but Mozilla didn't have the mailbox configuration, > so I've had to create it again and then copy the mailbox data files > over the newly created ones. i have seen this... usually it's configuration files being written to often, the metadat is logged but the datablocks aren't flushed. after a reboot you get nulls and mozilla either pukes or ignores the configuration (which is sensible) mozilla could be a little better about this for critical files IMO > As far as I can tell, they were being used at the moment of crash. if they were being written to then i would expect nulls, but not random data > Power outage, or me being impatient when I need to restart my system > (never caused any problems while I was using EXT3). "sync + reboot/poweroff" should be pretty safe (even if not recommended) --- fwiw i do it all the time and never have problems From owner-linux-xfs@oss.sgi.com Thu Apr 1 18:26:12 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 01 Apr 2004 18:26:17 -0800 (PST) Received: from ns1.tippett.com (user-112vvgq.biz.mindspring.com [66.47.254.26]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i322Q8KO015456 for ; Thu, 1 Apr 2004 18:26:10 -0800 Received: from hermes.tippett.com (hermes-e.tippett.com [192.168.3.20]) by ns1.tippett.com (8.12.8/8.12.8) with ESMTP id i3227MGN018845; Thu, 1 Apr 2004 18:07:22 -0800 Received: from tippett.com (gangsta.tippett.com [192.168.3.62]) by hermes.tippett.com (980427.SGI.8.8.8/8.7.3) with ESMTP id SAA93405; Thu, 1 Apr 2004 18:25:15 -0800 (PST) Message-ID: <406CCF08.9020309@tippett.com> Date: Thu, 01 Apr 2004 18:25:12 -0800 From: Christian Rice Organization: Tippett Studio User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Wedgwood CC: Dmitry Nikiforov , linux-xfs@oss.sgi.com Subject: Re: file corruption References: <406AF7B6.6030405@dniq-online.com> <20040402001801.GA24900@dingdong.cryptoapps.com> <406CB95B.4040500@dniq-online.com> <20040402011618.GA25511@dingdong.cryptoapps.com> <406CC518.1090204@dniq-online.com> <20040402015022.GA25936@dingdong.cryptoapps.com> In-Reply-To: <20040402015022.GA25936@dingdong.cryptoapps.com> Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.39 X-archive-position: 2691 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: xian@tippett.com Precedence: bulk X-list: linux-xfs Has anyone mentioned turning off write caching? hdparm -W 0 /dev/hda This for me made the difference between rebuilding up to five system disks per day (out of one hundred desktop workstations, and that was a couple years ago), and rebuilding...none per day. Users unplug and reset workstations without a second thought. Having data on the drive not flushed is a killer. Chris Wedgwood wrote: > On Thu, Apr 01, 2004 at 07:42:48PM -0600, Dmitry Nikiforov wrote: > > >>So technically the whole purpose of this is to provide faster >>startup time after crash and not the consistency of data, correct? > > > yes > > some fs' will journal all data though (reiserfs and ext3 can do this), > but it often comes at a significant performance penalty for no real > gain (and sometimes causes other problems like seeing old/stale data) > > >>In case of Mozilla and its e-mail accounts - subdirectories and >>files were there, but Mozilla didn't have the mailbox configuration, >>so I've had to create it again and then copy the mailbox data files >>over the newly created ones. > > > i have seen this... usually it's configuration files being written to > often, the metadat is logged but the datablocks aren't flushed. after > a reboot you get nulls and mozilla either pukes or ignores the > configuration (which is sensible) > > mozilla could be a little better about this for critical files IMO > > >>As far as I can tell, they were being used at the moment of crash. > > > if they were being written to then i would expect nulls, but not > random data > > >>Power outage, or me being impatient when I need to restart my system >>(never caused any problems while I was using EXT3). > > > "sync + reboot/poweroff" should be pretty safe (even if not > recommended) --- fwiw i do it all the time and never have problems > > > > > > From owner-linux-xfs@oss.sgi.com Thu Apr 1 19:48:36 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 01 Apr 2004 19:48:38 -0800 (PST) Received: from mail.dniq-online.com (dniq-online.com [209.172.191.129]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i323mQKO020764 for ; Thu, 1 Apr 2004 19:48:26 -0800 Received: from dniq-online.com (node-423a14b2.mdw.onnet.us.uu.net [66.58.20.178]) by mail.dniq-online.com (Postfix) with ESMTP id 2A6AE202201; Thu, 1 Apr 2004 21:05:51 -0600 (CST) Message-ID: <406CD88F.3070900@dniq-online.com> Date: Thu, 01 Apr 2004 21:05:51 -0600 From: Dmitry Nikiforov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Rice Cc: Chris Wedgwood , Dmitry Nikiforov , linux-xfs@oss.sgi.com Subject: Re: file corruption References: <406AF7B6.6030405@dniq-online.com> <20040402001801.GA24900@dingdong.cryptoapps.com> <406CB95B.4040500@dniq-online.com> <20040402011618.GA25511@dingdong.cryptoapps.com> <406CC518.1090204@dniq-online.com> <20040402015022.GA25936@dingdong.cryptoapps.com> <406CCF08.9020309@tippett.com> In-Reply-To: <406CCF08.9020309@tippett.com> Content-type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-archive-position: 2692 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dniq@dniq-online.com Precedence: bulk X-list: linux-xfs Christian Rice wrote: > Has anyone mentioned turning off write caching? > > hdparm -W 0 /dev/hda > > > This for me made the difference between rebuilding up to five system > disks per day (out of one hundred desktop workstations, and that was a > couple years ago), and rebuilding...none per day. > > Users unplug and reset workstations without a second thought. Having > data on the drive not flushed is a killer. Then there's no point in using XFS at all, is there? :) -- Regards, DNiq. From owner-linux-xfs@oss.sgi.com Thu Apr 1 20:39:24 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 01 Apr 2004 20:39:47 -0800 (PST) Received: from iris.acsalaska.net (iris.acsalaska.net [209.112.155.43]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i324dOKO025594 for ; Thu, 1 Apr 2004 20:39:24 -0800 Received: from erbenson.alaska.net (65-pm18.nwc.acsalaska.net [209.112.142.65]) by iris.acsalaska.net (8.12.11/8.12.10) with ESMTP id i324dL79038746 for ; Thu, 1 Apr 2004 19:39:22 -0900 (AKST) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id A430239E3 for ; Thu, 1 Apr 2004 19:39:20 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id 97C1840FF35; Thu, 1 Apr 2004 19:39:20 -0900 (AKST) Date: Thu, 1 Apr 2004 19:39:20 -0900 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: file corruption Message-ID: <20040402043920.GF21226@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <406AF7B6.6030405@dniq-online.com> <20040402001801.GA24900@dingdong.cryptoapps.com> <406CB95B.4040500@dniq-online.com> Mime-Version: 1.0 Content-type: text/plain Content-Disposition: inline In-Reply-To: <406CB95B.4040500@dniq-online.com> User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-ACS-Spam-Status: no X-ACS-Scanned-By: MD 2.37; SA 2.63; spamdefang 1.93 Content-Transfer-Encoding: 8bit X-archive-position: 2693 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs On Thu, Apr 01, 2004 at 06:52:43PM -0600, Dmitry Nikiforov wrote: > > > Well, it looks like a random garbage. Last time it happened to > /var/log/messages - there was some random binary data at the end of it. > At the same time, there were no error messages nor warnings when the > system was being started and fsck was running, which I find very odd... I have seen this a few times as well, except the binary crap is usually PREpended rather then appended to the file, also the end of the file is usually cut off, as if the start and end markers were equally offset backwards. (the start of the file moved back 5 or 10 bytes, and the end of the file moved back 5 or 10 bytes, thus causing truncation and random crud being prepended). in my case however this has always occured after doing a filesystem to filesystem copy via cpio, and then rebooting (cleanly). i cannot quite reproduce it consistently though, except that it ONLY occurs in /var/log, and is usually confined to the archived gzipped logs (but many of the active log files get this as well). for unclean reboots i have seen this on some open log files too, but again not consistently. -- Ethan Benson http://www.alaska.net/~erbenson/ -- Attached file included as plaintext by Ecartis -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iEYEARECAAYFAkBs7ngACgkQJKx7GixEevyFPQCcCQchMfzHGNlB4ki2MmIvtZlC hFkAnjGH4cEJpBhTiiwRwUXE7QAoB/P9 =gDlu -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Thu Apr 1 20:44:57 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 01 Apr 2004 20:44:59 -0800 (PST) Received: from dingdong.cryptoapps.com (postfix@uslink-66.173.43-133.uslink.net [66.173.43.133] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i324ivKO026099 for ; Thu, 1 Apr 2004 20:44:57 -0800 Received: by dingdong.cryptoapps.com (Postfix, from userid 1001) id 945CDFBA3C; Thu, 1 Apr 2004 22:44:56 -0600 (CST) Date: Thu, 1 Apr 2004 20:44:56 -0800 From: Chris Wedgwood To: Christian Rice Cc: Dmitry Nikiforov , linux-xfs@oss.sgi.com Subject: Re: file corruption Message-ID: <20040402044456.GA27240@dingdong.cryptoapps.com> References: <406AF7B6.6030405@dniq-online.com> <20040402001801.GA24900@dingdong.cryptoapps.com> <406CB95B.4040500@dniq-online.com> <20040402011618.GA25511@dingdong.cryptoapps.com> <406CC518.1090204@dniq-online.com> <20040402015022.GA25936@dingdong.cryptoapps.com> <406CCF08.9020309@tippett.com> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <406CCF08.9020309@tippett.com> Content-Transfer-Encoding: 8bit X-archive-position: 2694 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Thu, Apr 01, 2004 at 06:25:12PM -0800, Christian Rice wrote: > Has anyone mentioned turning off write caching? > > hdparm -W 0 /dev/hda Actually, this is a good point, until XFS gets some write-barrier support this is probably a good idea. > This for me made the difference between rebuilding up to five system > disks per day (out of one hundred desktop workstations, and that was > a couple years ago), and rebuilding...none per day. Newer drives with 8MB caches are worse... you can get quite a bit of data reordered and/or lost. I'm not sure if TCQ makes this worse or not, I suspect it probably does. Turning off write-caching hurts a little in performance with once there is write-barrier support write-caching can be reenabled. --cw From owner-linux-xfs@oss.sgi.com Thu Apr 1 20:47:13 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 01 Apr 2004 20:47:15 -0800 (PST) Received: from dingdong.cryptoapps.com (postfix@uslink-66.173.43-133.uslink.net [66.173.43.133] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i324lDKO026518 for ; Thu, 1 Apr 2004 20:47:13 -0800 Received: by dingdong.cryptoapps.com (Postfix, from userid 1001) id 7B2DBFBA3C; Thu, 1 Apr 2004 22:47:12 -0600 (CST) Date: Thu, 1 Apr 2004 20:47:12 -0800 From: Chris Wedgwood To: Dmitry Nikiforov Cc: Christian Rice , Dmitry Nikiforov , linux-xfs@oss.sgi.com Subject: Re: file corruption Message-ID: <20040402044712.GB27240@dingdong.cryptoapps.com> References: <406AF7B6.6030405@dniq-online.com> <20040402001801.GA24900@dingdong.cryptoapps.com> <406CB95B.4040500@dniq-online.com> <20040402011618.GA25511@dingdong.cryptoapps.com> <406CC518.1090204@dniq-online.com> <20040402015022.GA25936@dingdong.cryptoapps.com> <406CCF08.9020309@tippett.com> <406CD88F.3070900@dniq-online.com> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <406CD88F.3070900@dniq-online.com> Content-Transfer-Encoding: 8bit X-archive-position: 2695 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Thu, Apr 01, 2004 at 09:05:51PM -0600, Dmitry Nikiforov wrote: > Then there's no point in using XFS at all, is there? :) This has nothing to do with XFS. All filesystems journalling and otherwise are affected by this. --cw From owner-linux-xfs@oss.sgi.com Thu Apr 1 20:48:29 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 01 Apr 2004 20:48:30 -0800 (PST) Received: from dingdong.cryptoapps.com (postfix@uslink-66.173.43-133.uslink.net [66.173.43.133] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i324mSKO026925 for ; Thu, 1 Apr 2004 20:48:28 -0800 Received: by dingdong.cryptoapps.com (Postfix, from userid 1001) id DA37BFBA3C; Thu, 1 Apr 2004 22:48:27 -0600 (CST) Date: Thu, 1 Apr 2004 20:48:27 -0800 From: Chris Wedgwood To: linux-xfs@oss.sgi.com Subject: Re: file corruption Message-ID: <20040402044827.GC27240@dingdong.cryptoapps.com> References: <406AF7B6.6030405@dniq-online.com> <20040402001801.GA24900@dingdong.cryptoapps.com> <406CB95B.4040500@dniq-online.com> <20040402043920.GF21226@plato.local.lan> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040402043920.GF21226@plato.local.lan> Content-Transfer-Encoding: 8bit X-archive-position: 2696 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Thu, Apr 01, 2004 at 07:39:20PM -0900, Ethan Benson wrote: > I have seen this a few times as well, except the binary crap is > usually PREpended rather then appended to the file, also the end of > the file is usually cut off, as if the start and end markers were > equally offset backwards. (the start of the file moved back 5 or 10 > bytes, and the end of the file moved back 5 or 10 bytes, thus causing > truncation and random crud being prepended). How much data are we talking about here? For > blocksize this seems impssible. --cw From owner-linux-xfs@oss.sgi.com Thu Apr 1 21:03:07 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 01 Apr 2004 21:03:12 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.sgi.com [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i32536KO027709 for ; Thu, 1 Apr 2004 21:03:06 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i324v2f0022284 for ; Thu, 1 Apr 2004 22:57:03 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i324uwAL35555281 for ; Fri, 2 Apr 2004 14:56:59 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i324uwUx35476193 for linux-xfs@oss.sgi.com; Fri, 2 Apr 2004 14:56:58 +1000 (EST) Date: Fri, 2 Apr 2004 14:56:58 +1000 (EST) From: Nathan Scott Message-Id: <200404020456.i324uwUx35476193@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 909055 - make 2.4/2.6 pb ioerror same X-archive-position: 2697 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Make buffer error checking consistent, add a value range check. Date: Thu Apr 1 20:53:37 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-linux Inspected by: cattelan@sgi.com,hch@lst.de The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:169542a linux-2.6/xfs_buf.h - 1.95 linux-2.6/xfs_buf.c - 1.162 linux-2.4/xfs_buf.c - 1.183 From owner-linux-xfs@oss.sgi.com Thu Apr 1 22:40:37 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 01 Apr 2004 22:40:46 -0800 (PST) Received: from mail.dniq-online.com (dniq-online.com [209.172.191.129]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i326eaKO030777 for ; Thu, 1 Apr 2004 22:40:36 -0800 Received: from dniq-online.com (node-423a14b2.mdw.onnet.us.uu.net [66.58.20.178]) by mail.dniq-online.com (Postfix) with ESMTP id 12945202201; Fri, 2 Apr 2004 00:40:36 -0600 (CST) Message-ID: <406D0AE4.2030203@dniq-online.com> Date: Fri, 02 Apr 2004 00:40:36 -0600 From: Dmitry Nikiforov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Wedgwood Cc: Christian Rice , Dmitry Nikiforov , linux-xfs@oss.sgi.com Subject: Re: file corruption References: <406AF7B6.6030405@dniq-online.com> <20040402001801.GA24900@dingdong.cryptoapps.com> <406CB95B.4040500@dniq-online.com> <20040402011618.GA25511@dingdong.cryptoapps.com> <406CC518.1090204@dniq-online.com> <20040402015022.GA25936@dingdong.cryptoapps.com> <406CCF08.9020309@tippett.com> <406CD88F.3070900@dniq-online.com> <20040402044712.GB27240@dingdong.cryptoapps.com> In-Reply-To: <20040402044712.GB27240@dingdong.cryptoapps.com> Content-type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-archive-position: 2698 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dniq@dniq-online.com Precedence: bulk X-list: linux-xfs Chris Wedgwood wrote: >>Then there's no point in using XFS at all, is there? :) >> >> > >This has nothing to do with XFS. All filesystems journalling and >otherwise are affected by this. > > Agree, but different filesystems are affected to a different degree. So far I've not had any data lost with, say, ext3, however its performance is pretty poor. For now, I've reformatted all partitions on my workstation with ReiserFS and will see what's going to happen if the system crashes :) It appears that XFS does not guarantee the data consistency, and even worse than that: it will never tell you that some files are broken. I'd rather have a longer fsck which tells me which files are broken, even if it can't fix them. Thanks for clarification, though! :) At least now I know _why_ XFS shouldn't be used on a production server :) -- Regards, DNiq. From owner-linux-xfs@oss.sgi.com Thu Apr 1 23:13:54 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 01 Apr 2004 23:13:58 -0800 (PST) Received: from hob.acsalaska.net (hob.acsalaska.net [209.112.155.42]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i327DrKO032711 for ; Thu, 1 Apr 2004 23:13:54 -0800 Received: from erbenson.alaska.net (65-pm18.nwc.acsalaska.net [209.112.142.65]) by hob.acsalaska.net (8.12.11/8.12.11) with ESMTP id i327Doiq018836 for ; Thu, 1 Apr 2004 22:13:51 -0900 (AKST) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id E5ACE39E3 for ; Thu, 1 Apr 2004 22:13:49 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id 8FDBE40FF35; Thu, 1 Apr 2004 22:13:49 -0900 (AKST) Date: Thu, 1 Apr 2004 22:13:49 -0900 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: file corruption Message-ID: <20040402071349.GH21226@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <406AF7B6.6030405@dniq-online.com> <20040402001801.GA24900@dingdong.cryptoapps.com> <406CB95B.4040500@dniq-online.com> <20040402043920.GF21226@plato.local.lan> <20040402044827.GC27240@dingdong.cryptoapps.com> Mime-Version: 1.0 Content-type: text/plain Content-Disposition: inline In-Reply-To: <20040402044827.GC27240@dingdong.cryptoapps.com> User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-ACS-Spam-Status: no X-ACS-Scanned-By: MD 2.37; SA 2.63; spamdefang 1.93 Content-Transfer-Encoding: 8bit X-archive-position: 2699 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs On Thu, Apr 01, 2004 at 08:48:27PM -0800, Chris Wedgwood wrote: > On Thu, Apr 01, 2004 at 07:39:20PM -0900, Ethan Benson wrote: > > > I have seen this a few times as well, except the binary crap is > > usually PREpended rather then appended to the file, also the end of > > the file is usually cut off, as if the start and end markers were > > equally offset backwards. (the start of the file moved back 5 or 10 > > bytes, and the end of the file moved back 5 or 10 bytes, thus causing > > truncation and random crud being prepended). > > How much data are we talking about here? For > blocksize this seems > impssible. no more then 5 - 15 bytes or so. its definitly quite strange, i couldn't really make any guess as to what would cause it. but its definitly possible since ive seen it happen several times on multiple files, each file affected in a consistent way. what i find most peculiar is how it consistently affected /var/log/foo.gz.{1,2} but not {3,4} (or maybe it was {2,3} and {3,4} i don't recall now). however no other .gz file anywhere else in the filesystem was corrupted in this manner. -- Ethan Benson http://www.alaska.net/~erbenson/ -- Attached file included as plaintext by Ecartis -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iEYEARECAAYFAkBtEq0ACgkQJKx7GixEevyeEQCfQBQiuEDe/recha0s8LOyUcYc tIoAn1QAfeTiQTH071eKby4edCcsvtS7 =36sD -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Fri Apr 2 00:33:58 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 02 Apr 2004 00:34:02 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i328XwKO007640 for ; Fri, 2 Apr 2004 00:33:58 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i328XwVg007639 for linux-xfs@oss.sgi.com; Fri, 2 Apr 2004 00:33:58 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i328XuKQ007624 for ; Fri, 2 Apr 2004 00:33:57 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i327jjFg003213; Thu, 1 Apr 2004 23:45:45 -0800 Date: Thu, 1 Apr 2004 23:45:45 -0800 Message-Id: <200404020745.i327jjFg003213@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 311] ioctl hang in 2.6.x kernels with quota support X-Bugzilla-Reason: AssignedTo X-archive-position: 2700 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=311 ------- Additional Comments From steven.wilton@team.eftel.com 2004-01-04 23:45 PDT ------- OK, unfortunately the debug messages only show up on the console, and I can't have the server offline for long enough to copy the complete backtrace. The backtrace of the hung process has the following command sequence: io_schedule __lock_page find_lock_page _find_or_create_page _pagebuf_lookup_pages pagebuf_get No surprises here, the hung process is trying to lock a page, failing and calling the scheduler. Possibly related to this is the error message that I get in the kernel log (pagebuf_get: warning, failed to lookup pages). This error only occurs in the pagebuf_get() function (fs/xfs/linux/xfs_buf.c). I added some more printk statements, and discovered that the source of this error is a ENOMEM, returned from the _pagebuf_lookup_pages() function (fs/xfs/linux/xfs_buf.c). The reason that ENOMEM is returned from _pagebuf_lookup_pages() is because find_or_create_page() (in mm/filemap.c) returns NULL (line 12 of the function - explicit return NULL). This occurs because alloc_pages returns NULL 2 lines above. I can't see why this would leave a stale lock, but I am looking through the code to see if I can see anything else. Can I do anything else? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Fri Apr 2 00:50:22 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 02 Apr 2004 00:50:24 -0800 (PST) Received: from dingdong.cryptoapps.com (postfix@uslink-66.173.43-133.uslink.net [66.173.43.133] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i328oLKO008501 for ; Fri, 2 Apr 2004 00:50:21 -0800 Received: by dingdong.cryptoapps.com (Postfix, from userid 1001) id D5E96FB839; Fri, 2 Apr 2004 02:50:20 -0600 (CST) Date: Fri, 2 Apr 2004 00:50:20 -0800 From: Chris Wedgwood To: linux-xfs@oss.sgi.com Subject: Re: file corruption Message-ID: <20040402085020.GA28623@dingdong.cryptoapps.com> References: <406AF7B6.6030405@dniq-online.com> <20040402001801.GA24900@dingdong.cryptoapps.com> <406CB95B.4040500@dniq-online.com> <20040402043920.GF21226@plato.local.lan> <20040402044827.GC27240@dingdong.cryptoapps.com> <20040402071349.GH21226@plato.local.lan> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040402071349.GH21226@plato.local.lan> Content-Transfer-Encoding: 8bit X-archive-position: 2701 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Thu, Apr 01, 2004 at 10:13:49PM -0900, Ethan Benson wrote: > no more then 5 - 15 bytes or so. Sorry, I meant how large are the files ... not by how much are they shifted. > what i find most peculiar is how it consistently affected > /var/log/foo.gz.{1,2} but not {3,4} (or maybe it was {2,3} and {3,4} > i don't recall now). How can you tell if a compressed file is shifted 5-15 bytes? Casual inspection will fail to decompress the data I would expect. > however no other .gz file anywhere else in the filesystem was > corrupted in this manner. How recently had the logs been rotated before the unclean shutdown occurred? From owner-linux-xfs@oss.sgi.com Fri Apr 2 00:53:09 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 02 Apr 2004 00:53:11 -0800 (PST) Received: from dingdong.cryptoapps.com (postfix@uslink-66.173.43-133.uslink.net [66.173.43.133] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i328r9KO008914 for ; Fri, 2 Apr 2004 00:53:09 -0800 Received: by dingdong.cryptoapps.com (Postfix, from userid 1001) id AF67BFB839; Fri, 2 Apr 2004 02:53:08 -0600 (CST) Date: Fri, 2 Apr 2004 00:53:08 -0800 From: Chris Wedgwood To: Dmitry Nikiforov Cc: Christian Rice , Dmitry Nikiforov , linux-xfs@oss.sgi.com Subject: Re: file corruption Message-ID: <20040402085308.GB28623@dingdong.cryptoapps.com> References: <406AF7B6.6030405@dniq-online.com> <20040402001801.GA24900@dingdong.cryptoapps.com> <406CB95B.4040500@dniq-online.com> <20040402011618.GA25511@dingdong.cryptoapps.com> <406CC518.1090204@dniq-online.com> <20040402015022.GA25936@dingdong.cryptoapps.com> <406CCF08.9020309@tippett.com> <406CD88F.3070900@dniq-online.com> <20040402044712.GB27240@dingdong.cryptoapps.com> <406D0AE4.2030203@dniq-online.com> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <406D0AE4.2030203@dniq-online.com> Content-Transfer-Encoding: 8bit X-archive-position: 2702 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Fri, Apr 02, 2004 at 12:40:36AM -0600, Dmitry Nikiforov wrote: > It appears that XFS does not guarantee the data consistency, and > even worse than that: it will never tell you that some files are > broken. I'd rather have a longer fsck which tells me which files are > broken, even if it can't fix them. ext2 sounds like a good solution then. > Thanks for clarification, though! :) At least now I know _why_ XFS > shouldn't be used on a production server :) You're most welcome. Best of luck with reiserfs. --cw From owner-linux-xfs@oss.sgi.com Fri Apr 2 01:29:26 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 02 Apr 2004 01:29:34 -0800 (PST) Received: from hermod.acsalaska.net (hermod.acsalaska.net [209.112.155.45]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i329T6KO010733 for ; Fri, 2 Apr 2004 01:29:26 -0800 Received: from erbenson.alaska.net (65-pm18.nwc.acsalaska.net [209.112.142.65]) by hermod.acsalaska.net (8.12.11/8.12.11) with ESMTP id i329T4ma033904 for ; Fri, 2 Apr 2004 00:29:05 -0900 (AKST) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 03D1B39E3 for ; Fri, 2 Apr 2004 00:28:57 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id 4675740FF35; Fri, 2 Apr 2004 00:28:57 -0900 (AKST) Date: Fri, 2 Apr 2004 00:28:57 -0900 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: file corruption Message-ID: <20040402092857.GJ21226@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20040402001801.GA24900@dingdong.cryptoapps.com> <406CB95B.4040500@dniq-online.com> <20040402011618.GA25511@dingdong.cryptoapps.com> <406CC518.1090204@dniq-online.com> <20040402015022.GA25936@dingdong.cryptoapps.com> <406CCF08.9020309@tippett.com> <406CD88F.3070900@dniq-online.com> <20040402044712.GB27240@dingdong.cryptoapps.com> <406D0AE4.2030203@dniq-online.com> <20040402085308.GB28623@dingdong.cryptoapps.com> Mime-Version: 1.0 Content-type: text/plain Content-Disposition: inline In-Reply-To: <20040402085308.GB28623@dingdong.cryptoapps.com> User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-ACS-Spam-Status: no X-ACS-Scanned-By: MD 2.38; SA 2.63; spamdefang 1.93 Content-Transfer-Encoding: 8bit X-archive-position: 2703 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs On Fri, Apr 02, 2004 at 12:53:08AM -0800, Chris Wedgwood wrote: > > Thanks for clarification, though! :) At least now I know _why_ XFS > > shouldn't be used on a production server :) > > You're most welcome. Best of luck with reiserfs. if your worried about data corruption/loss, reiserfs is the last fs you want to run to... -- Ethan Benson http://www.alaska.net/~erbenson/ -- Attached file included as plaintext by Ecartis -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iEYEARECAAYFAkBtMlkACgkQJKx7GixEevxURACdFxKuB94XHCd9ZcSTEeJBUJhS V/8AniqZHjdnsspKA4s7xDYgYZSbMCS8 =im2A -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Fri Apr 2 01:29:45 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 02 Apr 2004 01:29:50 -0800 (PST) Received: from samwel.tk (kluizenaar.xs4all.nl [213.84.184.247]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i329TNKO010738 for ; Fri, 2 Apr 2004 01:29:44 -0800 Received: from localhost ([127.0.0.1] helo=localhost.localdomain) by samwel.tk with esmtp (Exim 4.30) id 1B9KzG-00084l-9d; Fri, 02 Apr 2004 11:29:18 +0200 Subject: [patch 2/2] Synchronize XFS sync daemon with laptop mode syncs. To: linux-xfs@oss.sgi.com Cc: bart@samwel.tk From: bart@samwel.tk Date: Fri, 02 Apr 2004 11:29:17 +0200 Message-ID: X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bart@samwel.tk X-SA-Exim-Scanned: No (on samwel.tk); SAEximRunCond expanded to false X-archive-position: 2705 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bart@samwel.tk Precedence: bulk X-list: linux-xfs From: Bart Samwel The XFS sync daemon is responsible for periodically syncing an XFS filesystem. The problem: in laptop mode, this can kick in at any time and spin up the disk, even when there is no other reason to do so. This patch wakes up the XFS sync daemon whenever an XFS syncfs takes place (e.g., at sys_sync()) so that it does its job and then sleeps for as long as it can. It does so only when laptop mode is active. Laptop mode calls sys_sync() to perform a writeback just before the disk is spun down, so the XFS sync daemon will be woken up just before the disk is spun down as well, and after that it will leave the disk alone for a full lm_sync_interval. --- linux-2.6.4-bsamwel/fs/xfs/linux/xfs_super.c | 22 ++++++++++++++++++++++ linux-2.6.4-bsamwel/fs/xfs/linux/xfs_vfs.c | 1 + linux-2.6.4-bsamwel/fs/xfs/linux/xfs_vfs.h | 2 ++ 3 files changed, 25 insertions(+) diff -puN fs/xfs/linux/xfs_super.c~xfs-laptop-mode-syncd-synchronization fs/xfs/linux/xfs_super.c --- linux-2.6.4/fs/xfs/linux/xfs_super.c~xfs-laptop-mode-syncd-synchronization 2004-04-01 03:29:11.000000000 +0200 +++ linux-2.6.4-bsamwel/fs/xfs/linux/xfs_super.c 2004-04-01 03:29:11.000000000 +0200 @@ -471,6 +471,10 @@ syncd(void *arg) if (vfsp->vfs_flag & VFS_RDONLY) continue; VFS_SYNC(vfsp, SYNCD_FLAGS, NULL, error); + + vfsp->vfs_sync_seq++; + wmb(); + wake_up(&vfsp->vfs_wait_single_sync_task); } vfsp->vfs_sync_task = NULL; @@ -554,6 +558,24 @@ linvfs_sync_super( VFS_SYNC(vfsp, flags, NULL, error); sb->s_dirt = 0; + if (unlikely(laptop_mode)) + { + int prev_sync_seq = vfsp->vfs_sync_seq; + /* + * The disk must be active because we're syncing. + * We schedule syncd now (now that the disk is + * active) instead of later (when it might not be). + */ + wake_up_process(vfsp->vfs_sync_task); + /* + * We have to wait for the sync iteration to complete. + * If we don't, the disk activity caused by the sync + * will come after the sync is completed, and that + * triggers another sync from laptop mode. + */ + wait_event(vfsp->vfs_wait_single_sync_task, vfsp->vfs_sync_seq != prev_sync_seq); + } + return -error; } diff -puN fs/xfs/linux/xfs_vfs.c~xfs-laptop-mode-syncd-synchronization fs/xfs/linux/xfs_vfs.c --- linux-2.6.4/fs/xfs/linux/xfs_vfs.c~xfs-laptop-mode-syncd-synchronization 2004-04-01 03:29:11.000000000 +0200 +++ linux-2.6.4-bsamwel/fs/xfs/linux/xfs_vfs.c 2004-04-01 03:29:11.000000000 +0200 @@ -238,6 +238,7 @@ vfs_allocate( void ) vfsp = kmem_zalloc(sizeof(vfs_t), KM_SLEEP); bhv_head_init(VFS_BHVHEAD(vfsp), "vfs"); init_waitqueue_head(&vfsp->vfs_wait_sync_task); + init_waitqueue_head(&vfsp->vfs_wait_single_sync_task); return vfsp; } diff -puN fs/xfs/linux/xfs_vfs.h~xfs-laptop-mode-syncd-synchronization fs/xfs/linux/xfs_vfs.h --- linux-2.6.4/fs/xfs/linux/xfs_vfs.h~xfs-laptop-mode-syncd-synchronization 2004-04-01 03:29:11.000000000 +0200 +++ linux-2.6.4-bsamwel/fs/xfs/linux/xfs_vfs.h 2004-04-01 03:29:11.000000000 +0200 @@ -52,6 +52,8 @@ typedef struct vfs { bhv_head_t vfs_bh; /* head of vfs behavior chain */ struct super_block *vfs_super; /* Linux superblock structure */ struct task_struct *vfs_sync_task; + int vfs_sync_seq; /* syncd iteration sequence number */ + wait_queue_head_t vfs_wait_single_sync_task; wait_queue_head_t vfs_wait_sync_task; } vfs_t; _ From owner-linux-xfs@oss.sgi.com Fri Apr 2 01:29:39 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 02 Apr 2004 01:29:45 -0800 (PST) Received: from samwel.tk (kluizenaar.xs4all.nl [213.84.184.247]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i329TIKO010736 for ; Fri, 2 Apr 2004 01:29:39 -0800 Received: from localhost ([127.0.0.1] helo=localhost.localdomain) by samwel.tk with esmtp (Exim 4.30) id 1B9KzA-00083v-Is; Fri, 02 Apr 2004 11:29:12 +0200 Subject: [patch 1/2] Laptop mode support for XFS To: linux-xfs@oss.sgi.com Cc: bart@samwel.tk From: bart@samwel.tk Date: Fri, 02 Apr 2004 11:29:11 +0200 Message-ID: X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bart@samwel.tk X-SA-Exim-Scanned: No (on samwel.tk); SAEximRunCond expanded to false X-archive-position: 2704 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bart@samwel.tk Precedence: bulk X-list: linux-xfs From: Bart Samwel Add laptop mode support for XFS. * Add /proc/sys/fs/xfs/lm_age_buffer and .../lm_flush_interval, values that are used instead of age_buffer and flush_interval when laptop mode is active. * Make the macros xfs_age_buffer and xfs_flush_interval refer to lm_flush_age and lm_flush_interval when laptop mode is active. * Switch from keeping track of "flush time" to keeping track of "creation time" for a pagebuf, so that changes in xfs_age_buffer can take effect immediately instead of only for pagebufs whose flush time is set anew. * Export "laptop_mode" variable, so that XFS can be compiled as a module. --- linux-2.6.4-bsamwel/fs/xfs/linux/xfs_buf.c | 6 ++++-- linux-2.6.4-bsamwel/fs/xfs/linux/xfs_buf.h | 2 +- linux-2.6.4-bsamwel/fs/xfs/linux/xfs_globals.c | 3 +++ linux-2.6.4-bsamwel/fs/xfs/linux/xfs_linux.h | 4 ++-- linux-2.6.4-bsamwel/fs/xfs/linux/xfs_super.c | 1 + linux-2.6.4-bsamwel/fs/xfs/linux/xfs_sysctl.c | 10 ++++++++++ linux-2.6.4-bsamwel/fs/xfs/linux/xfs_sysctl.h | 6 ++++++ linux-2.6.4-bsamwel/mm/page-writeback.c | 1 + 8 files changed, 28 insertions(+), 5 deletions(-) diff -puN fs/xfs/linux/xfs_buf.c~xfs-laptop-mode fs/xfs/linux/xfs_buf.c --- linux-2.6.4/fs/xfs/linux/xfs_buf.c~xfs-laptop-mode 2004-04-01 02:19:28.000000000 +0200 +++ linux-2.6.4-bsamwel/fs/xfs/linux/xfs_buf.c 2004-04-01 02:19:28.000000000 +0200 @@ -58,6 +58,8 @@ #include #include #include +#include +#include #include "xfs_linux.h" @@ -1574,7 +1576,7 @@ pagebuf_delwri_queue( } list_add_tail(&pb->pb_list, &pbd_delwrite_queue); - pb->pb_flushtime = jiffies + xfs_age_buffer; + pb->pb_creation_time = jiffies; spin_unlock(&pbd_delwrite_lock); if (unlock) @@ -1647,7 +1649,7 @@ pagebuf_daemon( if ((pb->pb_flags & PBF_DELWRI) && !pagebuf_ispin(pb) && !pagebuf_cond_lock(pb)) { if (!force_flush && - time_before(jiffies, pb->pb_flushtime)) { + time_before(jiffies, pb->pb_creation_time + xfs_age_buffer)) { pagebuf_unlock(pb); break; } diff -puN fs/xfs/linux/xfs_buf.h~xfs-laptop-mode fs/xfs/linux/xfs_buf.h --- linux-2.6.4/fs/xfs/linux/xfs_buf.h~xfs-laptop-mode 2004-04-01 02:19:28.000000000 +0200 +++ linux-2.6.4-bsamwel/fs/xfs/linux/xfs_buf.h 2004-04-01 02:19:28.000000000 +0200 @@ -139,7 +139,7 @@ typedef int (*page_buf_bdstrat_t)(struct typedef struct page_buf_s { struct semaphore pb_sema; /* semaphore for lockables */ - unsigned long pb_flushtime; /* time to flush pagebuf */ + unsigned long pb_creation_time; /* time pagebuf was created */ atomic_t pb_pin_count; /* pin count */ wait_queue_head_t pb_waiters; /* unpin waiters */ struct list_head pb_list; diff -puN fs/xfs/linux/xfs_globals.c~xfs-laptop-mode fs/xfs/linux/xfs_globals.c --- linux-2.6.4/fs/xfs/linux/xfs_globals.c~xfs-laptop-mode 2004-04-01 02:19:28.000000000 +0200 +++ linux-2.6.4-bsamwel/fs/xfs/linux/xfs_globals.c 2004-04-01 02:19:28.000000000 +0200 @@ -57,12 +57,15 @@ xfs_param_t xfs_params = { .panic_mask = { 0, 0, 127 }, .error_level = { 0, 3, 11 }, .sync_interval = { HZ, 30*HZ, 60*HZ }, + .lm_sync_interval + = { HZ, 600*HZ, INT_MAX }, .stats_clear = { 0, 0, 1 }, .inherit_sync = { 0, 1, 1 }, .inherit_nodump = { 0, 1, 1 }, .inherit_noatim = { 0, 1, 1 }, .flush_interval = { HZ/2, HZ, 30*HZ }, .age_buffer = { 1*HZ, 15*HZ, 300*HZ }, + .lm_age_buffer = { 1*HZ, 600*HZ, INT_MAX }, }; /* diff -puN fs/xfs/linux/xfs_linux.h~xfs-laptop-mode fs/xfs/linux/xfs_linux.h --- linux-2.6.4/fs/xfs/linux/xfs_linux.h~xfs-laptop-mode 2004-04-01 02:19:28.000000000 +0200 +++ linux-2.6.4-bsamwel/fs/xfs/linux/xfs_linux.h 2004-04-01 02:19:28.000000000 +0200 @@ -134,13 +134,13 @@ static inline void set_buffer_unwritten_ #define irix_symlink_mode xfs_params.symlink_mode.val #define xfs_panic_mask xfs_params.panic_mask.val #define xfs_error_level xfs_params.error_level.val -#define xfs_syncd_interval xfs_params.sync_interval.val +#define xfs_syncd_interval (unlikely(laptop_mode) ? xfs_params.lm_sync_interval.val : xfs_params.sync_interval.val) #define xfs_stats_clear xfs_params.stats_clear.val #define xfs_inherit_sync xfs_params.inherit_sync.val #define xfs_inherit_nodump xfs_params.inherit_nodump.val #define xfs_inherit_noatime xfs_params.inherit_noatim.val #define xfs_flush_interval xfs_params.flush_interval.val -#define xfs_age_buffer xfs_params.age_buffer.val +#define xfs_age_buffer (unlikely(laptop_mode) ? xfs_params.lm_age_buffer.val : xfs_params.age_buffer.val) #define current_cpu() smp_processor_id() #define current_pid() (current->pid) diff -puN fs/xfs/linux/xfs_super.c~xfs-laptop-mode fs/xfs/linux/xfs_super.c --- linux-2.6.4/fs/xfs/linux/xfs_super.c~xfs-laptop-mode 2004-04-01 02:19:28.000000000 +0200 +++ linux-2.6.4-bsamwel/fs/xfs/linux/xfs_super.c 2004-04-01 03:25:16.000000000 +0200 @@ -72,6 +72,7 @@ #include #include #include +#include STATIC struct quotactl_ops linvfs_qops; STATIC struct super_operations linvfs_sops; diff -puN fs/xfs/linux/xfs_sysctl.c~xfs-laptop-mode fs/xfs/linux/xfs_sysctl.c --- linux-2.6.4/fs/xfs/linux/xfs_sysctl.c~xfs-laptop-mode 2004-04-01 02:19:28.000000000 +0200 +++ linux-2.6.4-bsamwel/fs/xfs/linux/xfs_sysctl.c 2004-04-01 02:19:28.000000000 +0200 @@ -103,6 +103,11 @@ STATIC ctl_table xfs_table[] = { &sysctl_intvec, NULL, &xfs_params.sync_interval.min, &xfs_params.sync_interval.max}, + {XFS_LM_SYNC_INTERVAL, "lm_sync_interval", &xfs_params.lm_sync_interval.val, + sizeof(int), 0644, NULL, &proc_dointvec_minmax, + &sysctl_intvec, NULL, + &xfs_params.lm_sync_interval.min, &xfs_params.lm_sync_interval.max}, + {XFS_INHERIT_SYNC, "inherit_sync", &xfs_params.inherit_sync.val, sizeof(int), 0644, NULL, &proc_dointvec_minmax, &sysctl_intvec, NULL, @@ -128,6 +133,11 @@ STATIC ctl_table xfs_table[] = { &sysctl_intvec, NULL, &xfs_params.age_buffer.min, &xfs_params.age_buffer.max}, + {XFS_LM_AGE_BUFFER, "lm_age_buffer", &xfs_params.lm_age_buffer.val, + sizeof(int), 0644, NULL, &proc_dointvec_minmax, + &sysctl_intvec, NULL, + &xfs_params.lm_age_buffer.min, &xfs_params.lm_age_buffer.max}, + /* please keep this the last entry */ #ifdef CONFIG_PROC_FS {XFS_STATS_CLEAR, "stats_clear", &xfs_params.stats_clear.val, diff -puN fs/xfs/linux/xfs_sysctl.h~xfs-laptop-mode fs/xfs/linux/xfs_sysctl.h --- linux-2.6.4/fs/xfs/linux/xfs_sysctl.h~xfs-laptop-mode 2004-04-01 02:19:28.000000000 +0200 +++ linux-2.6.4-bsamwel/fs/xfs/linux/xfs_sysctl.h 2004-04-01 02:19:28.000000000 +0200 @@ -54,6 +54,7 @@ typedef struct xfs_param { xfs_sysctl_val_t panic_mask; /* bitmask to cause panic on errors. */ xfs_sysctl_val_t error_level; /* Degree of reporting for problems */ xfs_sysctl_val_t sync_interval; /* time between sync calls */ + xfs_sysctl_val_t lm_sync_interval; /* same, in laptop mode */ xfs_sysctl_val_t stats_clear; /* Reset all XFS statistics to zero. */ xfs_sysctl_val_t inherit_sync; /* Inherit the "sync" inode flag. */ xfs_sysctl_val_t inherit_nodump;/* Inherit the "nodump" inode flag. */ @@ -62,6 +63,9 @@ typedef struct xfs_param { * delwri flush daemon. */ xfs_sysctl_val_t age_buffer; /* time for buffer to age before * we flush it. */ + xfs_sysctl_val_t lm_age_buffer; /* time for buffer to age before + * we flush it when laptop mode is + * active. */ } xfs_param_t; /* @@ -86,12 +90,14 @@ enum { XFS_PANIC_MASK = 6, XFS_ERRLEVEL = 7, XFS_SYNC_INTERVAL = 8, + XFS_LM_SYNC_INTERVAL = 9, XFS_STATS_CLEAR = 12, XFS_INHERIT_SYNC = 13, XFS_INHERIT_NODUMP = 14, XFS_INHERIT_NOATIME = 15, XFS_FLUSH_INTERVAL = 16, XFS_AGE_BUFFER = 17, + XFS_LM_AGE_BUFFER = 3, }; extern xfs_param_t xfs_params; diff -puN mm/page-writeback.c~xfs-laptop-mode mm/page-writeback.c --- linux-2.6.4/mm/page-writeback.c~xfs-laptop-mode 2004-04-01 02:19:28.000000000 +0200 +++ linux-2.6.4-bsamwel/mm/page-writeback.c 2004-04-01 03:25:13.000000000 +0200 @@ -91,6 +91,7 @@ int block_dump; * Flag that puts the machine in "laptop mode". */ int laptop_mode; +EXPORT_SYMBOL(laptop_mode); /* End of sysctl-exported parameters */ _ From owner-linux-xfs@oss.sgi.com Fri Apr 2 01:32:39 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 02 Apr 2004 01:32:46 -0800 (PST) Received: from dingdong.cryptoapps.com (postfix@uslink-66.173.43-133.uslink.net [66.173.43.133] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i329WdKO011039 for ; Fri, 2 Apr 2004 01:32:39 -0800 Received: by dingdong.cryptoapps.com (Postfix, from userid 1001) id F22A2FB839; Fri, 2 Apr 2004 03:32:38 -0600 (CST) Date: Fri, 2 Apr 2004 01:32:38 -0800 From: Chris Wedgwood To: Carsten Gaebler Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: 2.4.25 XFS can't create files Message-ID: <20040402093238.GA28931@dingdong.cryptoapps.com> References: <406D20FE.8040701@snakefarm.org> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <406D20FE.8040701@snakefarm.org> Content-Transfer-Encoding: 8bit X-archive-position: 2706 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs (cc-'d to the linux-xfs list) On Fri, Apr 02, 2004 at 10:14:54AM +0200, Carsten Gaebler wrote: > I have somewhat of an esoteric problem. I can create an XFS on an > external fibre channel RAID attached to an LSI fibre channel card > (Fusion MPT driver) but I can't create files or directories on that > filesystem (Permission denied). ext2/ext3 work fine on the same > partition, so I suspect this is an XFS+MPT issue. I suspect it's not MPT related. I'm not farmiliar with stock 2.4.25 but assume the XFS merge went OK and everything is sane. Any chance you can test with a CVS kernel from oss.sgi.com to rule out the (probably minor) differences there? > sq22:~# touch /mnt/xfs/foo > touch: creating `/mnt/xfs/foo': Permission denied strace shows open/creat failing? there are also no ACLs and/or security modules involved are there? From owner-linux-xfs@oss.sgi.com Fri Apr 2 01:33:56 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 02 Apr 2004 01:34:04 -0800 (PST) Received: from phoenix.infradead.org (phoenix.infradead.org [213.86.99.234]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i329XZKO011254 for ; Fri, 2 Apr 2004 01:33:56 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.30 #5 (Red Hat Linux)) id 1B9L3N-0000Ct-Tx; Fri, 02 Apr 2004 10:33:33 +0100 Date: Fri, 2 Apr 2004 10:33:33 +0100 From: Christoph Hellwig To: bart@samwel.tk Cc: linux-xfs@oss.sgi.com Subject: Re: [patch 1/2] Laptop mode support for XFS Message-ID: <20040402103333.A787@infradead.org> References: Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from bart@samwel.tk on Fri, Apr 02, 2004 at 11:29:11AM +0200 Content-Transfer-Encoding: 8bit X-archive-position: 2707 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs On Fri, Apr 02, 2004 at 11:29:11AM +0200, bart@samwel.tk wrote: > > From: Bart Samwel > > Add laptop mode support for XFS. > > * Add /proc/sys/fs/xfs/lm_age_buffer and .../lm_flush_interval, values that > are used instead of age_buffer and flush_interval when laptop mode is > active. This doesn't make sense. Just change those values from userspace if your 'laptop mode' is active. From owner-linux-xfs@oss.sgi.com Fri Apr 2 01:34:17 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 02 Apr 2004 01:34:25 -0800 (PST) Received: from hermod.acsalaska.net (hermod.acsalaska.net [209.112.155.45]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i329XuKO011307 for ; Fri, 2 Apr 2004 01:34:17 -0800 Received: from erbenson.alaska.net (65-pm18.nwc.acsalaska.net [209.112.142.65]) by hermod.acsalaska.net (8.12.11/8.12.11) with ESMTP id i329Xtkh036031 for ; Fri, 2 Apr 2004 00:33:55 -0900 (AKST) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 1522639E3 for ; Fri, 2 Apr 2004 00:33:54 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id 4AA4B40FF35; Fri, 2 Apr 2004 00:33:54 -0900 (AKST) Date: Fri, 2 Apr 2004 00:33:54 -0900 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: file corruption Message-ID: <20040402093354.GK21226@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <406AF7B6.6030405@dniq-online.com> <20040402001801.GA24900@dingdong.cryptoapps.com> <406CB95B.4040500@dniq-online.com> <20040402043920.GF21226@plato.local.lan> <20040402044827.GC27240@dingdong.cryptoapps.com> <20040402071349.GH21226@plato.local.lan> <20040402085020.GA28623@dingdong.cryptoapps.com> Mime-Version: 1.0 Content-type: text/plain Content-Disposition: inline In-Reply-To: <20040402085020.GA28623@dingdong.cryptoapps.com> User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-ACS-Spam-Status: no X-ACS-Scanned-By: MD 2.38; SA 2.63; spamdefang 1.93 Content-Transfer-Encoding: 8bit X-archive-position: 2708 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs On Fri, Apr 02, 2004 at 12:50:20AM -0800, Chris Wedgwood wrote: > On Thu, Apr 01, 2004 at 10:13:49PM -0900, Ethan Benson wrote: > > > no more then 5 - 15 bytes or so. > > Sorry, I meant how large are the files ... not by how much are they > shifted. ah, various sizes all the apache archived logs were affected (except the most recent version as i recall). they range from 500K to 5MB. the rest of the compressed logs range form a couple K to aboug 800K. > > what i find most peculiar is how it consistently affected > > /var/log/foo.gz.{1,2} but not {3,4} (or maybe it was {2,3} and {3,4} > > i don't recall now). > > How can you tell if a compressed file is shifted 5-15 bytes? Casual > inspection will fail to decompress the data I would expect. by hexdumping and comparing the corrupt versions with the good versions on the original filesystem. also the uncompressed logfiles exhibited the same corruption, which is much more obvious to see. > > however no other .gz file anywhere else in the filesystem was > > corrupted in this manner. > > How recently had the logs been rotated before the unclean shutdown > occurred? 2-4 weeks. ive seen this on clean shutdowns after a filesystem copy as well. -- Ethan Benson http://www.alaska.net/~erbenson/ -- Attached file included as plaintext by Ecartis -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iEYEARECAAYFAkBtM4IACgkQJKx7GixEevwUYQCgkh/FQ44KD+QWpf6i2PZkn8tm gr0Ani9FeCYGvM8jxLvfBnqAz3ytPNBG =vcqH -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Fri Apr 2 01:45:14 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 02 Apr 2004 01:45:35 -0800 (PST) Received: from samwel.tk (kluizenaar.xs4all.nl [213.84.184.247]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i329irKO012802 for ; Fri, 2 Apr 2004 01:45:13 -0800 Received: from bsamwel by samwel.tk with local (Exim 4.30) id 1B9LEF-0008NC-DO; Fri, 02 Apr 2004 11:44:47 +0200 Subject: Re: [patch 1/2] Laptop mode support for XFS From: Bart Samwel To: Christoph Hellwig Cc: linux-xfs@oss.sgi.com In-Reply-To: <20040402103333.A787@infradead.org> References: <20040402103333.A787@infradead.org> Content-type: text/plain Content-Transfer-Encoding: 8bit Message-Id: <1080899086.5032.346.camel@samwel.tk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 02 Apr 2004 11:44:47 +0200 X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: bsamwel@samwel.tk X-SA-Exim-Scanned: No (on samwel.tk); SAEximRunCond expanded to false X-archive-position: 2709 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bart@samwel.tk Precedence: bulk X-list: linux-xfs On Fri, 2004-04-02 at 11:33, Christoph Hellwig wrote: > On Fri, Apr 02, 2004 at 11:29:11AM +0200, bart@samwel.tk wrote: > > > > From: Bart Samwel > > > > Add laptop mode support for XFS. > > > > * Add /proc/sys/fs/xfs/lm_age_buffer and .../lm_flush_interval, values that > > are used instead of age_buffer and flush_interval when laptop mode is > > active. > > This doesn't make sense. Just change those values from userspace if your > 'laptop mode' is active. The maximums that are listed for the regular flush_interval and age_buffer are way too low for laptop mode usage. I've considered increasing the maximums, but I figured they would be that low for a reason. By doing it this way, the maximums for regular usage aren't affected. If everybody thinks it's OK to simply increase the maximums on the regular ones to INT_MAX (or at least something like HZ*7200), I'll _gladly_ do that instead. --Bart From owner-linux-xfs@oss.sgi.com Fri Apr 2 01:56:21 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 02 Apr 2004 01:56:27 -0800 (PST) Received: from phoenix.infradead.org (phoenix.infradead.org [213.86.99.234]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i329txKO013627 for ; Fri, 2 Apr 2004 01:56:20 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.30 #5 (Red Hat Linux)) id 1B9LP3-0000GQ-00; Fri, 02 Apr 2004 10:55:57 +0100 Date: Fri, 2 Apr 2004 10:55:56 +0100 From: Christoph Hellwig To: Bart Samwel Cc: linux-xfs@oss.sgi.com Subject: Re: [patch 1/2] Laptop mode support for XFS Message-ID: <20040402105556.A1009@infradead.org> References: <20040402103333.A787@infradead.org> <1080899086.5032.346.camel@samwel.tk> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1080899086.5032.346.camel@samwel.tk>; from bart@samwel.tk on Fri, Apr 02, 2004 at 11:44:47AM +0200 Content-Transfer-Encoding: 8bit X-archive-position: 2710 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs On Fri, Apr 02, 2004 at 11:44:47AM +0200, Bart Samwel wrote: > The maximums that are listed for the regular flush_interval and > age_buffer are way too low for laptop mode usage. I've considered > increasing the maximums, but I figured they would be that low for a > reason. By doing it this way, the maximums for regular usage aren't > affected. If everybody thinks it's OK to simply increase the maximums on > the regular ones to INT_MAX (or at least something like HZ*7200), I'll > _gladly_ do that instead. There's no real problem with large intervals (except the possible data loss on a crash), so I'd say enlarge them. From owner-linux-xfs@oss.sgi.com Fri Apr 2 02:44:40 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 02 Apr 2004 02:44:50 -0800 (PST) Received: from corpmail.outblaze.com (corpmail.outblaze.com [203.86.166.82]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i32AidKO016968 for ; Fri, 2 Apr 2004 02:44:40 -0800 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by corpmail.outblaze.com (Postfix) with ESMTP id 1EC3A37AE6 for ; Fri, 2 Apr 2004 10:44:39 +0000 (GMT) Received: from yusufg.portal2.com (210-177-227-130.outblaze.com [210.177.227.130]) by corpmail.outblaze.com (Postfix) with SMTP id 9B45816DD97 for ; Fri, 2 Apr 2004 10:44:38 +0000 (GMT) Received: (qmail 24884 invoked by uid 500); 2 Apr 2004 10:44:36 -0000 Date: Fri, 2 Apr 2004 18:44:36 +0800 From: Yusuf Goolamabbas To: linux-xfs@oss.sgi.com Cc: akpm@osdl.org Subject: synctest results on xfs/ext3(htree) on 2.6.5-rc3-mm4 Message-ID: <20040402104436.GA24772@outblaze.com> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2i X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.11; VAE: 6.24.0.7; VDF: 6.24.0.82; host: corpmail.outblaze.com) Content-Transfer-Encoding: 8bit X-archive-position: 2711 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: yusufg@outblaze.com Precedence: bulk X-list: linux-xfs Here's result of running akpm's synctest available at http://www.zip.com.au/~akpm/linux/patches/stuff/ext3-tools.tar.gz I tried to run synctest in a way which modelled Postfix's queue writing behaviour. I ran it against ext3 (htree,ordered) and xfs. I used xfsprogs-2.6.9 to mkfs the xfs filesystem. I found that with the parameters I ran, xfs was very slow compared to ext3 Hardware, P3-450 with 384MB RAM, filesystems on a 9GB SCSI disk (aic7xxx). Anticipatory IO scheduler with global_tag_depth of 4 Tests performed after machine was cleanly booted. Multiple tests done, box rebooted between tests. numbers are more or less the same kernel version: 2.6.5-rc3-mm4 synctest : /usr/bin/time -p ./synctest -fu -t 100 -p1 -n1 /path/to/appropiate-dir htree,ordered : real 60.16 user 1.64 sys 17.81 xfs : real 880.71 user 2.93 sys 48.09 Regards, Yusuf From owner-linux-xfs@oss.sgi.com Fri Apr 2 03:20:57 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 02 Apr 2004 03:21:00 -0800 (PST) Received: from pophost.wldelft.nl (sunray.wldelft.nl [145.9.132.100]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i32BKjKO018805 for ; Fri, 2 Apr 2004 03:20:52 -0800 Received: (from root@localhost) by pophost.wldelft.nl (8.9.3/8.9.3vc) id NAA00013 for linux-xfs@oss.sgi.com; Fri, 2 Apr 2004 13:20:40 +0200 (MET DST) Received: from wldelft.nl (wl10564 [145.9.226.3]) by pophost.wldelft.nl (8.9.3/8.9.3) with ESMTP id NAA29414; Fri, 2 Apr 2004 13:20:28 +0200 (MET DST) Message-ID: <406D4D26.9030607@wldelft.nl> Date: Fri, 02 Apr 2004 13:23:18 +0200 From: Leroy van Logchem User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040123 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ethan Benson CC: linux-xfs@oss.sgi.com Subject: Re: file corruption References: <20040402001801.GA24900@dingdong.cryptoapps.com> <406CB95B.4040500@dniq-online.com> <20040402011618.GA25511@dingdong.cryptoapps.com> <406CC518.1090204@dniq-online.com> <20040402015022.GA25936@dingdong.cryptoapps.com> <406CCF08.9020309@tippett.com> <406CD88F.3070900@dniq-online.com> <20040402044712.GB27240@dingdong.cryptoapps.com> <406D0AE4.2030203@dniq-online.com> <20040402085308.GB28623@dingdong.cryptoapps.com> <20040402092857.GJ21226@plato.local.lan> In-Reply-To: <20040402092857.GJ21226@plato.local.lan> Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2712 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: leroy.vanlogchem@wldelft.nl Precedence: bulk X-list: linux-xfs Ethan Benson wrote: >On Fri, Apr 02, 2004 at 12:53:08AM -0800, Chris Wedgwood wrote: > > >>>Thanks for clarification, though! :) At least now I know _why_ XFS >>>shouldn't be used on a production server :) >>> >>> >>You're most welcome. Best of luck with reiserfs. >> >> >if your worried about data corruption/loss, reiserfs is the last fs >you want to run to... > > > Just use UFS2 on FreeBSD and be happy ever after. No corruption no loss just production quality. Been there.... never to return again. From owner-linux-xfs@oss.sgi.com Fri Apr 2 03:34:20 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 02 Apr 2004 03:34:37 -0800 (PST) Received: from mxintern.kundenserver.de (mxintern.kundenserver.de [212.227.126.201]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i32BYFKO028069 for ; Fri, 2 Apr 2004 03:34:20 -0800 Received: from [172.17.24.2] (helo=snakefarm.org) by mxintern.kundenserver.de with esmtp (Exim 3.35 #1) id 1B9MwA-0002pD-00; Fri, 02 Apr 2004 13:34:14 +0200 Message-ID: <406D4FB6.4070301@snakefarm.org> Date: Fri, 02 Apr 2004 13:34:14 +0200 From: Carsten Gaebler User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040124 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-kernel@vger.kernel.org CC: linux-xfs@oss.sgi.com Subject: Re: 2.4.25 XFS can't create files References: <406D20FE.8040701@snakefarm.org> <20040402093238.GA28931@dingdong.cryptoapps.com> In-Reply-To: <20040402093238.GA28931@dingdong.cryptoapps.com> Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2713 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ezinye-zinto@snakefarm.org Precedence: bulk X-list: linux-xfs Chris Wedgwood wrote: > I suspect it's not MPT related. I'm not farmiliar with stock 2.4.25 > but assume the XFS merge went OK and everything is sane. Any chance > you can test with a CVS kernel from oss.sgi.com to rule out the > (probably minor) differences there? The SGI kernel works fine. Thanks for the hint. > strace shows open/creat failing? Yes. open("/mnt/xfs/foo", O_WRONLY|O_NONBLOCK|O_CREAT|O_NOCTTY|O_LARGEFILE, 0666) = -1 EACCES (Permission denied) > there are also no ACLs and/or > security modules involved are there? Nope. cg. From owner-linux-xfs@oss.sgi.com Fri Apr 2 04:55:54 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 02 Apr 2004 04:55:59 -0800 (PST) Received: from alsvidh.mathematik.uni-muenchen.de (alsvidh.mathematik.uni-muenchen.de [129.187.111.42]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i32CthKO001602 for ; Fri, 2 Apr 2004 04:55:43 -0800 Received: by alsvidh.mathematik.uni-muenchen.de (Postfix, from userid 666) id 15BC63C7F3; Fri, 2 Apr 2004 14:22:17 +0200 (CEST) To: linux-xfs@oss.sgi.com Subject: slow file creation with xfs on software raid5 - suggestions? Organization: Lehrstuhl fuer vergleichende Astrozoologie X-Mahlzeit: Das ist per Saldo Gemuetlichkeit Reply-To: Jens Schmalzing From: Jens Schmalzing Date: 02 Apr 2004 14:22:17 +0200 Message-ID: Lines: 32 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i32CtsKO001607 X-archive-position: 2714 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: j.s@lmu.de Precedence: bulk X-list: linux-xfs Hi, I'm currently testing a small fileserver, using an array of SCA disks with xfs on top of software raid5. The chunk size of the raid is set to 4k, as is the sector size for the xfs filesystem. To be more precise, the file system was created with | # mkfs -t xfs -f -s size=4096 -l size=16384b /dev/md0 | meta-data=/dev/md0 isize=256 agcount=32, agsize=5608052 blks | = sectsz=4096 | data = bsize=4096 blocks=179457664, imaxpct=25 | = sunit=1 swidth=6 blks, unwritten=1 | naming =version 2 bsize=4096 | log =internal log bsize=4096 blocks=16384, version=2 | = sectsz=4096 sunit=1 blks | realtime =none extsz=24576 blocks=0, rtextents=0 While the setup performs well in general, I am a bit disappointed at the file creation speed - for example, unpacking a Linux kernel tree (a bit more than 200MB in a bit less than 20k files and directories) takes more than a minute and a half. The same is true for removing the whole thing again. On the other hand, reading is really fast. Any suggestions on tuning the file system or the software raid to obtain better performance? I'm also open to suggestions involving a different file system altogether. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj! From owner-linux-xfs@oss.sgi.com Fri Apr 2 05:42:45 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 02 Apr 2004 05:42:55 -0800 (PST) Received: from relay02.roc.ny.frontiernet.net (relay02.roc.ny.frontiernet.net [66.133.131.35]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i32DghKO003721 for ; Fri, 2 Apr 2004 05:42:44 -0800 Received: (qmail 1431 invoked from network); 2 Apr 2004 12:59:22 -0000 Received: from 208-186-10-249.nrp1.brv.mn.frontiernet.net (HELO xfs.org) ([208.186.10.249]) (envelope-sender ) by relay02.roc.ny.frontiernet.net (FrontierMTA 2.3.18) with SMTP for ; 2 Apr 2004 12:59:22 -0000 Message-ID: <406D6374.5000802@xfs.org> Date: Fri, 02 Apr 2004 06:58:28 -0600 From: Steve Lord User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yusuf Goolamabbas CC: linux-xfs@oss.sgi.com, akpm@osdl.org Subject: Re: synctest results on xfs/ext3(htree) on 2.6.5-rc3-mm4 References: <20040402104436.GA24772@outblaze.com> In-Reply-To: <20040402104436.GA24772@outblaze.com> Content-type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-archive-position: 2716 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 1317 Lines: 46 Yusuf Goolamabbas wrote: >Here's result of running akpm's synctest available at > > http://www.zip.com.au/~akpm/linux/patches/stuff/ext3-tools.tar.gz > >I tried to run synctest in a way which modelled Postfix's > queue writing behaviour. > >I ran it against ext3 (htree,ordered) and xfs. I used xfsprogs-2.6.9 to >mkfs the xfs filesystem. I found that with the parameters I ran, xfs was >very slow compared to ext3 > >Hardware, P3-450 with 384MB RAM, filesystems on a 9GB SCSI disk >(aic7xxx). >Anticipatory IO scheduler with global_tag_depth of 4 > >Tests performed after machine was cleanly booted. >Multiple tests done, box rebooted between tests. >numbers are more or less the same > >kernel version: 2.6.5-rc3-mm4 >synctest : > >/usr/bin/time -p ./synctest -fu -t 100 -p1 -n1 /path/to/appropiate-dir > >htree,ordered : real 60.16 user 1.64 sys 17.81 >xfs : real 880.71 user 2.93 sys 48.09 > >Regards, Yusuf > > > Did you use default mkfs parameters on xfs? Try upping the log size: mkfs -t xfs -f -l size=32768b ..... Also try mount -o logbufs=8 .... The multiple test dirs will make xfs spread out all over the disk, not sure how ext3 will place them. Probably seek heaven, what does the disk sound like on ext3, it chatters a lot for xfs. Steve From owner-linux-xfs@oss.sgi.com Fri Apr 2 06:11:44 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 02 Apr 2004 06:11:48 -0800 (PST) Received: from corpmail.outblaze.com (corpmail.outblaze.com [203.86.166.82]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i32EBgKO004969 for ; Fri, 2 Apr 2004 06:11:43 -0800 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by corpmail.outblaze.com (Postfix) with ESMTP id B147537AF5 for ; Fri, 2 Apr 2004 14:11:42 +0000 (GMT) Received: from yusufg.portal2.com (210-177-227-130.outblaze.com [210.177.227.130]) by corpmail.outblaze.com (Postfix) with SMTP id 117E516DD89 for ; Fri, 2 Apr 2004 14:11:42 +0000 (GMT) Received: (qmail 26699 invoked by uid 500); 2 Apr 2004 14:11:38 -0000 Date: Fri, 2 Apr 2004 22:11:38 +0800 From: Yusuf Goolamabbas To: Steve Lord Cc: linux-xfs@oss.sgi.com, akpm@osdl.org Subject: Re: synctest results on xfs/ext3(htree) on 2.6.5-rc3-mm4 Message-ID: <20040402141138.GB26499@outblaze.com> References: <20040402104436.GA24772@outblaze.com> <406D6374.5000802@xfs.org> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <406D6374.5000802@xfs.org> User-Agent: Mutt/1.4.2i X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.11; VAE: 6.24.0.7; VDF: 6.24.0.82; host: corpmail.outblaze.com) Content-Transfer-Encoding: 8bit X-archive-position: 2717 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: yusufg@outblaze.com Precedence: bulk X-list: linux-xfs Content-Length: 636 Lines: 22 > Did you use default mkfs parameters on xfs? Try upping the log size: > > mkfs -t xfs -f -l size=32768b ..... > > Also try > > mount -o logbufs=8 .... > The multiple test dirs will make xfs spread out all over the disk, > not sure how ext3 will place them. Probably seek heaven, what > does the disk sound like on ext3, it chatters a lot for xfs. Big difference With your mkfs settings and mount options, the same synctest finishes in real 97.64 user 2.20 sys 30.19 That's close to a 10x difference from the original numbers Can't tell you about disk noise now, doing the test remotely. I'll try to listen in on Monday From owner-linux-xfs@oss.sgi.com Fri Apr 2 06:30:44 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 02 Apr 2004 06:30:49 -0800 (PST) Received: from relay04.roc.ny.frontiernet.net (relay04.roc.ny.frontiernet.net [66.133.131.37]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i32EUgKO005916 for ; Fri, 2 Apr 2004 06:30:43 -0800 Received: (qmail 12706 invoked from network); 2 Apr 2004 14:30:41 -0000 Received: from 208-186-10-249.nrp1.brv.mn.frontiernet.net (HELO xfs.org) ([208.186.10.249]) (envelope-sender ) by relay04.roc.ny.frontiernet.net (FrontierMTA 2.3.18) with SMTP for ; 2 Apr 2004 14:30:41 -0000 Message-ID: <406D78E0.1000304@xfs.org> Date: Fri, 02 Apr 2004 08:29:52 -0600 From: Steve Lord User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yusuf Goolamabbas CC: linux-xfs@oss.sgi.com, akpm@osdl.org Subject: Re: synctest results on xfs/ext3(htree) on 2.6.5-rc3-mm4 References: <20040402104436.GA24772@outblaze.com> <406D6374.5000802@xfs.org> <20040402141138.GB26499@outblaze.com> In-Reply-To: <20040402141138.GB26499@outblaze.com> Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2718 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 959 Lines: 40 Yusuf Goolamabbas wrote: >>Did you use default mkfs parameters on xfs? Try upping the log size: >> >> mkfs -t xfs -f -l size=32768b ..... >> >>Also try >> >> mount -o logbufs=8 .... >>The multiple test dirs will make xfs spread out all over the disk, >>not sure how ext3 will place them. Probably seek heaven, what >>does the disk sound like on ext3, it chatters a lot for xfs. >> >> > >Big difference > >With your mkfs settings and mount options, the same synctest finishes in > >real 97.64 user 2.20 sys 30.19 > >That's close to a 10x difference from the original numbers > > Thats somewhat of a relief, we should be able to get closer to ext3 than that, but at least it puts us in the same ballpark. >Can't tell you about disk noise now, doing the test remotely. I'll try >to listen in on Monday > > > That's OK, if our 2 week old lets me I might be able to try ext3 myself, just a matter of being able to get to the basement ;-) Steve From owner-linux-xfs@oss.sgi.com Fri Apr 2 10:28:34 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 02 Apr 2004 10:28:36 -0800 (PST) Received: from dingdong.cryptoapps.com (postfix@uslink-66.173.43-133.uslink.net [66.173.43.133] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i32ISXKO015648 for ; Fri, 2 Apr 2004 10:28:34 -0800 Received: by dingdong.cryptoapps.com (Postfix, from userid 1001) id 0B218FB837; Fri, 2 Apr 2004 12:28:32 -0600 (CST) Date: Fri, 2 Apr 2004 10:28:32 -0800 From: Chris Wedgwood To: linux-xfs@oss.sgi.com Subject: Re: file corruption Message-ID: <20040402182832.GA2235@dingdong.cryptoapps.com> References: <406AF7B6.6030405@dniq-online.com> <20040402001801.GA24900@dingdong.cryptoapps.com> <406CB95B.4040500@dniq-online.com> <20040402043920.GF21226@plato.local.lan> <20040402044827.GC27240@dingdong.cryptoapps.com> <20040402071349.GH21226@plato.local.lan> <20040402085020.GA28623@dingdong.cryptoapps.com> <20040402093354.GK21226@plato.local.lan> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040402093354.GK21226@plato.local.lan> Content-Transfer-Encoding: 8bit X-archive-position: 2719 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 457 Lines: 14 On Fri, Apr 02, 2004 at 12:33:54AM -0900, Ethan Benson wrote: > by hexdumping and comparing the corrupt versions with the good > versions on the original filesystem. > > also the uncompressed logfiles exhibited the same corruption, which > is much more obvious to see. i can't think if anything which would cause entire files to have data shifted, and presumably this is across block boundaries too? without more data this is really hard to comment on From owner-linux-xfs@oss.sgi.com Fri Apr 2 12:47:20 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 02 Apr 2004 12:47:23 -0800 (PST) Received: from iss05.interliant.com (iss05.interliant.com [198.3.182.195]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i32KlJKO022822 for ; Fri, 2 Apr 2004 12:47:20 -0800 Received: from EX-008.mail.navisite.com (ex-008.interliant.com [198.3.179.39]) by iss05.interliant.com (8.10.2/8.10.2) with ESMTP id i32KlDH21536 for ; Fri, 2 Apr 2004 14:47:13 -0600 (CST) Received: from EX-001.mail.navisite.com ([172.16.1.11]) by EX-008.mail.navisite.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 2 Apr 2004 14:45:14 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 MIME-Version: 1.0 Subject: XFS corruption issue Date: Fri, 2 Apr 2004 14:46:39 -0600 Message-ID: <75653EEEF6218646B5239EA1D5204E26016DD5E5@EX-001.mail.navisite.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: XFS corruption issue Thread-Index: AcQY85j73zIbmzInTo+Pt9jlCceZyQ== From: "Shirley Shi" To: X-OriginalArrivalTime: 02 Apr 2004 20:45:14.0543 (UTC) FILETIME=[664983F0:01C418F3] Content-Disposition: inline Content-type: text/plain Content-Transfer-Encoding: 8bit X-archive-position: 2720 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: shirley@kasenna.com Precedence: bulk X-list: linux-xfs Content-Length: 1907 Lines: 50 Hi, I received the following XFS_WANT_CRRUPTED_RETURN error messages while writing data to XFS Filesystem. So that the write operation was failed. Can anyone tell me why this problem happened and how I can fix it? The system is configured as: linux 2.4.25 kernel with RH 8.0 system the xfs fs is on top of md0 stripped across two H/W RAID5 logical devices xfsprogs 2.4.12 internal xfs log with version 1 The machine was powered down due to an accident power out two weeks ago. I didn't do xfs_repair after it boot back since I didn't find any problem at that time. I don't know if the power down made some thing wrong on the xfs fs. Apr 1 17:28:49 k kernel: XFS internal error XFS_WANT_CORRUPTED_RETURN at line 310 of file xfs_alloc.c. Caller 0xf8a44c31 Apr 1 17:28:49 k kernel: dcb2b8c4 f8a4355c f8ab5bfc 00000001 00000000 f8ab5c16 00000136 f8a44c31 Apr 1 17:28:49 k kernel: 00000000 00000000 00000000 00000040 dcb2ba54 c0459e28 00000040 f8a44c31 Apr 1 17:28:49 k kernel: c0459e28 c0459da4 000dc080 00023f40 000dc080 00000040 00000002 edabf0e0 Apr 1 17:28:49 k kernel: Call Trace: [] [] [] [] [] Apr 1 17:28:49 k kernel: [] [] [] [] [] [] Apr 1 17:28:49 k kernel: [] [] [] [] [] [] Apr 1 17:28:49 k kernel: [] [] [] [] [] [] Apr 1 17:28:49 k kernel: [] [] [] [] [] [] Apr 1 17:28:49 k kernel: [] [] [] [] [] [] Apr 1 17:28:49 k kernel: [] [] Apr 1 17:28:49 k kernel: XFS internal error XFS_WANT_CORRUPTED_RETURN at line 310 of file xfs_alloc.c. Caller 0xf8a44c31 Thanks, -Shirley [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Fri Apr 2 15:02:56 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 02 Apr 2004 15:02:58 -0800 (PST) Received: from mail-h12-03.cc.ksu.edu (mail-h12-03.cc.ksu.edu [129.130.12.152]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i32N2uKO026339 for ; Fri, 2 Apr 2004 15:02:56 -0800 Received: from unix1.cc.ksu.edu (unix1.cc.ksu.edu [129.130.12.3]) by mail-h12-03.cc.ksu.edu (8.12.9/8.12.9) with ESMTP id i32N2nxU021820; Fri, 2 Apr 2004 17:02:49 -0600 (CST) Received: from localhost (matts@localhost) by unix1.cc.ksu.edu (8.8.8+Sun/8.8.8) with ESMTP id RAA27302; Fri, 2 Apr 2004 17:02:48 -0600 (CST) X-Authentication-Warning: unix1.cc.ksu.edu: matts owned process doing -bs Date: Fri, 2 Apr 2004 17:02:48 -0600 (CST) From: Matt Stegman X-X-Sender: matts@unix1.cc.ksu.edu To: Jens Schmalzing cc: linux-xfs@oss.sgi.com Subject: Re: slow file creation with xfs on software raid5 - suggestions? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit X-archive-position: 2721 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: matts@ksu.edu Precedence: bulk X-list: linux-xfs Content-Length: 2323 Lines: 62 Make your RAID5 chunk size larger than 4kB. I'd suggest you start with 32kB chunks; I chose 256kB for my RAID5 over four Serial ATA disks. # time tar jxf linux-2.4.24.tar.bz2 real 0m35.627s user 0m27.480s sys 0m5.170s # time rm -rf linux-2.4.24 real 0m5.761s user 0m0.000s sys 0m2.440s # xfs_info /home meta-data=/home isize=256 agcount=25, agsize=1048576 blks = sectsz=4096 data = bsize=4096 blocks=26214400, imaxpct=25 = sunit=64 swidth=192 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=12800, version=2 = sectsz=4096 sunit=1 blks realtime =none extsz=65536 blocks=0, rtextents=0 -- Matt Stegman On 2 Apr 2004, Jens Schmalzing wrote: > Hi, > > I'm currently testing a small fileserver, using an array of SCA disks > with xfs on top of software raid5. The chunk size of the raid is set > to 4k, as is the sector size for the xfs filesystem. To be more > precise, the file system was created with > > | # mkfs -t xfs -f -s size=4096 -l size=16384b /dev/md0 > | meta-data=/dev/md0 isize=256 agcount=32, agsize=5608052 blks > | = sectsz=4096 > | data = bsize=4096 blocks=179457664, imaxpct=25 > | = sunit=1 swidth=6 blks, unwritten=1 > | naming =version 2 bsize=4096 > | log =internal log bsize=4096 blocks=16384, version=2 > | = sectsz=4096 sunit=1 blks > | realtime =none extsz=24576 blocks=0, rtextents=0 > > While the setup performs well in general, I am a bit disappointed at > the file creation speed - for example, unpacking a Linux kernel tree > (a bit more than 200MB in a bit less than 20k files and directories) > takes more than a minute and a half. The same is true for removing > the whole thing again. On the other hand, reading is really fast. > > Any suggestions on tuning the file system or the software raid to > obtain better performance? I'm also open to suggestions involving a > different file system altogether. > > Regards, Jens. > > From owner-linux-xfs@oss.sgi.com Fri Apr 2 17:45:58 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 02 Apr 2004 17:46:01 -0800 (PST) Received: from omx2.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i331jvKO001712 for ; Fri, 2 Apr 2004 17:45:57 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i333oG6e023162 for ; Fri, 2 Apr 2004 19:50:16 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i331jpKe36309376; Fri, 2 Apr 2004 19:45:51 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i331joEr4105422; Fri, 2 Apr 2004 19:45:51 -0600 (CST) Date: Fri, 2 Apr 2004 19:45:50 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Shirley Shi cc: linux-xfs@oss.sgi.com Subject: Re: XFS corruption issue In-Reply-To: <75653EEEF6218646B5239EA1D5204E26016DD5E5@EX-001.mail.navisite.com> Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit X-archive-position: 2722 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2490 Lines: 66 Shirley - Running the oops through ksymoops would provide a bit more info. You probably want to run xfs_repair over the filesystem, also save that output and pass it along. Having said all that, often these errors are the filesystem coming across corruption that happened some time ago, so it's very hard to say exactly what went wrong or when; the message usually just means that we came back and found it at some later point. -Eric On Fri, 2 Apr 2004, Shirley Shi wrote: > Hi, > > I received the following XFS_WANT_CRRUPTED_RETURN error messages while > writing data to XFS Filesystem. So that the write operation was failed. > Can anyone tell me why this problem happened and how I can fix it? > > The system is configured as: > > linux 2.4.25 kernel with RH 8.0 system > the xfs fs is on top of md0 stripped across two H/W RAID5 logical > devices > xfsprogs 2.4.12 > internal xfs log with version 1 > > The machine was powered down due to an accident power out two weeks ago. > I didn't do xfs_repair after it boot back since I didn't find any > problem at that time. I don't know if the power down made some thing > wrong on the xfs fs. > > Apr 1 17:28:49 k kernel: XFS internal error XFS_WANT_CORRUPTED_RETURN at > line 310 of file xfs_alloc.c. Caller 0xf8a44c31 > Apr 1 17:28:49 k kernel: dcb2b8c4 f8a4355c f8ab5bfc 00000001 00000000 > f8ab5c16 00000136 f8a44c31 > Apr 1 17:28:49 k kernel: 00000000 00000000 00000000 00000040 dcb2ba54 > c0459e28 00000040 f8a44c31 > Apr 1 17:28:49 k kernel: c0459e28 c0459da4 000dc080 00023f40 000dc080 > 00000040 00000002 edabf0e0 > Apr 1 17:28:49 k kernel: Call Trace: [] [] > [] [] [] > Apr 1 17:28:49 k kernel: [] [] [] > [] [] [] > Apr 1 17:28:49 k kernel: [] [] [] > [] [] [] > Apr 1 17:28:49 k kernel: [] [] [] > [] [] [] > Apr 1 17:28:49 k kernel: [] [] [] > [] [] [] > Apr 1 17:28:49 k kernel: [] [] [] > [] [] [] > Apr 1 17:28:49 k kernel: [] [] > Apr 1 17:28:49 k kernel: XFS internal error XFS_WANT_CORRUPTED_RETURN at > line 310 of file xfs_alloc.c. Caller 0xf8a44c31 > > Thanks, > -Shirley > > > > [[HTML alternate version deleted]] > > From owner-linux-xfs@oss.sgi.com Fri Apr 2 20:10:58 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 02 Apr 2004 20:11:01 -0800 (PST) Received: from hermes.acsalaska.net (hermes.acsalaska.net [209.112.155.38]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i334AvKO006038 for ; Fri, 2 Apr 2004 20:10:58 -0800 Received: from erbenson.alaska.net (12-pm33.nwc.acsalaska.net [209.112.159.12]) by hermes.acsalaska.net (8.12.11/8.12.11) with ESMTP id i334AtLu092557 for ; Fri, 2 Apr 2004 19:10:55 -0900 (AKST) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 8B02D39E6 for ; Fri, 2 Apr 2004 19:10:54 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id 30A9F40FF35; Fri, 2 Apr 2004 19:10:54 -0900 (AKST) Date: Fri, 2 Apr 2004 19:10:54 -0900 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: file corruption Message-ID: <20040403041054.GN21226@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <406AF7B6.6030405@dniq-online.com> <20040402001801.GA24900@dingdong.cryptoapps.com> <406CB95B.4040500@dniq-online.com> <20040402043920.GF21226@plato.local.lan> <20040402044827.GC27240@dingdong.cryptoapps.com> <20040402071349.GH21226@plato.local.lan> <20040402085020.GA28623@dingdong.cryptoapps.com> <20040402093354.GK21226@plato.local.lan> <20040402182832.GA2235@dingdong.cryptoapps.com> Mime-Version: 1.0 Content-type: text/plain Content-Disposition: inline In-Reply-To: <20040402182832.GA2235@dingdong.cryptoapps.com> User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-ACS-Spam-Status: no X-ACS-Scanned-By: MD 2.39; SA 2.63; spamdefang 1.93 Content-Transfer-Encoding: 8bit X-archive-position: 2723 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs Content-Length: 967 Lines: 31 On Fri, Apr 02, 2004 at 10:28:32AM -0800, Chris Wedgwood wrote: > On Fri, Apr 02, 2004 at 12:33:54AM -0900, Ethan Benson wrote: > > > by hexdumping and comparing the corrupt versions with the good > > versions on the original filesystem. > > > > also the uncompressed logfiles exhibited the same corruption, which > > is much more obvious to see. > > i can't think if anything which would cause entire files to have data > shifted, and presumably this is across block boundaries too? > > without more data this is really hard to comment on i know.. thats why ive never brought it up before, but the other user's report sounded quite similar to my experience. -- Ethan Benson http://www.alaska.net/~erbenson/ -- Attached file included as plaintext by Ecartis -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iEYEARECAAYFAkBuOU0ACgkQJKx7GixEevx6GgCfc7nX03NEy2BCyEkzqh5y1ft9 ad4An0ErcVpOUG6hjFU0UTE6fLV6GUUt =8jx7 -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Sat Apr 3 03:12:53 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 03 Apr 2004 03:13:03 -0800 (PST) Received: from samwel.tk (kluizenaar.xs4all.nl [213.84.184.247]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i33BClKO024706 for ; Sat, 3 Apr 2004 03:12:52 -0800 Received: from localhost ([127.0.0.1] helo=localhost.localdomain) by samwel.tk with esmtp (Exim 4.30) id 1B9j4r-00081Q-DD; Sat, 03 Apr 2004 13:12:41 +0200 Subject: [patch 1/1] Make XFS sysctl parameters use USER_HZ instead of HZ. To: linux-xfs@oss.sgi.com Cc: bart@samwel.tk From: bart@samwel.tk Date: Sat, 03 Apr 2004 13:12:40 +0200 Message-ID: X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bart@samwel.tk X-SA-Exim-Scanned: No (on samwel.tk); SAEximRunCond expanded to false X-archive-position: 2724 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bart@samwel.tk Precedence: bulk X-list: linux-xfs Content-Length: 3551 Lines: 85 From: Bart Samwel The sysctl parameters sync_interval, flush_interval and age_buffer are in units of jiffies, which are very variable between kernels and architectures. These parameters should use USER_HZ, which is meant for use in external interfaces. Rationale: If there is no interface with a reliable unit, the laptop mode control script can never work reliably, because it then needs to know the value of HZ, which is intentionally not exported from the kernel anywhere. Possible improvement (matter of taste): renaming the variables, so that old code knows that the new variables are in new units. I suggest to not do this, because the variables previously didn't have any usable unit anyway. Any code that was written against this interface had to assume some HZ and would _have_ to have known that it would break with _any_ change in HZ. --- linux-2.6.4-bsamwel/fs/xfs/linux/xfs_globals.c | 26 ++++++++++++------------- linux-2.6.4-bsamwel/fs/xfs/linux/xfs_linux.h | 6 ++--- 2 files changed, 16 insertions(+), 16 deletions(-) diff -puN fs/xfs/linux/xfs_globals.c~xfs-sysctl-centisecs fs/xfs/linux/xfs_globals.c --- linux-2.6.4/fs/xfs/linux/xfs_globals.c~xfs-sysctl-centisecs 2004-04-03 12:41:05.000000000 +0200 +++ linux-2.6.4-bsamwel/fs/xfs/linux/xfs_globals.c 2004-04-03 12:52:05.000000000 +0200 @@ -50,19 +50,19 @@ unsigned long xfs_physmem; */ xfs_param_t xfs_params = { - /* MIN DFLT MAX */ - .restrict_chown = { 0, 1, 1 }, - .sgid_inherit = { 0, 0, 1 }, - .symlink_mode = { 0, 0, 1 }, - .panic_mask = { 0, 0, 127 }, - .error_level = { 0, 3, 11 }, - .sync_interval = { HZ, 30*HZ, 60*HZ }, - .stats_clear = { 0, 0, 1 }, - .inherit_sync = { 0, 1, 1 }, - .inherit_nodump = { 0, 1, 1 }, - .inherit_noatim = { 0, 1, 1 }, - .flush_interval = { HZ/2, HZ, 30*HZ }, - .age_buffer = { 1*HZ, 15*HZ, 300*HZ }, + /* MIN DFLT MAX */ + .restrict_chown = { 0, 1, 1 }, + .sgid_inherit = { 0, 0, 1 }, + .symlink_mode = { 0, 0, 1 }, + .panic_mask = { 0, 0, 127 }, + .error_level = { 0, 3, 11 }, + .sync_interval = { USER_HZ, 30*USER_HZ, 60*USER_HZ }, + .stats_clear = { 0, 0, 1 }, + .inherit_sync = { 0, 1, 1 }, + .inherit_nodump = { 0, 1, 1 }, + .inherit_noatim = { 0, 1, 1 }, + .flush_interval = { USER_HZ/2, USER_HZ, 30*USER_HZ }, + .age_buffer = { USER_HZ, 15*USER_HZ, 30*USER_HZ }, }; /* diff -puN fs/xfs/linux/xfs_linux.h~xfs-sysctl-centisecs fs/xfs/linux/xfs_linux.h --- linux-2.6.4/fs/xfs/linux/xfs_linux.h~xfs-sysctl-centisecs 2004-04-03 12:47:00.000000000 +0200 +++ linux-2.6.4-bsamwel/fs/xfs/linux/xfs_linux.h 2004-04-03 12:52:34.000000000 +0200 @@ -134,13 +134,13 @@ static inline void set_buffer_unwritten_ #define irix_symlink_mode xfs_params.symlink_mode.val #define xfs_panic_mask xfs_params.panic_mask.val #define xfs_error_level xfs_params.error_level.val -#define xfs_syncd_interval xfs_params.sync_interval.val +#define xfs_syncd_interval (xfs_params.sync_interval.val * HZ / USER_HZ) #define xfs_stats_clear xfs_params.stats_clear.val #define xfs_inherit_sync xfs_params.inherit_sync.val #define xfs_inherit_nodump xfs_params.inherit_nodump.val #define xfs_inherit_noatime xfs_params.inherit_noatim.val -#define xfs_flush_interval xfs_params.flush_interval.val -#define xfs_age_buffer xfs_params.age_buffer.val +#define xfs_flush_interval (xfs_params.flush_interval.val * HZ / USER_HZ) +#define xfs_age_buffer (xfs_params.age_buffer.val * HZ / USER_HZ) #define current_cpu() smp_processor_id() #define current_pid() (current->pid) _ From owner-linux-xfs@oss.sgi.com Sat Apr 3 04:00:19 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 03 Apr 2004 04:00:33 -0800 (PST) Received: from lists.suse.com (lists.suse.com [195.135.221.131]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i33C0HKO026288 for ; Sat, 3 Apr 2004 04:00:18 -0800 Received: (qmail 10930 invoked by alias); 3 Apr 2004 12:00:10 -0000 Mailing-List: contact suse-linux-help@suse.com; run by ezmlm Date: 3 Apr 2004 12:00:10 -0000 Message-ID: <1080993610.10929.ezmlm@suse.com> From: suse-linux-return-@suse.com To: linux-xfs@oss.sgi.com Delivered-To: responder for suse-linux@suse.com Received: (qmail 10923 invoked from network); 3 Apr 2004 12:00:10 -0000 Received: from unknown (HELO hermes.suse.de) (195.135.221.8) by 0 with SMTP; 3 Apr 2004 12:00:10 -0000 Received: from scanhost.suse.de (scanhost.suse.de [10.0.0.5]) by hermes.suse.de (Postfix) with ESMTP id 59060178DD for ; Sat, 3 Apr 2004 14:00:10 +0200 (CEST) Received: by scanhost.suse.de (Postfix, from userid 0) id 5140A1A922; Sat, 3 Apr 2004 14:00:10 +0200 (CEST) Delivered-To: virus-quarantine Received: from Cantor.suse.de (ns.suse.de [195.135.220.2]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by hermes.suse.de (Postfix) with ESMTP id 432771ABC0 for ; Sat, 3 Apr 2004 13:50:21 +0200 (CEST) Received: from suse.com (p50830AFB.dip0.t-ipconnect.de [80.131.10.251]) by Cantor.suse.de (Postfix) with ESMTP id EC4DC3DAE50 for ; Sat, 3 Apr 2004 13:50:14 +0200 (CEST) MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Subject: ezmlm response Content-Transfer-Encoding: 8bit X-archive-position: 2725 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: suse-linux-return-@suse.com Precedence: bulk X-list: linux-xfs Content-Length: 6476 Lines: 154 Hi! This is the ezmlm program. I'm managing the suse-linux@suse.com mailing list. I'm working for my owner, who can be reached at suse-linux-owner@suse.com. Hier eine Aufstellung der Kommandos zur Steuerung des Mailinglistenmanagers ezmlm für diese Liste: Die beiden Adressen sind zur Anforderung eines Informationstextes zur Mailingliste bzw. zur Anforderung der FAQ (Frequently Asked Questions - oft gestellte Fragen und die Antworten darauf) vorgesehen. Auf diese Weise fordern Sie eine Kopie der Nachricht 12 vom Archiv an. Fordern Sie auf diese Weise eine Kopie der Nachrichten 123 bis 145 vom Archiv an. Sie können mit einer Anforderung maximal einhundert Nachrichten bekommen. Fordern Sie auf diese Weise die Betreff-Zeilen (Subjects) der Nachrichten von 123 bis 456 (inklusive) vom Archiv an. Pro Anforderung werden maximal 2000 Betreff-Zeilen zugestellt. Die Zustellung erfolgt in Gruppen zu je einhundert Betreff-Zeilen, so daß Sie mit dieser Anforderung real die Betreff-Zeilen der Nachrichten 100 bis 499 erhalten. Zusätzlich zu den Betreffzeilen wird der jeweilige Autor übermittelt. Anforderung aller Nachrichten, die den gleichen Betreff wie die Nachricht 123 haben. Der Inhalt der Nachrichten muß nicht unbedingt leer sein, Sie können auch etwas in die Betreff-Zeilen schreiben. Ich werde jedoch beide Angaben ignorieren - nur die angeschriebene Adresse ist für meine Steuerung maßgebend. ------------------------------------------------------------ ACHTUNG: bitte probieren Sie nicht die im folgenden genannte Adresse ich@lightwerk.de aus, sondern ersetzen Sie diese durch Ihre eigene Adresse, unter der Sie Abonnent der Liste werden möchten! ------------------------------------------------------------ Sie können direkt die Adresse vorgeben, unter der Sie als Empfänger der Liste eingetragen werden möchten. Dazu bauen Sie die gewünschte Adresse in meine Steuerungsadresse ein, indem Sie das at-Zeichen (@) durch ein Gleichheitszeichen (=) ersetzen. Um zum Beispiel als Adresse ich@lightwerk.de anzugeben, senden Sie eine Mail an die Adresse . Die entsprechende Adresse zum abmelden des Abonnements ist . In beiden Fällen werde ich eine Bestätigung an ich@lightwerk.de schicken, die Sie nach Empfang einfach nur beantworten müssen, um den An- oder Abmeldevorgang abzuschließen. Auch wenn diese Erklärungen zu kompliziert für Sie sein sollten oder Sie Probleme mit der Steuerung der Liste haben, schreiben Sie bitte keine Hilfemails an die Liste selbst. Wenden Sie sich stattdessen an den Listeneigentümer: suse-linux-owner@suse.com Bitte haben Sie Geduld, da es sich dabei um ein eventuell überlastetes menschliches Wesen handelt, das nie so schnell reagieren kann wie ich :) Wenn Sie weiterführende Informationen zu Mailinglisten haben möchten, schauen Sie sich doch im World Wide Web einmal das Dokument "Mailinglisten und ihre Benutzung" unter folgender Adresse an: http://www.pobox.com/~fte/ml.html --- Hier eine Aufstellung der wichtigsten Kommandos zur Steuerung des Mailinglistenmanagers ezmlm für diese Liste: Ich kann alle Ihre Anforderungen bezüglich der Liste automatisch bearbeiten. Schicken Sie einfach eine leere Mail an die jeweilige Adresse. SENDEN SIE KEINE KOMMANDOS AN DIE MAILINGLISTE SELBST. In dem Fall kann ich nicht darauf reagieren und viele Empfänger der Mailingliste werden sich bei Ihnen oder über Sie beschweren. Beschreibung der Steuerungsmöglichkeiten für diese Mailingliste wenn Sie die Mailingliste in Zukunft beziehen möchten Wenn Sie keine Nachrichten der Mailingliste suse-linux mehr empfangen möchten, benutzen Sie bitte die Adresse, die im Header "List-Unsubscribe:" angegeben ist. Wenn Sie Ihre Email-Adresse nach der Listenbestellung nicht geändert haben, geht auch: Beim Löschen oder Eintragen von Abonnenten verschicke ich eine zusätzliche Kontrollnachricht. Diese muß zur Bestätigung einfach nur beantwortet werden. Falls Sie menschliche Hilfe brauchen, wenden Sie sich bitte an den Listeneigentümer: Bitte schicken Sie eine Listenmail inklusive ALLER Header mit - dadurch wird es sehr viel leichter, Ihnen schnell zu helfen. --- Anbei eine Kopie der Anforderung die ich erhalten habe: -- Attached file included as plaintext by Ecartis -- Return-Path: Received: (qmail 10923 invoked from network); 3 Apr 2004 12:00:10 -0000 Received: from unknown (HELO hermes.suse.de) (195.135.221.8) by 0 with SMTP; 3 Apr 2004 12:00:10 -0000 Received: from scanhost.suse.de (scanhost.suse.de [10.0.0.5]) by hermes.suse.de (Postfix) with ESMTP id 59060178DD for ; Sat, 3 Apr 2004 14:00:10 +0200 (CEST) Received: by scanhost.suse.de (Postfix, from userid 0) id 5140A1A922; Sat, 3 Apr 2004 14:00:10 +0200 (CEST) Delivered-To: virus-quarantine X-Quarantine-id: Received: from Cantor.suse.de (ns.suse.de [195.135.220.2]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by hermes.suse.de (Postfix) with ESMTP id 432771ABC0 for ; Sat, 3 Apr 2004 13:50:21 +0200 (CEST) Received: from suse.com (p50830AFB.dip0.t-ipconnect.de [80.131.10.251]) by Cantor.suse.de (Postfix) with ESMTP id EC4DC3DAE50 for ; Sat, 3 Apr 2004 13:50:14 +0200 (CEST) From: linux-xfs@oss.sgi.com To: suse-linux-help@suse.com Subject: Mail Delivery (failure suse-linux-help@suse.com) Date: Sat, 3 Apr 2004 13:48:04 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: <20040403115014.EC4DC3DAE50@Cantor.suse.de> X-AMaViS-Alert: INFECTED, message contains virus: Worm.SomeFool.P X-Converted-To-Plain-Text: from multipart/related by demime 1.1d X-Converted-To-Plain-Text: Alternative section used was multipart/alternative [the SUSE virus scanner removed an attachment of type audio/x-wav which had a name of message.scr] [if you need the message in its original form including all attachments, please ask the SENDER for a version free of viruses] From owner-linux-xfs@oss.sgi.com Sat Apr 3 05:36:20 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 03 Apr 2004 05:36:25 -0800 (PST) Received: from samwel.tk (kluizenaar.xs4all.nl [213.84.184.247]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i33DaEKO000478 for ; Sat, 3 Apr 2004 05:36:19 -0800 Received: from localhost ([127.0.0.1] helo=localhost.localdomain) by samwel.tk with esmtp (Exim 4.30) id 1B9lJh-0001SC-T6 for linux-xfs@oss.sgi.com; Sat, 03 Apr 2004 15:36:09 +0200 Subject: [patch 1/2] From: Bart Samwel To: linux-xfs@oss.sgi.com From: bart@samwel.tk Date: Sat, 03 Apr 2004 15:36:09 +0200 Message-ID: X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bart@samwel.tk X-SA-Exim-Scanned: No (on samwel.tk); SAEximRunCond expanded to false X-archive-position: 2726 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bart@samwel.tk Precedence: bulk X-list: linux-xfs Content-Length: 2831 Lines: 74 Add laptop mode support for XFS. * Increase maximums for age_buffer and sync_interval so that values useful for laptop-mode are within the allowed range. * Switch from keeping track of "flush time" to keeping track of "creation time" for a pagebuf, so that changes in xfs_age_buffer can take effect immediately instead of only for pagebufs whose flush time is set anew. --- linux-2.6.4-bsamwel/fs/xfs/linux/xfs_buf.c | 4 ++-- linux-2.6.4-bsamwel/fs/xfs/linux/xfs_buf.h | 2 +- linux-2.6.4-bsamwel/fs/xfs/linux/xfs_globals.c | 4 ++-- 3 files changed, 5 insertions(+), 5 deletions(-) diff -puN fs/xfs/linux/xfs_buf.c~xfs-laptop-mode fs/xfs/linux/xfs_buf.c --- linux-2.6.4/fs/xfs/linux/xfs_buf.c~xfs-laptop-mode 2004-04-02 12:45:39.000000000 +0200 +++ linux-2.6.4-bsamwel/fs/xfs/linux/xfs_buf.c 2004-04-03 10:31:04.000000000 +0200 @@ -1574,7 +1574,7 @@ pagebuf_delwri_queue( } list_add_tail(&pb->pb_list, &pbd_delwrite_queue); - pb->pb_flushtime = jiffies + xfs_age_buffer; + pb->pb_creation_time = jiffies; spin_unlock(&pbd_delwrite_lock); if (unlock) @@ -1647,7 +1647,7 @@ pagebuf_daemon( if ((pb->pb_flags & PBF_DELWRI) && !pagebuf_ispin(pb) && !pagebuf_cond_lock(pb)) { if (!force_flush && - time_before(jiffies, pb->pb_flushtime)) { + time_before(jiffies, pb->pb_creation_time + xfs_age_buffer)) { pagebuf_unlock(pb); break; } diff -puN fs/xfs/linux/xfs_buf.h~xfs-laptop-mode fs/xfs/linux/xfs_buf.h --- linux-2.6.4/fs/xfs/linux/xfs_buf.h~xfs-laptop-mode 2004-04-02 12:45:39.000000000 +0200 +++ linux-2.6.4-bsamwel/fs/xfs/linux/xfs_buf.h 2004-04-02 12:45:39.000000000 +0200 @@ -139,7 +139,7 @@ typedef int (*page_buf_bdstrat_t)(struct typedef struct page_buf_s { struct semaphore pb_sema; /* semaphore for lockables */ - unsigned long pb_flushtime; /* time to flush pagebuf */ + unsigned long pb_creation_time; /* time pagebuf was created */ atomic_t pb_pin_count; /* pin count */ wait_queue_head_t pb_waiters; /* unpin waiters */ struct list_head pb_list; diff -puN fs/xfs/linux/xfs_globals.c~xfs-laptop-mode fs/xfs/linux/xfs_globals.c --- linux-2.6.4/fs/xfs/linux/xfs_globals.c~xfs-laptop-mode 2004-04-02 12:45:39.000000000 +0200 +++ linux-2.6.4-bsamwel/fs/xfs/linux/xfs_globals.c 2004-04-02 12:45:39.000000000 +0200 @@ -56,13 +56,13 @@ xfs_param_t xfs_params = { .symlink_mode = { 0, 0, 1 }, .panic_mask = { 0, 0, 127 }, .error_level = { 0, 3, 11 }, - .sync_interval = { HZ, 30*HZ, 60*HZ }, + .sync_interval = { HZ, 30*HZ, 7200*HZ }, .stats_clear = { 0, 0, 1 }, .inherit_sync = { 0, 1, 1 }, .inherit_nodump = { 0, 1, 1 }, .inherit_noatim = { 0, 1, 1 }, .flush_interval = { HZ/2, HZ, 30*HZ }, - .age_buffer = { 1*HZ, 15*HZ, 300*HZ }, + .age_buffer = { 1*HZ, 15*HZ, 7200*HZ }, }; /* _ From owner-linux-xfs@oss.sgi.com Sat Apr 3 05:36:21 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 03 Apr 2004 05:36:25 -0800 (PST) Received: from samwel.tk (kluizenaar.xs4all.nl [213.84.184.247]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i33DaJKO000481 for ; Sat, 3 Apr 2004 05:36:20 -0800 Received: from localhost ([127.0.0.1] helo=localhost.localdomain) by samwel.tk with esmtp (Exim 4.30) id 1B9lJn-0001Sz-Cj for linux-xfs@oss.sgi.com; Sat, 03 Apr 2004 15:36:15 +0200 Subject: [patch 2/2] From: Bart Samwel To: linux-xfs@oss.sgi.com From: bart@samwel.tk Date: Sat, 03 Apr 2004 15:36:15 +0200 Message-ID: X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bart@samwel.tk X-SA-Exim-Scanned: No (on samwel.tk); SAEximRunCond expanded to false X-archive-position: 2726 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bart@samwel.tk Precedence: bulk X-list: linux-xfs Content-Length: 4185 Lines: 111 The XFS sync daemon is responsible for periodically syncing an XFS filesystem. The problem: in laptop mode, this can kick in at any time and spin up the disk, even when there is no other reason to do so. This patch wakes up the XFS sync daemon whenever an XFS syncfs takes place (e.g., at sys_sync()) so that it does its job and then sleeps for as long as it can. It does so only when laptop mode is active. Laptop mode calls sys_sync() to perform a writeback just before the disk is spun down, so the XFS sync daemon will be woken up just before the disk is spun down as well, and after that it will leave the disk alone for a full lm_sync_interval. The patch also exports symbol laptop_mode, so that XFS can still be compiled as a module. --- --- linux-2.6.4-bsamwel/fs/xfs/linux/xfs_super.c | 23 +++++++++++++++++++++++ linux-2.6.4-bsamwel/fs/xfs/linux/xfs_vfs.c | 1 + linux-2.6.4-bsamwel/fs/xfs/linux/xfs_vfs.h | 2 ++ linux-2.6.4-bsamwel/mm/page-writeback.c | 1 + 4 files changed, 27 insertions(+) diff -puN fs/xfs/linux/xfs_super.c~xfs-laptop-mode-syncd-synchronization fs/xfs/linux/xfs_super.c --- linux-2.6.4/fs/xfs/linux/xfs_super.c~xfs-laptop-mode-syncd-synchronization 2004-04-03 15:34:30.000000000 +0200 +++ linux-2.6.4-bsamwel/fs/xfs/linux/xfs_super.c 2004-04-03 15:34:30.000000000 +0200 @@ -72,6 +72,7 @@ #include #include #include +#include STATIC struct quotactl_ops linvfs_qops; STATIC struct super_operations linvfs_sops; @@ -470,6 +471,10 @@ syncd(void *arg) if (vfsp->vfs_flag & VFS_RDONLY) continue; VFS_SYNC(vfsp, SYNCD_FLAGS, NULL, error); + + vfsp->vfs_sync_seq++; + wmb(); + wake_up(&vfsp->vfs_wait_single_sync_task); } vfsp->vfs_sync_task = NULL; @@ -553,6 +558,24 @@ linvfs_sync_super( VFS_SYNC(vfsp, flags, NULL, error); sb->s_dirt = 0; + if (unlikely(laptop_mode)) + { + int prev_sync_seq = vfsp->vfs_sync_seq; + /* + * The disk must be active because we're syncing. + * We schedule syncd now (now that the disk is + * active) instead of later (when it might not be). + */ + wake_up_process(vfsp->vfs_sync_task); + /* + * We have to wait for the sync iteration to complete. + * If we don't, the disk activity caused by the sync + * will come after the sync is completed, and that + * triggers another sync from laptop mode. + */ + wait_event(vfsp->vfs_wait_single_sync_task, vfsp->vfs_sync_seq != prev_sync_seq); + } + return -error; } diff -puN fs/xfs/linux/xfs_vfs.c~xfs-laptop-mode-syncd-synchronization fs/xfs/linux/xfs_vfs.c --- linux-2.6.4/fs/xfs/linux/xfs_vfs.c~xfs-laptop-mode-syncd-synchronization 2004-04-03 15:34:30.000000000 +0200 +++ linux-2.6.4-bsamwel/fs/xfs/linux/xfs_vfs.c 2004-04-03 15:34:30.000000000 +0200 @@ -238,6 +238,7 @@ vfs_allocate( void ) vfsp = kmem_zalloc(sizeof(vfs_t), KM_SLEEP); bhv_head_init(VFS_BHVHEAD(vfsp), "vfs"); init_waitqueue_head(&vfsp->vfs_wait_sync_task); + init_waitqueue_head(&vfsp->vfs_wait_single_sync_task); return vfsp; } diff -puN fs/xfs/linux/xfs_vfs.h~xfs-laptop-mode-syncd-synchronization fs/xfs/linux/xfs_vfs.h --- linux-2.6.4/fs/xfs/linux/xfs_vfs.h~xfs-laptop-mode-syncd-synchronization 2004-04-03 15:34:30.000000000 +0200 +++ linux-2.6.4-bsamwel/fs/xfs/linux/xfs_vfs.h 2004-04-03 15:34:30.000000000 +0200 @@ -52,6 +52,8 @@ typedef struct vfs { bhv_head_t vfs_bh; /* head of vfs behavior chain */ struct super_block *vfs_super; /* Linux superblock structure */ struct task_struct *vfs_sync_task; + int vfs_sync_seq; /* syncd iteration sequence number */ + wait_queue_head_t vfs_wait_single_sync_task; wait_queue_head_t vfs_wait_sync_task; } vfs_t; diff -puN mm/page-writeback.c~xfs-laptop-mode-syncd-synchronization mm/page-writeback.c --- linux-2.6.4/mm/page-writeback.c~xfs-laptop-mode-syncd-synchronization 2004-04-03 15:34:30.000000000 +0200 +++ linux-2.6.4-bsamwel/mm/page-writeback.c 2004-04-03 15:34:30.000000000 +0200 @@ -91,6 +91,7 @@ int block_dump; * Flag that puts the machine in "laptop mode". */ int laptop_mode; +EXPORT_SYMBOL(laptop_mode); /* End of sysctl-exported parameters */ _ From owner-linux-xfs@oss.sgi.com Sat Apr 3 05:39:26 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 03 Apr 2004 05:39:40 -0800 (PST) Received: from samwel.tk (kluizenaar.xs4all.nl [213.84.184.247]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i33DdPKO001323 for ; Sat, 3 Apr 2004 05:39:26 -0800 Received: from bsamwel by samwel.tk with local (Exim 4.30) id 1B9lMn-0001Wq-1P; Sat, 03 Apr 2004 15:39:21 +0200 Subject: Re: [patch 1/2] Laptop mode support for XFS From: Bart Samwel To: Christoph Hellwig Cc: XFS mailing list In-Reply-To: <20040402105556.A1009@infradead.org> References: <20040402103333.A787@infradead.org> <1080899086.5032.346.camel@samwel.tk> <20040402105556.A1009@infradead.org> Content-type: text/plain Content-Transfer-Encoding: 8bit Message-Id: <1080999560.2011.8.camel@samwel.tk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Sat, 03 Apr 2004 15:39:20 +0200 X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: bsamwel@samwel.tk X-SA-Exim-Scanned: No (on samwel.tk); SAEximRunCond expanded to false X-archive-position: 2727 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bart@samwel.tk Precedence: bulk X-list: linux-xfs Content-Length: 957 Lines: 22 On Fri, 2004-04-02 at 11:55, Christoph Hellwig wrote: > On Fri, Apr 02, 2004 at 11:44:47AM +0200, Bart Samwel wrote: > > The maximums that are listed for the regular flush_interval and > > age_buffer are way too low for laptop mode usage. I've considered > > increasing the maximums, but I figured they would be that low for a > > reason. By doing it this way, the maximums for regular usage aren't > > affected. If everybody thinks it's OK to simply increase the maximums on > > the regular ones to INT_MAX (or at least something like HZ*7200), I'll > > _gladly_ do that instead. > > There's no real problem with large intervals (except the possible data > loss on a crash), so I'd say enlarge them. I've done so in the patches that I've just posted to the list, I've put them at HZ*7200. These patches also fix another problem with the earlier patches -- when I split up the patches, some of the #includes had ended up in the wrong patch. :) --Bart From owner-linux-xfs@oss.sgi.com Sat Apr 3 18:32:06 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 03 Apr 2004 18:32:12 -0800 (PST) Received: from burgers.bubbanfriends.org (IDENT:Nhw6ZZc5U9ckj6+SH8Yryt1t+TK0C3A9@burgers.bubbanfriends.org [69.212.163.241]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i342W5KO004026 for ; Sat, 3 Apr 2004 18:32:05 -0800 Received: from localhost (burgers.bubbanfriends.org [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 7D4101421005 for ; Sat, 3 Apr 2004 21:33:34 -0500 (EST) Received: from burgers.bubbanfriends.org ([127.0.0.1]) by localhost (burgers.bubbanfriends.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03130-10 for ; Sat, 3 Apr 2004 21:33:33 -0500 (EST) Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id E026D1421002; Sat, 3 Apr 2004 21:33:32 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id C977030002A2 for ; Sat, 3 Apr 2004 21:33:32 -0500 (EST) Date: Sat, 3 Apr 2004 21:33:32 -0500 (EST) From: Mike Burger Cc: linux-xfs@oss.sgi.com Subject: Re: ezmlm response In-Reply-To: <1080993610.10929.ezmlm@suse.com> Message-ID: References: <1080993610.10929.ezmlm@suse.com> MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 X-Virus-Scanned: by amavisd-new at bubbanfriends.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i342W6KO004029 X-archive-position: 2728 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mburger@bubbanfriends.org Precedence: bulk X-list: linux-xfs Content-Length: 7251 Lines: 177 Silly question, but who signed the list up for another list? On Sat, 3 Apr 2004 suse-linux-return-@suse.com wrote: > Hi! This is the ezmlm program. I'm managing the > suse-linux@suse.com mailing list. > I'm working for my owner, who can be reached > at suse-linux-owner@suse.com. > > Hier eine Aufstellung der Kommandos zur Steuerung des > Mailinglistenmanagers ezmlm für diese Liste: > > > > Die beiden Adressen sind zur Anforderung eines > Informationstextes zur Mailingliste bzw. zur Anforderung der > FAQ (Frequently Asked Questions - oft gestellte Fragen und > die Antworten darauf) vorgesehen. > > > Auf diese Weise fordern Sie eine Kopie der Nachricht 12 > vom Archiv an. > > > Fordern Sie auf diese Weise eine Kopie der Nachrichten > 123 bis 145 vom Archiv an. Sie können mit einer Anforderung > maximal einhundert Nachrichten bekommen. > > > Fordern Sie auf diese Weise die Betreff-Zeilen (Subjects) > der Nachrichten von 123 bis 456 (inklusive) vom Archiv an. > Pro Anforderung werden maximal 2000 Betreff-Zeilen zugestellt. > Die Zustellung erfolgt in Gruppen zu je einhundert Betreff-Zeilen, > so daß Sie mit dieser Anforderung real die Betreff-Zeilen > der Nachrichten 100 bis 499 erhalten. > Zusätzlich zu den Betreffzeilen wird der jeweilige Autor > übermittelt. > > > Anforderung aller Nachrichten, die den gleichen Betreff wie > die Nachricht 123 haben. > > Der Inhalt der Nachrichten muß nicht unbedingt leer sein, Sie > können auch etwas in die Betreff-Zeilen schreiben. Ich werde > jedoch beide Angaben ignorieren - nur die angeschriebene Adresse > ist für meine Steuerung maßgebend. > > ------------------------------------------------------------ > ACHTUNG: bitte probieren Sie nicht die im folgenden genannte > Adresse ich@lightwerk.de aus, sondern ersetzen Sie > diese durch Ihre eigene Adresse, unter der Sie > Abonnent der Liste werden möchten! > ------------------------------------------------------------ > > Sie können direkt die Adresse vorgeben, unter der Sie als > Empfänger der Liste eingetragen werden möchten. Dazu bauen Sie > die gewünschte Adresse in meine Steuerungsadresse ein, indem Sie > das at-Zeichen (@) durch ein Gleichheitszeichen (=) ersetzen. > Um zum Beispiel als Adresse ich@lightwerk.de anzugeben, senden > Sie eine Mail an die Adresse > . > Die entsprechende Adresse zum abmelden des Abonnements ist > . > In beiden Fällen werde ich eine Bestätigung an ich@lightwerk.de > schicken, die Sie nach Empfang einfach nur beantworten müssen, > um den An- oder Abmeldevorgang abzuschließen. > > Auch wenn diese Erklärungen zu kompliziert für Sie sein sollten > oder Sie Probleme mit der Steuerung der Liste haben, schreiben > Sie bitte keine Hilfemails an die Liste selbst. Wenden Sie sich > stattdessen an den Listeneigentümer: > suse-linux-owner@suse.com > Bitte haben Sie Geduld, da es sich dabei um ein eventuell > überlastetes menschliches Wesen handelt, das nie so schnell > reagieren kann wie ich :) > > > Wenn Sie weiterführende Informationen zu Mailinglisten haben möchten, > schauen Sie sich doch im World Wide Web einmal das Dokument > "Mailinglisten und ihre Benutzung" unter folgender Adresse an: > http://www.pobox.com/~fte/ml.html > > --- Hier eine Aufstellung der wichtigsten Kommandos zur Steuerung des > Mailinglistenmanagers ezmlm für diese Liste: > > Ich kann alle Ihre Anforderungen bezüglich der Liste > automatisch bearbeiten. Schicken Sie einfach eine leere Mail > an die jeweilige Adresse. > SENDEN SIE KEINE KOMMANDOS AN DIE MAILINGLISTE SELBST. > In dem Fall kann ich nicht darauf reagieren und viele Empfänger > der Mailingliste werden sich bei Ihnen oder über Sie beschweren. > > > Beschreibung der Steuerungsmöglichkeiten für diese > Mailingliste > > > wenn Sie die Mailingliste in Zukunft beziehen möchten > > Wenn Sie keine Nachrichten der Mailingliste suse-linux > mehr empfangen möchten, benutzen Sie bitte die Adresse, die > im Header "List-Unsubscribe:" angegeben ist. Wenn Sie Ihre > Email-Adresse nach der Listenbestellung nicht geändert haben, > geht auch: > > > Beim Löschen oder Eintragen von Abonnenten verschicke ich eine > zusätzliche Kontrollnachricht. Diese muß zur Bestätigung einfach > nur beantwortet werden. > > Falls Sie menschliche Hilfe brauchen, wenden Sie sich bitte an > den Listeneigentümer: > > > > Bitte schicken Sie eine Listenmail inklusive ALLER Header mit - > dadurch wird es sehr viel leichter, Ihnen schnell zu helfen. > > --- Anbei eine Kopie der Anforderung die ich erhalten habe: > > > -- Attached file included as plaintext by Ecartis -- > > Return-Path: > Received: (qmail 10923 invoked from network); 3 Apr 2004 12:00:10 -0000 > Received: from unknown (HELO hermes.suse.de) (195.135.221.8) > by 0 with SMTP; 3 Apr 2004 12:00:10 -0000 > Received: from scanhost.suse.de (scanhost.suse.de [10.0.0.5]) > by hermes.suse.de (Postfix) with ESMTP id 59060178DD > for ; Sat, 3 Apr 2004 14:00:10 +0200 (CEST) > Received: by scanhost.suse.de (Postfix, from userid 0) > id 5140A1A922; Sat, 3 Apr 2004 14:00:10 +0200 (CEST) > Delivered-To: virus-quarantine > X-Quarantine-id: > Received: from Cantor.suse.de (ns.suse.de [195.135.220.2]) (using TLSv1 > with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client > certificate requested) by hermes.suse.de (Postfix) with ESMTP id > 432771ABC0 for ; Sat, 3 Apr 2004 13:50:21 > +0200 (CEST) > Received: from suse.com (p50830AFB.dip0.t-ipconnect.de [80.131.10.251]) > by Cantor.suse.de (Postfix) with ESMTP id EC4DC3DAE50 for > ; Sat, 3 Apr 2004 13:50:14 +0200 (CEST) > From: linux-xfs@oss.sgi.com > To: suse-linux-help@suse.com > Subject: Mail Delivery (failure suse-linux-help@suse.com) > Date: Sat, 3 Apr 2004 13:48:04 +0100 > MIME-Version: 1.0 > Content-Type: text/plain; charset="us-ascii" > Message-Id: <20040403115014.EC4DC3DAE50@Cantor.suse.de> > X-AMaViS-Alert: INFECTED, message contains virus: Worm.SomeFool.P > X-Converted-To-Plain-Text: from multipart/related by demime 1.1d > X-Converted-To-Plain-Text: Alternative section used was multipart/alternative > > > [the SUSE virus scanner removed an attachment of type audio/x-wav which had a name of message.scr] > [if you need the message in its original form including all attachments, please ask the SENDER for a version free of viruses] > > > -- Mike Burger http://www.bubbanfriends.org Visit the Dog Pound II BBS telnet://dogpound2.citadel.org or http://dogpound2.citadel.org:2000 To be notified of updates to the web site, visit http://www.bubbanfriends.org/mailman/listinfo/site-update, or send a message to: site-update-request@bubbanfriends.org with a message of: subscribe From owner-linux-xfs@oss.sgi.com Sun Apr 4 03:53:22 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 04 Apr 2004 03:53:28 -0700 (PDT) Received: from batleth.sapienti-sat.org (batleth.sapienti-sat.org [80.190.100.240]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i34ArKKO025635 for ; Sun, 4 Apr 2004 03:53:21 -0700 Received: from localhost (localhost [127.0.0.1]) by batleth.sapienti-sat.org (Postfix) with SMTP id ADF3710333E for ; Sun, 4 Apr 2004 12:53:19 +0200 (CEST) Received: from koschikode.com (pD95D1F6B.dip.t-dialin.net [217.93.31.107]) by batleth.sapienti-sat.org (Postfix) with ESMTP id 2E5631029CA for ; Sun, 4 Apr 2004 12:53:19 +0200 (CEST) Message-ID: <406FE91D.2020603@koschikode.com> Date: Sun, 04 Apr 2004 12:53:17 +0200 From: Juri Haberland User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en, de-DE MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: ezmlm response References: <1080993610.10929.ezmlm@suse.com> In-Reply-To: Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2729 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: juri@koschikode.com Precedence: bulk X-list: linux-xfs Content-Length: 2127 Lines: 43 Mike Burger wrote: > Silly question, but who signed the list up for another list? Noone. It was a virus sending itself to the suse-list with the xfs list as the sender address. Just read the included headers below... Cheers, Juri >> Return-Path: >> Received: (qmail 10923 invoked from network); 3 Apr 2004 12:00:10 -0000 >> Received: from unknown (HELO hermes.suse.de) (195.135.221.8) >> by 0 with SMTP; 3 Apr 2004 12:00:10 -0000 >> Received: from scanhost.suse.de (scanhost.suse.de [10.0.0.5]) >> by hermes.suse.de (Postfix) with ESMTP id 59060178DD >> for ; Sat, 3 Apr 2004 14:00:10 +0200 (CEST) >> Received: by scanhost.suse.de (Postfix, from userid 0) >> id 5140A1A922; Sat, 3 Apr 2004 14:00:10 +0200 (CEST) >> Delivered-To: virus-quarantine >> X-Quarantine-id: >> Received: from Cantor.suse.de (ns.suse.de [195.135.220.2]) (using TLSv1 >> with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client >> certificate requested) by hermes.suse.de (Postfix) with ESMTP id >> 432771ABC0 for ; Sat, 3 Apr 2004 13:50:21 >> +0200 (CEST) >> Received: from suse.com (p50830AFB.dip0.t-ipconnect.de [80.131.10.251]) >> by Cantor.suse.de (Postfix) with ESMTP id EC4DC3DAE50 for >> ; Sat, 3 Apr 2004 13:50:14 +0200 (CEST) >> From: linux-xfs@oss.sgi.com >> To: suse-linux-help@suse.com >> Subject: Mail Delivery (failure suse-linux-help@suse.com) >> Date: Sat, 3 Apr 2004 13:48:04 +0100 >> MIME-Version: 1.0 >> Content-Type: text/plain; charset="us-ascii" >> Message-Id: <20040403115014.EC4DC3DAE50@Cantor.suse.de> >> X-AMaViS-Alert: INFECTED, message contains virus: Worm.SomeFool.P >> X-Converted-To-Plain-Text: from multipart/related by demime 1.1d >> X-Converted-To-Plain-Text: Alternative section used was multipart/alternative >> >> >> [the SUSE virus scanner removed an attachment of type audio/x-wav which had a name of message.scr] >> [if you need the message in its original form including all attachments, please ask the SENDER for a version free of viruses] From owner-linux-xfs@oss.sgi.com Sun Apr 4 04:27:57 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 04 Apr 2004 04:28:14 -0700 (PDT) Received: from burgers.bubbanfriends.org (IDENT:ZqU/3DrQO+tkmV48LIUY8g1hpGh3gHbO@burgers.bubbanfriends.org [69.212.163.241]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i34BRtKO002824 for ; Sun, 4 Apr 2004 04:27:56 -0700 Received: from localhost (burgers.bubbanfriends.org [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id EE16C1421005; Sun, 4 Apr 2004 06:29:33 -0500 (EST) Received: from burgers.bubbanfriends.org ([127.0.0.1]) by localhost (burgers.bubbanfriends.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22630-10; Sun, 4 Apr 2004 06:29:32 -0500 (EST) Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id 58F0D1421002; Sun, 4 Apr 2004 06:29:32 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 4D27A30002A2; Sun, 4 Apr 2004 06:29:32 -0500 (EST) Date: Sun, 4 Apr 2004 06:29:32 -0500 (EST) From: Mike Burger To: kris buggenhout Cc: linux-xfs@oss.sgi.com Subject: Re: ezmlm response In-Reply-To: <1081075135.18829.1.camel@borg-cube.no-ip.com> Message-ID: References: <1080993610.10929.ezmlm@suse.com> <1081075135.18829.1.camel@borg-cube.no-ip.com> MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 X-Virus-Scanned: by amavisd-new at bubbanfriends.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i34BRvKO002825 X-archive-position: 2730 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mburger@bubbanfriends.org Precedence: bulk X-list: linux-xfs Content-Length: 8306 Lines: 192 Of course, I didn't bother to read the entire message...goes to show, right? Oy. On Sun, 4 Apr 2004, kris buggenhout wrote: > The end of the message is the dead give away... > > somebody on this mailinglist is using wincrap and is infected with a > virus, which has sent this mail to another list adress in his > adressbook,.. etc... > > kind regards, Kris > > On Sun, 2004-04-04 at 04:33, Mike Burger wrote: > > Silly question, but who signed the list up for another list? > > > > On Sat, 3 Apr 2004 suse-linux-return-@suse.com wrote: > > > > > Hi! This is the ezmlm program. I'm managing the > > > suse-linux@suse.com mailing list. > > > I'm working for my owner, who can be reached > > > at suse-linux-owner@suse.com. > > > > > > Hier eine Aufstellung der Kommandos zur Steuerung des > > > Mailinglistenmanagers ezmlm für diese Liste: > > > > > > > > > > > > Die beiden Adressen sind zur Anforderung eines > > > Informationstextes zur Mailingliste bzw. zur Anforderung der > > > FAQ (Frequently Asked Questions - oft gestellte Fragen und > > > die Antworten darauf) vorgesehen. > > > > > > > > > Auf diese Weise fordern Sie eine Kopie der Nachricht 12 > > > vom Archiv an. > > > > > > > > > Fordern Sie auf diese Weise eine Kopie der Nachrichten > > > 123 bis 145 vom Archiv an. Sie können mit einer Anforderung > > > maximal einhundert Nachrichten bekommen. > > > > > > > > > Fordern Sie auf diese Weise die Betreff-Zeilen (Subjects) > > > der Nachrichten von 123 bis 456 (inklusive) vom Archiv an. > > > Pro Anforderung werden maximal 2000 Betreff-Zeilen zugestellt. > > > Die Zustellung erfolgt in Gruppen zu je einhundert Betreff-Zeilen, > > > so daß Sie mit dieser Anforderung real die Betreff-Zeilen > > > der Nachrichten 100 bis 499 erhalten. > > > Zusätzlich zu den Betreffzeilen wird der jeweilige Autor > > > übermittelt. > > > > > > > > > Anforderung aller Nachrichten, die den gleichen Betreff wie > > > die Nachricht 123 haben. > > > > > > Der Inhalt der Nachrichten muß nicht unbedingt leer sein, Sie > > > können auch etwas in die Betreff-Zeilen schreiben. Ich werde > > > jedoch beide Angaben ignorieren - nur die angeschriebene Adresse > > > ist für meine Steuerung maßgebend. > > > > > > ------------------------------------------------------------ > > > ACHTUNG: bitte probieren Sie nicht die im folgenden genannte > > > Adresse ich@lightwerk.de aus, sondern ersetzen Sie > > > diese durch Ihre eigene Adresse, unter der Sie > > > Abonnent der Liste werden möchten! > > > ------------------------------------------------------------ > > > > > > Sie können direkt die Adresse vorgeben, unter der Sie als > > > Empfänger der Liste eingetragen werden möchten. Dazu bauen Sie > > > die gewünschte Adresse in meine Steuerungsadresse ein, indem Sie > > > das at-Zeichen (@) durch ein Gleichheitszeichen (=) ersetzen. > > > Um zum Beispiel als Adresse ich@lightwerk.de anzugeben, senden > > > Sie eine Mail an die Adresse > > > . > > > Die entsprechende Adresse zum abmelden des Abonnements ist > > > . > > > In beiden Fällen werde ich eine Bestätigung an ich@lightwerk.de > > > schicken, die Sie nach Empfang einfach nur beantworten müssen, > > > um den An- oder Abmeldevorgang abzuschließen. > > > > > > Auch wenn diese Erklärungen zu kompliziert für Sie sein sollten > > > oder Sie Probleme mit der Steuerung der Liste haben, schreiben > > > Sie bitte keine Hilfemails an die Liste selbst. Wenden Sie sich > > > stattdessen an den Listeneigentümer: > > > suse-linux-owner@suse.com > > > Bitte haben Sie Geduld, da es sich dabei um ein eventuell > > > überlastetes menschliches Wesen handelt, das nie so schnell > > > reagieren kann wie ich :) > > > > > > > > > Wenn Sie weiterführende Informationen zu Mailinglisten haben möchten, > > > schauen Sie sich doch im World Wide Web einmal das Dokument > > > "Mailinglisten und ihre Benutzung" unter folgender Adresse an: > > > http://www.pobox.com/~fte/ml.html > > > > > > --- Hier eine Aufstellung der wichtigsten Kommandos zur Steuerung des > > > Mailinglistenmanagers ezmlm für diese Liste: > > > > > > Ich kann alle Ihre Anforderungen bezüglich der Liste > > > automatisch bearbeiten. Schicken Sie einfach eine leere Mail > > > an die jeweilige Adresse. > > > SENDEN SIE KEINE KOMMANDOS AN DIE MAILINGLISTE SELBST. > > > In dem Fall kann ich nicht darauf reagieren und viele Empfänger > > > der Mailingliste werden sich bei Ihnen oder über Sie beschweren. > > > > > > > > > Beschreibung der Steuerungsmöglichkeiten für diese > > > Mailingliste > > > > > > > > > wenn Sie die Mailingliste in Zukunft beziehen möchten > > > > > > Wenn Sie keine Nachrichten der Mailingliste suse-linux > > > mehr empfangen möchten, benutzen Sie bitte die Adresse, die > > > im Header "List-Unsubscribe:" angegeben ist. Wenn Sie Ihre > > > Email-Adresse nach der Listenbestellung nicht geändert haben, > > > geht auch: > > > > > > > > > Beim Löschen oder Eintragen von Abonnenten verschicke ich eine > > > zusätzliche Kontrollnachricht. Diese muß zur Bestätigung einfach > > > nur beantwortet werden. > > > > > > Falls Sie menschliche Hilfe brauchen, wenden Sie sich bitte an > > > den Listeneigentümer: > > > > > > > > > > > > Bitte schicken Sie eine Listenmail inklusive ALLER Header mit - > > > dadurch wird es sehr viel leichter, Ihnen schnell zu helfen. > > > > > > --- Anbei eine Kopie der Anforderung die ich erhalten habe: > > > > > > > > > -- Attached file included as plaintext by Ecartis -- > > > > > > Return-Path: > > > Received: (qmail 10923 invoked from network); 3 Apr 2004 12:00:10 -0000 > > > Received: from unknown (HELO hermes.suse.de) (195.135.221.8) > > > by 0 with SMTP; 3 Apr 2004 12:00:10 -0000 > > > Received: from scanhost.suse.de (scanhost.suse.de [10.0.0.5]) > > > by hermes.suse.de (Postfix) with ESMTP id 59060178DD > > > for ; Sat, 3 Apr 2004 14:00:10 +0200 (CEST) > > > Received: by scanhost.suse.de (Postfix, from userid 0) > > > id 5140A1A922; Sat, 3 Apr 2004 14:00:10 +0200 (CEST) > > > Delivered-To: virus-quarantine > > > X-Quarantine-id: > > > Received: from Cantor.suse.de (ns.suse.de [195.135.220.2]) (using TLSv1 > > > with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client > > > certificate requested) by hermes.suse.de (Postfix) with ESMTP id > > > 432771ABC0 for ; Sat, 3 Apr 2004 13:50:21 > > > +0200 (CEST) > > > Received: from suse.com (p50830AFB.dip0.t-ipconnect.de [80.131.10.251]) > > > by Cantor.suse.de (Postfix) with ESMTP id EC4DC3DAE50 for > > > ; Sat, 3 Apr 2004 13:50:14 +0200 (CEST) > > > From: linux-xfs@oss.sgi.com > > > To: suse-linux-help@suse.com > > > Subject: Mail Delivery (failure suse-linux-help@suse.com) > > > Date: Sat, 3 Apr 2004 13:48:04 +0100 > > > MIME-Version: 1.0 > > > Content-Type: text/plain; charset="us-ascii" > > > Message-Id: <20040403115014.EC4DC3DAE50@Cantor.suse.de> > > > X-AMaViS-Alert: INFECTED, message contains virus: Worm.SomeFool.P > > > X-Converted-To-Plain-Text: from multipart/related by demime 1.1d > > > X-Converted-To-Plain-Text: Alternative section used was multipart/alternative > > > > > > > > > [the SUSE virus scanner removed an attachment of type audio/x-wav which had a name of message.scr] > > > [if you need the message in its original form including all attachments, please ask the SENDER for a version free of viruses] > > > > > > > > > > -- Mike Burger http://www.bubbanfriends.org Visit the Dog Pound II BBS telnet://dogpound2.citadel.org or http://dogpound2.citadel.org:2000 To be notified of updates to the web site, visit http://www.bubbanfriends.org/mailman/listinfo/site-update, or send a message to: site-update-request@bubbanfriends.org with a message of: subscribe From owner-linux-xfs@oss.sgi.com Sun Apr 4 06:43:04 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 04 Apr 2004 06:43:09 -0700 (PDT) Received: from vladbert.skynet.be (vladbert.isp.belgacom.be [195.238.3.12] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i34Dh2KO006820 for ; Sun, 4 Apr 2004 06:43:03 -0700 Received: from outmx018.isp.belgacom.be (outmx018.isp.belgacom.be [195.238.2.117]) by vladbert.skynet.be (8.12.9/8.12.9/Skynet-OUT-FALLBACK-2.22) with ESMTP id i34Ae19t014796 for ; Sun, 4 Apr 2004 12:40:01 +0200 (MEST) (envelope-from ) Received: from borg-cube.no-ip.com (37.208-200-80.adsl.skynet.be [80.200.208.37]) by outmx018.isp.belgacom.be (8.12.9/8.12.9/Skynet-OUT-2.21) with ESMTP id i34Acsdm011675; Sun, 4 Apr 2004 12:38:54 +0200 (envelope-from ) Subject: Re: ezmlm response From: kris buggenhout To: Mike Burger Cc: linux-xfs@oss.sgi.com In-Reply-To: References: <1080993610.10929.ezmlm@suse.com> Content-type: text/plain; charset=ISO-8859-1 Message-Id: <1081075135.18829.1.camel@borg-cube.no-ip.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Sun, 04 Apr 2004 12:38:55 +0200 X-RAVMilter-Version: 8.4.3(snapshot 20030212) (outmx018.isp.belgacom.be) X-MIME-Autoconverted: from 8bit to quoted-printable by vladbert.skynet.be id i34Ae19t014796 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i34Dh4KO006821 X-archive-position: 2731 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kris.buggenhout@skynet.be Precedence: bulk X-list: linux-xfs Content-Length: 7494 Lines: 170 The end of the message is the dead give away... somebody on this mailinglist is using wincrap and is infected with a virus, which has sent this mail to another list adress in his adressbook,.. etc... kind regards, Kris On Sun, 2004-04-04 at 04:33, Mike Burger wrote: > Silly question, but who signed the list up for another list? > > On Sat, 3 Apr 2004 suse-linux-return-@suse.com wrote: > > > Hi! This is the ezmlm program. I'm managing the > > suse-linux@suse.com mailing list. > > I'm working for my owner, who can be reached > > at suse-linux-owner@suse.com. > > > > Hier eine Aufstellung der Kommandos zur Steuerung des > > Mailinglistenmanagers ezmlm für diese Liste: > > > > > > > > Die beiden Adressen sind zur Anforderung eines > > Informationstextes zur Mailingliste bzw. zur Anforderung der > > FAQ (Frequently Asked Questions - oft gestellte Fragen und > > die Antworten darauf) vorgesehen. > > > > > > Auf diese Weise fordern Sie eine Kopie der Nachricht 12 > > vom Archiv an. > > > > > > Fordern Sie auf diese Weise eine Kopie der Nachrichten > > 123 bis 145 vom Archiv an. Sie können mit einer Anforderung > > maximal einhundert Nachrichten bekommen. > > > > > > Fordern Sie auf diese Weise die Betreff-Zeilen (Subjects) > > der Nachrichten von 123 bis 456 (inklusive) vom Archiv an. > > Pro Anforderung werden maximal 2000 Betreff-Zeilen zugestellt. > > Die Zustellung erfolgt in Gruppen zu je einhundert Betreff-Zeilen, > > so daß Sie mit dieser Anforderung real die Betreff-Zeilen > > der Nachrichten 100 bis 499 erhalten. > > Zusätzlich zu den Betreffzeilen wird der jeweilige Autor > > übermittelt. > > > > > > Anforderung aller Nachrichten, die den gleichen Betreff wie > > die Nachricht 123 haben. > > > > Der Inhalt der Nachrichten muß nicht unbedingt leer sein, Sie > > können auch etwas in die Betreff-Zeilen schreiben. Ich werde > > jedoch beide Angaben ignorieren - nur die angeschriebene Adresse > > ist für meine Steuerung maßgebend. > > > > ------------------------------------------------------------ > > ACHTUNG: bitte probieren Sie nicht die im folgenden genannte > > Adresse ich@lightwerk.de aus, sondern ersetzen Sie > > diese durch Ihre eigene Adresse, unter der Sie > > Abonnent der Liste werden möchten! > > ------------------------------------------------------------ > > > > Sie können direkt die Adresse vorgeben, unter der Sie als > > Empfänger der Liste eingetragen werden möchten. Dazu bauen Sie > > die gewünschte Adresse in meine Steuerungsadresse ein, indem Sie > > das at-Zeichen (@) durch ein Gleichheitszeichen (=) ersetzen. > > Um zum Beispiel als Adresse ich@lightwerk.de anzugeben, senden > > Sie eine Mail an die Adresse > > . > > Die entsprechende Adresse zum abmelden des Abonnements ist > > . > > In beiden Fällen werde ich eine Bestätigung an ich@lightwerk.de > > schicken, die Sie nach Empfang einfach nur beantworten müssen, > > um den An- oder Abmeldevorgang abzuschließen. > > > > Auch wenn diese Erklärungen zu kompliziert für Sie sein sollten > > oder Sie Probleme mit der Steuerung der Liste haben, schreiben > > Sie bitte keine Hilfemails an die Liste selbst. Wenden Sie sich > > stattdessen an den Listeneigentümer: > > suse-linux-owner@suse.com > > Bitte haben Sie Geduld, da es sich dabei um ein eventuell > > überlastetes menschliches Wesen handelt, das nie so schnell > > reagieren kann wie ich :) > > > > > > Wenn Sie weiterführende Informationen zu Mailinglisten haben möchten, > > schauen Sie sich doch im World Wide Web einmal das Dokument > > "Mailinglisten und ihre Benutzung" unter folgender Adresse an: > > http://www.pobox.com/~fte/ml.html > > > > --- Hier eine Aufstellung der wichtigsten Kommandos zur Steuerung des > > Mailinglistenmanagers ezmlm für diese Liste: > > > > Ich kann alle Ihre Anforderungen bezüglich der Liste > > automatisch bearbeiten. Schicken Sie einfach eine leere Mail > > an die jeweilige Adresse. > > SENDEN SIE KEINE KOMMANDOS AN DIE MAILINGLISTE SELBST. > > In dem Fall kann ich nicht darauf reagieren und viele Empfänger > > der Mailingliste werden sich bei Ihnen oder über Sie beschweren. > > > > > > Beschreibung der Steuerungsmöglichkeiten für diese > > Mailingliste > > > > > > wenn Sie die Mailingliste in Zukunft beziehen möchten > > > > Wenn Sie keine Nachrichten der Mailingliste suse-linux > > mehr empfangen möchten, benutzen Sie bitte die Adresse, die > > im Header "List-Unsubscribe:" angegeben ist. Wenn Sie Ihre > > Email-Adresse nach der Listenbestellung nicht geändert haben, > > geht auch: > > > > > > Beim Löschen oder Eintragen von Abonnenten verschicke ich eine > > zusätzliche Kontrollnachricht. Diese muß zur Bestätigung einfach > > nur beantwortet werden. > > > > Falls Sie menschliche Hilfe brauchen, wenden Sie sich bitte an > > den Listeneigentümer: > > > > > > > > Bitte schicken Sie eine Listenmail inklusive ALLER Header mit - > > dadurch wird es sehr viel leichter, Ihnen schnell zu helfen. > > > > --- Anbei eine Kopie der Anforderung die ich erhalten habe: > > > > > > -- Attached file included as plaintext by Ecartis -- > > > > Return-Path: > > Received: (qmail 10923 invoked from network); 3 Apr 2004 12:00:10 -0000 > > Received: from unknown (HELO hermes.suse.de) (195.135.221.8) > > by 0 with SMTP; 3 Apr 2004 12:00:10 -0000 > > Received: from scanhost.suse.de (scanhost.suse.de [10.0.0.5]) > > by hermes.suse.de (Postfix) with ESMTP id 59060178DD > > for ; Sat, 3 Apr 2004 14:00:10 +0200 (CEST) > > Received: by scanhost.suse.de (Postfix, from userid 0) > > id 5140A1A922; Sat, 3 Apr 2004 14:00:10 +0200 (CEST) > > Delivered-To: virus-quarantine > > X-Quarantine-id: > > Received: from Cantor.suse.de (ns.suse.de [195.135.220.2]) (using TLSv1 > > with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client > > certificate requested) by hermes.suse.de (Postfix) with ESMTP id > > 432771ABC0 for ; Sat, 3 Apr 2004 13:50:21 > > +0200 (CEST) > > Received: from suse.com (p50830AFB.dip0.t-ipconnect.de [80.131.10.251]) > > by Cantor.suse.de (Postfix) with ESMTP id EC4DC3DAE50 for > > ; Sat, 3 Apr 2004 13:50:14 +0200 (CEST) > > From: linux-xfs@oss.sgi.com > > To: suse-linux-help@suse.com > > Subject: Mail Delivery (failure suse-linux-help@suse.com) > > Date: Sat, 3 Apr 2004 13:48:04 +0100 > > MIME-Version: 1.0 > > Content-Type: text/plain; charset="us-ascii" > > Message-Id: <20040403115014.EC4DC3DAE50@Cantor.suse.de> > > X-AMaViS-Alert: INFECTED, message contains virus: Worm.SomeFool.P > > X-Converted-To-Plain-Text: from multipart/related by demime 1.1d > > X-Converted-To-Plain-Text: Alternative section used was multipart/alternative > > > > > > [the SUSE virus scanner removed an attachment of type audio/x-wav which had a name of message.scr] > > [if you need the message in its original form including all attachments, please ask the SENDER for a version free of viruses] > > > > > > From owner-linux-xfs@oss.sgi.com Sun Apr 4 10:13:43 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 04 Apr 2004 10:13:47 -0700 (PDT) Received: from tgpsolutions.com (host-22-202.ksb.net [207.212.22.202]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i34HDgKO016561 for ; Sun, 4 Apr 2004 10:13:43 -0700 Received: (qmail 31518 invoked by uid 115); 4 Apr 2004 17:13:42 -0000 Received: from bailey@tgpsolutions.com by macross by uid 106 with qmail-scanner-1.21 (clamdscan: 0.67. spamassassin: 2.63. Clear:RC:1(24.54.206.135):. Processed in 0.033544 secs); 04 Apr 2004 17:13:42 -0000 Received: from unknown (HELO lain.wired) (24.54.206.135) by 0 with SMTP; 4 Apr 2004 17:13:42 -0000 Date: Sun, 4 Apr 2004 10:13:38 -0700 From: Bailey Kong To: linux-xfs@oss.sgi.com Subject: XFS internal error Message-Id: <20040404101338.07d6cc42.bailey@tgpsolutions.com> X-Mailer: Sylpheed version 0.9.8 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-type: text/plain Content-Transfer-Encoding: 8bit X-archive-position: 2732 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bailey@tgpsolutions.com Precedence: bulk X-list: linux-xfs Content-Length: 1190 Lines: 46 Hello, I was googling around, and I found this thread in the archives http://oss.sgi.com/projects/xfs/mail_archive/200308/msg00335.html The suggested fix was: > That is a corrupt inode on the disk, time to break out xfs_repair. Do > a quick mount and unmount of the fs first, then run xfs_check and save > the output, finally run xfs_repair and send us the output of both > commands. I was wondering if you guys wanted the outputs from me as well, I have xfs_check output and xfs_repair -n output as well http://bailey.tgpsolutions.com/xfs_check http://bailey.tgpsolutions.com/xfs_repair I can also give you guys the output of xfs_repair w/o -n if you wish. The error seemed to have started Feb 6th, when I was using kernel 2.6.2. And is still appearing, even now, when I'm using kernel 2.6.4. My version of xfsprogs is 2.6.3. Best Regards, Bailey -- bailey@tgpsolutions.com Administrator, tgpsolutions http://www.tgpsolutions.com -- Attached file included as plaintext by Ecartis -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAcEJFJQxq3nrInXgRAq+QAKCpHHJ+0JeVbi9I4lLgHWYmlFrlRACghAiU bkP+QVQtO377QrDrxvnZepk= =jJs5 -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Sun Apr 4 10:50:56 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 04 Apr 2004 10:50:58 -0700 (PDT) Received: from dingdong.cryptoapps.com (postfix@uslink-66.173.43-133.uslink.net [66.173.43.133] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i34HouKO017868 for ; Sun, 4 Apr 2004 10:50:56 -0700 Received: by dingdong.cryptoapps.com (Postfix, from userid 1001) id 446ABFB837; Sun, 4 Apr 2004 12:50:53 -0500 (CDT) Date: Sun, 4 Apr 2004 10:50:53 -0700 From: Chris Wedgwood To: Bailey Kong Cc: linux-xfs@oss.sgi.com Subject: Re: XFS internal error Message-ID: <20040404175053.GA19528@dingdong.cryptoapps.com> References: <20040404101338.07d6cc42.bailey@tgpsolutions.com> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040404101338.07d6cc42.bailey@tgpsolutions.com> Content-Transfer-Encoding: 8bit X-archive-position: 2733 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 318 Lines: 10 On Sun, Apr 04, 2004 at 10:13:38AM -0700, Bailey Kong wrote: > The error seemed to have started Feb 6th, when I was using kernel > 2.6.2. And is still appearing, even now, when I'm using kernel > 2.6.4. My version of xfsprogs is 2.6.3. You mean you've fixed the filesystem (run xfs_repair) and the error returns? From owner-linux-xfs@oss.sgi.com Sun Apr 4 11:45:34 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 04 Apr 2004 11:45:38 -0700 (PDT) Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i34IjYKO019717 for ; Sun, 4 Apr 2004 11:45:34 -0700 Received: from [24.118.125.111] (c-24-118-125-111.mn.client2.attbi.com [24.118.125.111]) by lips.borg.umn.edu (8.12.11/8.12.11) with ESMTP id i34IjXid004425; Sun, 4 Apr 2004 13:45:33 -0500 (CDT) (envelope-from cattelan@thebarn.com) Subject: Re: XFS internal error From: Russell Cattelan To: Bailey Kong Cc: linux-xfs@oss.sgi.com In-Reply-To: <20040404101338.07d6cc42.bailey@tgpsolutions.com> References: <20040404101338.07d6cc42.bailey@tgpsolutions.com> Content-type: text/plain Message-Id: <1081103985.37957.16.camel@lupo.thebarn.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sun, 04 Apr 2004 13:39:46 -0500 Content-Transfer-Encoding: 8bit X-archive-position: 2734 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 1704 Lines: 52 On Sun, 2004-04-04 at 12:13, Bailey Kong wrote: > Hello, > I was googling around, and I found this thread in the archives > > http://oss.sgi.com/projects/xfs/mail_archive/200308/msg00335.html > > The suggested fix was: > > > That is a corrupt inode on the disk, time to break out xfs_repair. Do > > a quick mount and unmount of the fs first, then run xfs_check and save > > the output, finally run xfs_repair and send us the output of both > > commands. > > I was wondering if you guys wanted the outputs from me as well, > > I have xfs_check output and xfs_repair -n output as well > > http://bailey.tgpsolutions.com/xfs_check > http://bailey.tgpsolutions.com/xfs_repair > > I can also give you guys the output of xfs_repair w/o -n if you wish. > > The error seemed to have started Feb 6th, when I was using kernel 2.6.2. > And is still appearing, even now, when I'm using kernel 2.6.4. My > version of xfsprogs is 2.6.3. Just curious was this a 2.4 system that was upgraded to 2.6? if so was the filesystem clean before the upgrade? (Not that I'm really expecting you to have checked asking anyways) Finally did you ever do something directly to the block device while the fs was mounted? Like run xfs_db? There is a known problem with accessing a device, even if it's just read, while the fs is mounted. > > Best Regards, > Bailey -- Russell Cattelan -- Attached file included as plaintext by Ecartis -- -- File: signature.asc -- Desc: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQBAcFZxNRmM+OaGhBgRArLoAJ4jYocwvcYXaIL1RudxPvixb+J4aQCgg4Ce r+QPKWoA/09nou7h8UdBwVs= =akRP -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Sun Apr 4 12:59:12 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 04 Apr 2004 12:59:15 -0700 (PDT) Received: from mail2.catalyst.net.nz (godel.catalyst.net.nz [202.49.159.12]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i34JxAKO026145 for ; Sun, 4 Apr 2004 12:59:11 -0700 Received: from leibniz.catalyst.net.nz ([202.49.159.7] helo=shankara.wgtn.cat-it.co.nz) by mail2.catalyst.net.nz with esmtp (Cipher TLSv1:RC4-MD5:128) (Exim 3.35 #1 (Debian)) id 1BADln-0000GO-02 for ; Mon, 05 Apr 2004 07:59:03 +1200 From: Steve Wray Reply-To: stevew@catalyst.net.nz To: linux-xfs@oss.sgi.com Subject: Re: file corruption Date: Mon, 5 Apr 2004 07:59:02 +1200 User-Agent: KMail/1.5 References: <406AF7B6.6030405@dniq-online.com> <406CC518.1090204@dniq-online.com> <20040402015022.GA25936@dingdong.cryptoapps.com> In-Reply-To: <20040402015022.GA25936@dingdong.cryptoapps.com> MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200404050759.02927.stevew@catalyst.net.nz> X-System-Filter-Id: mail2.catalyst.net.nz 1BADln-0000GO-02 X-Virus-Scanned-By: Amavis with CLAM Anti Virus on mail2.catalyst.net.nz X-archive-position: 2735 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stevew@catalyst.net.nz Precedence: bulk X-list: linux-xfs Content-Length: 1111 Lines: 26 On Fri, 02 Apr 2004 13:50, Chris Wedgwood wrote: > On Thu, Apr 01, 2004 at 07:42:48PM -0600, Dmitry Nikiforov wrote: > > So technically the whole purpose of this is to provide faster > > startup time after crash and not the consistency of data, correct? > > yes > > some fs' will journal all data though (reiserfs and ext3 can do > this), but it often comes at a significant performance penalty for no > real gain (and sometimes causes other problems like seeing old/stale > data) This is why I use ext3 with data=journal on /var/log I ran benchmarks comparing with data=writeback (supposed to be the fastest mode) and found that for the sort of writes that happen on /var/log you don't lose performance (and if one were writing enough data fast enough to /var/log to actually experience the performance hit, one would probably have worst problems than performance anyway). The advantage is that in event of a kernel panic or other hard lockup, one can actually find some useful hints in the logs as to what went wrong, instead of 'garbage binary data'. I wish XFS had an *option* to journal data... From owner-linux-xfs@oss.sgi.com Sun Apr 4 13:53:15 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 04 Apr 2004 13:53:17 -0700 (PDT) Received: from dingdong.cryptoapps.com (postfix@uslink-66.173.43-133.uslink.net [66.173.43.133] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i34KrEKO027896 for ; Sun, 4 Apr 2004 13:53:14 -0700 Received: by dingdong.cryptoapps.com (Postfix, from userid 1001) id B9E65FB839; Sun, 4 Apr 2004 15:53:13 -0500 (CDT) Date: Sun, 4 Apr 2004 13:53:13 -0700 From: Chris Wedgwood To: Steve Wray Cc: linux-xfs@oss.sgi.com Subject: Re: file corruption Message-ID: <20040404205313.GA20703@dingdong.cryptoapps.com> References: <406AF7B6.6030405@dniq-online.com> <406CC518.1090204@dniq-online.com> <20040402015022.GA25936@dingdong.cryptoapps.com> <200404050759.02927.stevew@catalyst.net.nz> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200404050759.02927.stevew@catalyst.net.nz> Content-Transfer-Encoding: 8bit X-archive-position: 2736 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 856 Lines: 24 On Mon, Apr 05, 2004 at 07:59:02AM +1200, Steve Wray wrote: > This is why I use ext3 with data=journal on /var/log By default syslog writes synchronously... however many configurations have some files marked to write asynchronously. Does "data=journal" buy anything over synchronous writes? > The advantage is that in event of a kernel panic or other hard > lockup, one can actually find some useful hints in the logs as to > what went wrong, instead of 'garbage binary data'. Synchronous writes are probably more useful still. > I wish XFS had an *option* to journal data... There is already a massive amount of data written to the log (profile how much IO there is to a log during a large "rm -rf" or something), making this worse for a small number of corner-cases where alternative solutions exist doesn't seem entirely useful as-is. --cw From owner-linux-xfs@oss.sgi.com Sun Apr 4 14:16:40 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 04 Apr 2004 14:16:46 -0700 (PDT) Received: from hermes.acsalaska.net (hermes.acsalaska.net [209.112.155.38]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i34LGdKO029518 for ; Sun, 4 Apr 2004 14:16:39 -0700 Received: from erbenson.alaska.net (29-pm33.nwc.acsalaska.net [209.112.159.29]) by hermes.acsalaska.net (8.12.11/8.12.11) with ESMTP id i34LGb9P097775 for ; Sun, 4 Apr 2004 13:16:37 -0800 (AKDT) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 3ED7E39D9 for ; Sun, 4 Apr 2004 13:16:36 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id EE5FF40FF35; Sun, 4 Apr 2004 13:16:35 -0800 (AKDT) Date: Sun, 4 Apr 2004 13:16:35 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: file corruption Message-ID: <20040404211635.GS21226@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <406AF7B6.6030405@dniq-online.com> <406CC518.1090204@dniq-online.com> <20040402015022.GA25936@dingdong.cryptoapps.com> <200404050759.02927.stevew@catalyst.net.nz> Mime-Version: 1.0 Content-type: text/plain Content-Disposition: inline In-Reply-To: <200404050759.02927.stevew@catalyst.net.nz> User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-ACS-Spam-Status: no X-ACS-Scanned-By: MD 2.39; SA 2.63; spamdefang 1.93 Content-Transfer-Encoding: 8bit X-archive-position: 2737 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs Content-Length: 2015 Lines: 54 On Mon, Apr 05, 2004 at 07:59:02AM +1200, Steve Wray wrote: > On Fri, 02 Apr 2004 13:50, Chris Wedgwood wrote: > > On Thu, Apr 01, 2004 at 07:42:48PM -0600, Dmitry Nikiforov wrote: > > > So technically the whole purpose of this is to provide faster > > > startup time after crash and not the consistency of data, correct? > > > > yes > > > > some fs' will journal all data though (reiserfs and ext3 can do > > this), but it often comes at a significant performance penalty for no > > real gain (and sometimes causes other problems like seeing old/stale > > data) > > This is why I use ext3 with data=journal on /var/log > > I ran benchmarks comparing with data=writeback (supposed to be the > fastest mode) and found that for the sort of writes that happen on > /var/log you don't lose performance (and if one were writing enough > data fast enough to /var/log to actually experience the performance > hit, one would probably have worst problems than performance anyway). > > The advantage is that in event of a kernel panic or other hard lockup, > one can actually find some useful hints in the logs as to what went > wrong, instead of 'garbage binary data'. you could always configure syslog to sync its logs after writing, check your syslog.conf, it probably has most important logs prefixed with a - from the man page: You may prefix each entry with the minus ``-'' sign to omit syncing the file after every logging. Note that you might lose information if the system crashes right behind a write attempt. Nevertheless this might give you back some performance, especially if you run programs that use logging in a very verbose manner. there is also chattr +S for important files/dirs. -- Ethan Benson http://www.alaska.net/~erbenson/ -- Attached file included as plaintext by Ecartis -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iEYEARECAAYFAkBwezMACgkQJKx7GixEevzbLQCeLpXBk0XYVj3ove1PUVtN9dDv Q4MAn2n4CHEwlDt1gyO5VizVsx+121x9 =mBuf -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Sun Apr 4 16:46:14 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 04 Apr 2004 16:46:16 -0700 (PDT) Received: from camelot.virtualavalon.net (rrcs-se-24-73-202-230.biz.rr.com [24.73.202.230]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i34NkAKO004299 for ; Sun, 4 Apr 2004 16:46:12 -0700 Received: from arthur.virtualavalon.net (arthur.virtualavalon.net [172.20.1.10]) by camelot.virtualavalon.net (8.12.0/8.12.0) with ESMTP id i350oPqu009528 for ; Sun, 4 Apr 2004 20:50:25 -0400 Received: from tampabay.rr.com (wayfarer.virtualavalon.net [172.20.1.15]) by arthur.virtualavalon.net (8.12.10/8.12.0) with ESMTP id i34NiVF5028501 for ; Sun, 4 Apr 2004 19:44:32 -0400 (EDT) Message-ID: <40709DCE.7010704@tampabay.rr.com> Date: Sun, 04 Apr 2004 19:44:14 -0400 From: "Jesse W. Asher" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, ja MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Is XFS backwards compatible? Content-type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-archive-position: 2738 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jasher1@tampabay.rr.com Precedence: bulk X-list: linux-xfs Content-Length: 526 Lines: 17 Hello all! I have a system with filesystems built with XFS 1.0.1. I'd like to reinstall it using the latest XFS, but I'm wondering if XFS 1.3.1 will be able to read the filesystems created with 1.0.1? Eventually, I'd like to recreate them, but I'd like to know if I need to move my data before I reinstall. Thanks!! P.S. Will XFS 1.3.1 work with RedHat 9? -- Jesse W. Asher "They that can give up essential liberty to purchase a little temporary safety, deserve neither liberty or safety." - Benjamin Franklin From owner-linux-xfs@oss.sgi.com Sun Apr 4 17:09:43 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 04 Apr 2004 17:09:46 -0700 (PDT) Received: from hermes.acsalaska.net (hermes.acsalaska.net [209.112.155.38]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3509gKO005546 for ; Sun, 4 Apr 2004 17:09:43 -0700 Received: from erbenson.alaska.net (29-pm33.nwc.acsalaska.net [209.112.159.29]) by hermes.acsalaska.net (8.12.11/8.12.11) with ESMTP id i3509f1b080359 for ; Sun, 4 Apr 2004 16:09:41 -0800 (AKDT) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 2E68C39D9 for ; Sun, 4 Apr 2004 16:09:40 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 9F2C740FF35; Sun, 4 Apr 2004 16:09:39 -0800 (AKDT) Date: Sun, 4 Apr 2004 16:09:39 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: Is XFS backwards compatible? Message-ID: <20040405000939.GA14742@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <40709DCE.7010704@tampabay.rr.com> Mime-Version: 1.0 Content-type: text/plain Content-Disposition: inline In-Reply-To: <40709DCE.7010704@tampabay.rr.com> User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-ACS-Spam-Status: no X-ACS-Scanned-By: MD 2.39; SA 2.63; spamdefang 1.93 Content-Transfer-Encoding: 8bit X-archive-position: 2739 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs Content-Length: 1041 Lines: 35 On Sun, Apr 04, 2004 at 07:44:14PM -0400, Jesse W. Asher wrote: > > Hello all! > > I have a system with filesystems built with XFS 1.0.1. I'd like to > reinstall it using the latest XFS, but I'm wondering if XFS 1.3.1 will > be able to read the filesystems created with 1.0.1? Eventually, I'd > like to recreate them, but I'd like to know if I need to move my data > before I reinstall. Thanks!! the on disk format doesn't change in incompatible ways, the versions have to do with code versions, not disk format versions. so yes your existing filesystems are perfectly fine. > P.S. Will XFS 1.3.1 work with RedHat 9? if you replace the redhat kernel sure. just build yourself a 2.4.25 from kernel.org, it has XFS support. -- Ethan Benson http://www.alaska.net/~erbenson/ -- Attached file included as plaintext by Ecartis -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iEYEARECAAYFAkBwo8MACgkQJKx7GixEevwpeQCgmT+ZCmUqPO39YiizrAfGMp5J 4m0AoJ+PFClgtGkXNWpHoNpFlQXuTXbn =JPC/ -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Sun Apr 4 19:47:00 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 04 Apr 2004 19:47:12 -0700 (PDT) Received: from omx1.americas.sgi.com (cfcafw.sgi.com [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i352kvKO009676 for ; Sun, 4 Apr 2004 19:47:00 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i352eqVC011159 for ; Sun, 4 Apr 2004 21:40:53 -0500 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i352emAL38045316; Mon, 5 Apr 2004 12:40:48 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i352eknW38005913; Mon, 5 Apr 2004 12:40:46 +1000 (EST) Date: Mon, 5 Apr 2004 12:40:46 +1000 (EST) From: Nathan Scott Message-Id: <200404050240.i352eknW38005913@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, c.pascoe@itee.uq.edu.au Subject: TAKE - xfsprogs-2.6.10 X-archive-position: 2740 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1438 Lines: 56 Note: this contains some very important mkfs fixes from Chris Pascoe for anyone creating filesystems with version 2 logs. This has been broken in cvs since the sb_features2 superblock field was introduced (March 17th). Thanks Chris! cheers. Make xfs_copy -d duplicate the log as well. Date: Sun Apr 4 19:26:57 PDT 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-cmds Inspected by: tes@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:169618a xfsprogs/copy/xfs_copy.c - 1.8 Get the units right for a forced 32K aligned v2 log stripe size. Date: Sun Apr 4 19:30:23 PDT 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-cmds Inspected by: c.pascoe@itee.uq.edu.au,tes@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:169619a xfsprogs/mkfs/xfs_mkfs.c - 1.56 Add in missing sb_features2 field into endian conversion table. Means v2 log filesystems are not created broken now by mkfs. Date: Sun Apr 4 19:33:16 PDT 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-cmds Inspected by: c.pascoe@itee.uq.edu.au,tes@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:169620a xfsprogs/VERSION - 1.104 xfsprogs/doc/CHANGES - 1.141 xfsprogs/debian/changelog - 1.94 xfsprogs/libxfs/xfs_mount.c - 1.18 From owner-linux-xfs@oss.sgi.com Sun Apr 4 20:12:58 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 04 Apr 2004 20:13:00 -0700 (PDT) Received: from omx2.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i353CwKO010821 for ; Sun, 4 Apr 2004 20:12:58 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i355HZFV005600 for ; Sun, 4 Apr 2004 22:17:35 -0700 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i353CgAL38092605; Mon, 5 Apr 2004 13:12:43 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i353CfpD37962225; Mon, 5 Apr 2004 13:12:41 +1000 (EST) Date: Mon, 5 Apr 2004 13:12:41 +1000 (EST) From: Nathan Scott Message-Id: <200404050312.i353CfpD37962225@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 912425 - ACL version errno X-archive-position: 2741 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 332 Lines: 13 Return the right error code on an ACL xattr version mismatch. Date: Sun Apr 4 20:12:16 PDT 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-linux Inspected by: agruen@suse.de The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:169622a xfs_acl.c - 1.49 From owner-linux-xfs@oss.sgi.com Sun Apr 4 20:22:05 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 04 Apr 2004 20:22:08 -0700 (PDT) Received: from omx1.americas.sgi.com (cfcafw.sgi.com [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i353M5KO014272 for ; Sun, 4 Apr 2004 20:22:05 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with SMTP id i3537bVC020603 for ; Sun, 4 Apr 2004 22:07:38 -0500 Received: from melbourne.sgi.com (omen.melbourne.sgi.com [134.14.55.139]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id NAA01223; Mon, 5 Apr 2004 13:07:33 +1000 Date: Mon, 5 Apr 2004 13:07:33 +1000 From: Ivan Rayner To: "Jacky Kim" Cc: "linux-xfs" Subject: Re: xfsdump media file size Message-Id: <20040405130733.0db6985d.ivanr@sgi.com> In-Reply-To: <200404040646.i346kpkt080088@mx2.sgi.com> References: <200404040646.i346kpkt080088@mx2.sgi.com> Organization: SGI X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; mips-sgi-irix6.5) Mime-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit X-archive-position: 2742 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ivanr@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1128 Lines: 34 On Sun, 4 Apr 2004 12:38:43 +0800, Jacky Kim wrote: > >> Because Linux 2.4 kernel has 2 GB file size limit, I want to backup some data > >> to severial regular files with limited size. > >> > >> I find that the '-d' option can specify the size of dump media files, so I try > >> the follow command: > >> > >> # xfsdump -l 0 -d 100 -f /backup/data -s data /home > >> > >> But it doesn't work, because the size of the media file(/backup/data) is much > >> larger then 100 megabytes. > >> > >> What can I do? > > > >Basically, you can't do that. Linux xfsdump only supports writing to > >multiple media files if it is writing to tape. You could probably use the > >split utility to do what you want. Eg. > > > > xfsdump -f - ... | split -b 100m > > > >And then you'll have to play a similar trick (probably using cat) to join > >them together for xfsrestore. > > But there is still the same problem: the totle size will exceed 2GB limit when > I join the splits together. You don't need to join them back together. You should be able to do something like: cat file1 file2 file3 | xfsrestore -f - ... Ivan From owner-linux-xfs@oss.sgi.com Sun Apr 4 22:34:11 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 04 Apr 2004 22:34:13 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i355YBKO017696 for ; Sun, 4 Apr 2004 22:34:11 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i355YBZ3017695 for linux-xfs@oss.sgi.com; Sun, 4 Apr 2004 22:34:11 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i355YAKQ017679 for ; Sun, 4 Apr 2004 22:34:10 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i3557HqT016790; Sun, 4 Apr 2004 22:07:17 -0700 Date: Sun, 4 Apr 2004 22:07:17 -0700 Message-Id: <200404050507.i3557HqT016790@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 311] ioctl hang in 2.6.x kernels with quota support X-Bugzilla-Reason: AssignedTo X-archive-position: 2743 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 620 Lines: 20 http://oss.sgi.com/bugzilla/show_bug.cgi?id=311 ------- Additional Comments From steven.wilton@team.eftel.com 2004-04-04 22:07 PDT ------- It loks like the bug may have been fixed in 2.6.5. I have run xfs_fsr without any problems a couple of times on the running filesystem - which used to cause the error fairly consistently. I can't get the kernel "warning, failed to lookup pages" error either, which also used to come up consistently while running the fsr (not sure if they're related). ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Apr 5 00:13:19 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 05 Apr 2004 00:14:06 -0700 (PDT) Received: from zok.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i357DIKO021917 for ; Mon, 5 Apr 2004 00:13:19 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id i3589ViQ011204 for ; Mon, 5 Apr 2004 01:09:31 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA05536; Mon, 5 Apr 2004 17:06:49 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i3576bpx206968; Mon, 5 Apr 2004 17:06:38 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id i3585cId009566; Mon, 5 Apr 2004 18:05:38 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i3585a0c009563; Mon, 5 Apr 2004 18:05:36 +1000 Date: Mon, 5 Apr 2004 18:05:36 +1000 From: Nathan Scott To: Carsten Gaebler Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: 2.4.25 XFS can't create files Message-ID: <20040405080536.GB9193@frodo> References: <406D20FE.8040701@snakefarm.org> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <406D20FE.8040701@snakefarm.org> User-Agent: Mutt/1.5.3i Content-Transfer-Encoding: 8bit X-archive-position: 2744 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 859 Lines: 23 On Fri, Apr 02, 2004 at 10:14:54AM +0200, Carsten Gaebler wrote: > Hi there, > > I have somewhat of an esoteric problem. I can create an XFS on an > external fibre channel RAID attached to an LSI fibre channel card > (Fusion MPT driver) but I can't create files or directories on that > filesystem (Permission denied). ext2/ext3 work fine on the same > partition, so I suspect this is an XFS+MPT issue. Thats very odd - the SGI CVS 2.4 kernel (that you reported working) is also at 2.4.25, and there's nothing in the XFS fixes/updates there that might be the cause of this, AFAICT. ACLs are not in Marcelo's tree, but that is unlikely to be the cause here (both cases are well tested). The only other thing I can suggest is a liberal sprinkling of printks on the sys_open path, till you find the spot thats returning this error.. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Apr 5 00:38:48 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 05 Apr 2004 00:38:50 -0700 (PDT) Received: from phoenix.infradead.org (phoenix.infradead.org [213.86.99.234]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i357ckKO026255 for ; Mon, 5 Apr 2004 00:38:47 -0700 Received: from hch by phoenix.infradead.org with local (Exim 4.30 #5 (Red Hat Linux)) id 1BAOgq-0000hK-4G; Mon, 05 Apr 2004 08:38:40 +0100 Date: Mon, 5 Apr 2004 08:38:39 +0100 From: Christoph Hellwig To: bart@samwel.tk Cc: linux-xfs@oss.sgi.com Subject: Re: [patch 1/1] Make XFS sysctl parameters use USER_HZ instead of HZ. Message-ID: <20040405083839.A2647@infradead.org> References: Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from bart@samwel.tk on Sat, Apr 03, 2004 at 01:12:40PM +0200 Content-Transfer-Encoding: 8bit X-archive-position: 2745 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 1204 Lines: 25 On Sat, Apr 03, 2004 at 01:12:40PM +0200, bart@samwel.tk wrote: > > From: Bart Samwel > > The sysctl parameters sync_interval, flush_interval and age_buffer are > in units of jiffies, which are very variable between kernels and > architectures. These parameters should use USER_HZ, which is meant for > use in external interfaces. > > Rationale: If there is no interface with a reliable unit, the laptop mode > control script can never work reliably, because it then needs to know the > value of HZ, which is intentionally not exported from the kernel anywhere. > > Possible improvement (matter of taste): renaming the variables, so that > old code knows that the new variables are in new units. I suggest to not > do this, because the variables previously didn't have any usable unit > anyway. Any code that was written against this interface had to assume > some HZ and would _have_ to have known that it would break with _any_ > change in HZ. I think this is problematic because schedule_timeout() expects these in units of HZ. So you need to re-unit them somewhere in the sysctl handler, IIRC the networking folks even added special sysctl handlers that do it automatically. From owner-linux-xfs@oss.sgi.com Mon Apr 5 00:40:52 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 05 Apr 2004 00:40:54 -0700 (PDT) Received: from phoenix.infradead.org (phoenix.infradead.org [213.86.99.234]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i357epKO026737 for ; Mon, 5 Apr 2004 00:40:52 -0700 Received: from hch by phoenix.infradead.org with local (Exim 4.30 #5 (Red Hat Linux)) id 1BAOiw-0000hh-Pa; Mon, 05 Apr 2004 08:40:50 +0100 Date: Mon, 5 Apr 2004 08:40:50 +0100 From: Christoph Hellwig To: bart@samwel.tk Cc: linux-xfs@oss.sgi.com Subject: Re: [patch 1/2] From: Bart Samwel Message-ID: <20040405084050.B2647@infradead.org> References: Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from bart@samwel.tk on Sat, Apr 03, 2004 at 03:36:09PM +0200 Content-Transfer-Encoding: 8bit X-archive-position: 2746 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 345 Lines: 7 > * Switch from keeping track of "flush time" to keeping track of "creation time" > for a pagebuf, so that changes in xfs_age_buffer can take effect immediately > instead of only for pagebufs whose flush time is set anew. looks good but doesn't apply against the XFS CVS tree which has some additional changes vs linus' tree in that area. From owner-linux-xfs@oss.sgi.com Mon Apr 5 00:46:32 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 05 Apr 2004 00:46:34 -0700 (PDT) Received: from phoenix.infradead.org (phoenix.infradead.org [213.86.99.234]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i357kTKO027336 for ; Mon, 5 Apr 2004 00:46:32 -0700 Received: from hch by phoenix.infradead.org with local (Exim 4.30 #5 (Red Hat Linux)) id 1BAOoO-0000j2-LT; Mon, 05 Apr 2004 08:46:28 +0100 Date: Mon, 5 Apr 2004 08:46:28 +0100 From: Christoph Hellwig To: bart@samwel.tk Cc: linux-xfs@oss.sgi.com Subject: Re: [patch 2/2] From: Bart Samwel Message-ID: <20040405084628.C2647@infradead.org> References: Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from bart@samwel.tk on Sat, Apr 03, 2004 at 03:36:15PM +0200 Content-Transfer-Encoding: 8bit X-archive-position: 2747 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 1205 Lines: 27 On Sat, Apr 03, 2004 at 03:36:15PM +0200, bart@samwel.tk wrote: > > > The XFS sync daemon is responsible for periodically syncing an XFS filesystem. > The problem: in laptop mode, this can kick in at any time and spin up the disk, > even when there is no other reason to do so. > > This patch wakes up the XFS sync daemon whenever an XFS syncfs takes place (e.g., > at sys_sync()) so that it does its job and then sleeps for as long as it can. It > does so only when laptop mode is active. Laptop mode calls sys_sync() to > perform a writeback just before the disk is spun down, so the XFS sync daemon will > be woken up just before the disk is spun down as well, and after that it will leave > the disk alone for a full lm_sync_interval. > > The patch also exports symbol laptop_mode, so that XFS can still be compiled as a > module. The idea behind this changes looks good, but I really dislike the way you implemented it. What about something like the following inside linvfs_sync_super instead of the current code? if (unlikely(laptop_mode)) VFS_SYNC(vfsp, SYNCD_FLAGS, NULL, error); this doesn't restart the sync sleep interval, but if it's large enough that shouldn't matter, should it? From owner-linux-xfs@oss.sgi.com Mon Apr 5 01:27:16 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 05 Apr 2004 01:27:21 -0700 (PDT) Received: from samwel.tk (kluizenaar.xs4all.nl [213.84.184.247]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i358RAKO029326 for ; Mon, 5 Apr 2004 01:27:15 -0700 Received: from localhost ([127.0.0.1] helo=samwel.tk) by samwel.tk with esmtp (Exim 4.30) id 1BAPRi-00061N-SE; Mon, 05 Apr 2004 10:27:07 +0200 Message-ID: <40711852.50809@samwel.tk> Date: Mon, 05 Apr 2004 10:26:58 +0200 From: Bart Samwel User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: nl, en-us, en MIME-Version: 1.0 To: Christoph Hellwig CC: linux-xfs@oss.sgi.com Subject: Re: [patch 2/2] From: Bart Samwel References: <20040405084628.C2647@infradead.org> In-Reply-To: <20040405084628.C2647@infradead.org> Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bart@samwel.tk X-SA-Exim-Scanned: No (on samwel.tk); SAEximRunCond expanded to false X-archive-position: 2748 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bart@samwel.tk Precedence: bulk X-list: linux-xfs Content-Length: 2146 Lines: 48 Christoph Hellwig wrote: > On Sat, Apr 03, 2004 at 03:36:15PM +0200, bart@samwel.tk wrote: > >> >>The XFS sync daemon is responsible for periodically syncing an XFS filesystem. >>The problem: in laptop mode, this can kick in at any time and spin up the disk, >>even when there is no other reason to do so. >> >>This patch wakes up the XFS sync daemon whenever an XFS syncfs takes place (e.g., >>at sys_sync()) so that it does its job and then sleeps for as long as it can. It >>does so only when laptop mode is active. Laptop mode calls sys_sync() to >>perform a writeback just before the disk is spun down, so the XFS sync daemon will >>be woken up just before the disk is spun down as well, and after that it will leave >>the disk alone for a full lm_sync_interval. >> >>The patch also exports symbol laptop_mode, so that XFS can still be compiled as a >>module. > > > The idea behind this changes looks good, but I really dislike the way you > implemented it. What about something like the following inside > linvfs_sync_super instead of the current code? > > if (unlikely(laptop_mode)) > VFS_SYNC(vfsp, SYNCD_FLAGS, NULL, error); > > this doesn't restart the sync sleep interval, but if it's large enough that > shouldn't matter, should it? It shouldn't, except that the whole point of the exercise is to restart the sync sleep interval, not to sync anything. ;) The problem with not having any synchronization between the laptop mode syncs and the xfssyncd is that the xfssyncd may wake up in the middle of a spun-down interval, and spin up the disk. Only restarting the sync sleep interval can solve that problem. :( Making the sync interval "large enough" would mean putting it at 6 hours or something, because then it wouldn't sync at all during any meaningful battery life of a laptop. If it's any lower than that, we get spurious spinups. And 6 hours may be just too long -- even in laptop mode, we _want_ forced syncs every now and then. For instance, we also increase the kupdate interval to (by default) 10 minutes, and my gut says the xfs sync sleep interval should be the same. What do you think? --Bart From owner-linux-xfs@oss.sgi.com Mon Apr 5 01:30:10 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 05 Apr 2004 01:30:13 -0700 (PDT) Received: from samwel.tk (kluizenaar.xs4all.nl [213.84.184.247]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i358U8KO029790 for ; Mon, 5 Apr 2004 01:30:09 -0700 Received: from localhost ([127.0.0.1] helo=samwel.tk) by samwel.tk with esmtp (Exim 4.30) id 1BAPUb-00065q-HU; Mon, 05 Apr 2004 10:30:05 +0200 Message-ID: <4071190A.4000500@samwel.tk> Date: Mon, 05 Apr 2004 10:30:02 +0200 From: Bart Samwel User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: nl, en-us, en MIME-Version: 1.0 To: Christoph Hellwig CC: linux-xfs@oss.sgi.com Subject: Re: [patch 1/2] From: Bart Samwel References: <20040405084050.B2647@infradead.org> In-Reply-To: <20040405084050.B2647@infradead.org> Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bart@samwel.tk X-SA-Exim-Scanned: No (on samwel.tk); SAEximRunCond expanded to false X-archive-position: 2749 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bart@samwel.tk Precedence: bulk X-list: linux-xfs Content-Length: 424 Lines: 15 Christoph Hellwig wrote: >>* Switch from keeping track of "flush time" to keeping track of "creation time" >> for a pagebuf, so that changes in xfs_age_buffer can take effect immediately >> instead of only for pagebufs whose flush time is set anew. > > > looks good but doesn't apply against the XFS CVS tree which has some > additional changes vs linus' tree in that area. I'll prepare a patch against CVS. --Bart From owner-linux-xfs@oss.sgi.com Mon Apr 5 01:33:55 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 05 Apr 2004 01:33:58 -0700 (PDT) Received: from samwel.tk (kluizenaar.xs4all.nl [213.84.184.247]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i358XsKO030294 for ; Mon, 5 Apr 2004 01:33:54 -0700 Received: from localhost ([127.0.0.1] helo=samwel.tk) by samwel.tk with esmtp (Exim 4.30) id 1BAPYE-0006AU-MP; Mon, 05 Apr 2004 10:33:50 +0200 Message-ID: <407119EB.4050101@samwel.tk> Date: Mon, 05 Apr 2004 10:33:47 +0200 From: Bart Samwel User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: nl, en-us, en MIME-Version: 1.0 To: Christoph Hellwig CC: linux-xfs@oss.sgi.com Subject: Re: [patch 1/1] Make XFS sysctl parameters use USER_HZ instead of HZ. References: <20040405083839.A2647@infradead.org> In-Reply-To: <20040405083839.A2647@infradead.org> Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bart@samwel.tk X-SA-Exim-Scanned: No (on samwel.tk); SAEximRunCond expanded to false X-archive-position: 2750 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bart@samwel.tk Precedence: bulk X-list: linux-xfs Content-Length: 1533 Lines: 41 Christoph Hellwig wrote: > On Sat, Apr 03, 2004 at 01:12:40PM +0200, bart@samwel.tk wrote: > >>From: Bart Samwel >> >>The sysctl parameters sync_interval, flush_interval and age_buffer are >>in units of jiffies, which are very variable between kernels and >>architectures. These parameters should use USER_HZ, which is meant for >>use in external interfaces. >> >>Rationale: If there is no interface with a reliable unit, the laptop mode >>control script can never work reliably, because it then needs to know the >>value of HZ, which is intentionally not exported from the kernel anywhere. >> >>Possible improvement (matter of taste): renaming the variables, so that >>old code knows that the new variables are in new units. I suggest to not >>do this, because the variables previously didn't have any usable unit >>anyway. Any code that was written against this interface had to assume >>some HZ and would _have_ to have known that it would break with _any_ >>change in HZ. > > > I think this is problematic because schedule_timeout() expects these in > units of HZ. So you need to re-unit them somewhere in the sysctl handler, > IIRC the networking folks even added special sysctl handlers that do it > automatically. The reunit code is there, e.g., for the sync interval there is: -#define xfs_syncd_interval xfs_params.sync_interval.val +#define xfs_syncd_interval (xfs_params.sync_interval.val * HZ / USER_HZ) So the xfs_params.XXX values are in USER_HZ, but the xfs_XXX values are in HZ. --Bart From owner-linux-xfs@oss.sgi.com Mon Apr 5 04:18:11 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 05 Apr 2004 04:18:38 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i35BIAKO010502 for ; Mon, 5 Apr 2004 04:18:10 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i35BI65D023362; Mon, 5 Apr 2004 07:18:06 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i35BI6j19236; Mon, 5 Apr 2004 07:18:06 -0400 Received: from [10.0.1.44] (sct.cipe.redhat.com [10.0.1.44]) by devserv.devel.redhat.com (8.12.10/8.12.10) with ESMTP id i35BHf1n010185; Mon, 5 Apr 2004 07:17:41 -0400 Subject: Re: file corruption From: "Stephen C. Tweedie" To: Chris Wedgwood Cc: Dmitry Nikiforov , Christian Rice , Dmitry Nikiforov , linux-xfs@oss.sgi.com, Stephen Tweedie In-Reply-To: <20040402044712.GB27240@dingdong.cryptoapps.com> References: <406AF7B6.6030405@dniq-online.com> <20040402001801.GA24900@dingdong.cryptoapps.com> <406CB95B.4040500@dniq-online.com> <20040402011618.GA25511@dingdong.cryptoapps.com> <406CC518.1090204@dniq-online.com> <20040402015022.GA25936@dingdong.cryptoapps.com> <406CCF08.9020309@tippett.com> <406CD88F.3070900@dniq-online.com> <20040402044712.GB27240@dingdong.cryptoapps.com> Content-type: text/plain Organization: Message-Id: <1081163884.1945.13.camel@sisko.scot.redhat.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 05 Apr 2004 12:18:04 +0100 Content-Transfer-Encoding: 8bit X-archive-position: 2752 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sct@redhat.com Precedence: bulk X-list: linux-xfs Content-Length: 1277 Lines: 32 Hi, On Fri, 2004-04-02 at 05:47, Chris Wedgwood wrote: > On Thu, Apr 01, 2004 at 09:05:51PM -0600, Dmitry Nikiforov wrote: > > > Then there's no point in using XFS at all, is there? :) > > This has nothing to do with XFS. All filesystems journalling and > otherwise are affected by this. No, it's entirely a matter of the fs implementation. Ext3 by default does not suffer from the problem, and it does _not_ have to journal its data to avoid it. It simply arranges to flush data to disk first, then metadata, when writing. Chris Mason also implemented such an "ordered" mode for Reiserfs, and I believe SuSE use that as the default in their kernels. And there are designs which are fundamentally immune to the problem. Both log-structured filesystems (such as jffs) and the tux2 experimental phase-tree-based filesystem that Daniel Phillips did a while back are guaranteed to hit disk in strict time order for both data and metadata. It's a compromise, though: phase-tree and log-structure filesystems are known to have serious fragmentation problems under some workloads. You wouldn't necessarily want to use them for your Oracle database. :-) But it's misleading to claim that all filesystems are necessarily affected by this sort of thing. Cheers, Stephen From owner-linux-xfs@oss.sgi.com Mon Apr 5 04:20:59 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 05 Apr 2004 04:21:09 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i35BKwKO013888 for ; Mon, 5 Apr 2004 04:20:59 -0700 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i35BKs5D024356; Mon, 5 Apr 2004 07:20:54 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i35BKsj19822; Mon, 5 Apr 2004 07:20:54 -0400 Received: from [10.0.1.44] (sct.cipe.redhat.com [10.0.1.44]) by devserv.devel.redhat.com (8.12.10/8.12.10) with ESMTP id i35BKT1n011025; Mon, 5 Apr 2004 07:20:29 -0400 Subject: Re: file corruption From: "Stephen C. Tweedie" To: stevew@catalyst.net.nz Cc: linux-xfs@oss.sgi.com, Stephen Tweedie In-Reply-To: <200404050759.02927.stevew@catalyst.net.nz> References: <406AF7B6.6030405@dniq-online.com> <406CC518.1090204@dniq-online.com> <20040402015022.GA25936@dingdong.cryptoapps.com> <200404050759.02927.stevew@catalyst.net.nz> Content-type: text/plain Organization: Message-Id: <1081164052.1945.17.camel@sisko.scot.redhat.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 05 Apr 2004 12:20:52 +0100 Content-Transfer-Encoding: 8bit X-archive-position: 2753 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sct@redhat.com Precedence: bulk X-list: linux-xfs Content-Length: 929 Lines: 25 Hi, On Sun, 2004-04-04 at 20:59, Steve Wray wrote: > > some fs' will journal all data though (reiserfs and ext3 can do > > this), but it often comes at a significant performance penalty for no > > real gain (and sometimes causes other problems like seeing old/stale > > data) > > This is why I use ext3 with data=journal on /var/log Why? The default "data=ordered" mode for ext3 is 100% identical to data=journal for the sorts of append-only file activity that you usually see in /var/log. The only visible difference between data=ordered and data=journal that you can expect after a power-failure is that for update-in-place operations, such as database updates, data=journal preserves strict write ordering but data=ordered does not. For newly allocated data --- new files or appends to old files --- data=ordered gives exactly the same benefit, without the performance penalty of writing the data twice. --Stephen From owner-linux-xfs@oss.sgi.com Mon Apr 5 12:54:12 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 05 Apr 2004 12:54:15 -0700 (PDT) Received: from samwel.tk (kluizenaar.xs4all.nl [213.84.184.247]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i35Js6KO021524 for ; Mon, 5 Apr 2004 12:54:11 -0700 Received: from bsamwel by samwel.tk with local (Exim 4.30) id 1BAaAS-0004nA-FO; Mon, 05 Apr 2004 21:54:00 +0200 Subject: Re: [patch 1/2] From: Bart Samwel From: Bart Samwel To: Christoph Hellwig Cc: XFS mailing list In-Reply-To: <20040405084050.B2647@infradead.org> References: <20040405084050.B2647@infradead.org> Content-type: text/plain Message-Id: <1081194839.2996.37.camel@samwel.tk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 05 Apr 2004 21:54:00 +0200 X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: bsamwel@samwel.tk X-SA-Exim-Scanned: No (on samwel.tk); SAEximRunCond expanded to false Content-Transfer-Encoding: 8bit X-archive-position: 2754 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bart@samwel.tk Precedence: bulk X-list: linux-xfs Content-Length: 569 Lines: 17 On Mon, 2004-04-05 at 09:40, Christoph Hellwig wrote: > > * Switch from keeping track of "flush time" to keeping track of "creation time" > > for a pagebuf, so that changes in xfs_age_buffer can take effect immediately > > instead of only for pagebufs whose flush time is set anew. > > looks good but doesn't apply against the XFS CVS tree which has some > additional changes vs linus' tree in that area. Attached patch is against the XFS CVS tree. --Bart -- Binary/unsupported file stripped by Ecartis -- -- Type: text/x-patch -- File: xfs-laptop-mode.patch From owner-linux-xfs@oss.sgi.com Mon Apr 5 12:56:34 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 05 Apr 2004 12:56:36 -0700 (PDT) Received: from samwel.tk (kluizenaar.xs4all.nl [213.84.184.247]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i35JuXKO021715 for ; Mon, 5 Apr 2004 12:56:33 -0700 Received: from localhost ([127.0.0.1] helo=localhost.localdomain) by samwel.tk with esmtp (Exim 4.30) id 1BAaCp-0004rN-GE; Mon, 05 Apr 2004 21:56:27 +0200 Subject: [patch 1/1] Laptop mode for XFS (patch against CVS) To: hch@infradead.org Cc: linux-xfs@oss.sgi.com, bart@samwel.tk From: bart@samwel.tk Date: Mon, 05 Apr 2004 21:56:24 +0200 Message-ID: X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bart@samwel.tk X-SA-Exim-Scanned: No (on samwel.tk); SAEximRunCond expanded to false X-archive-position: 2755 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bart@samwel.tk Precedence: bulk X-list: linux-xfs Content-Length: 3019 Lines: 78 From: Bart Samwel This is the same patch as earlier, but against the XFS CVS tree. Changelog: * Increase maximums for age_buffer and sync_interval so that values useful for laptop-mode are within the allowed range. * Switch from keeping track of "flush time" to keeping track of "creation time" for a pagebuf, so that changes in xfs_age_buffer can take effect immediately instead of only for pagebufs whose flush time is set anew. --- linux-2.6-xfs-bsamwel/fs/xfs/linux-2.6/xfs_buf.c | 4 ++-- linux-2.6-xfs-bsamwel/fs/xfs/linux-2.6/xfs_buf.h | 2 +- linux-2.6-xfs-bsamwel/fs/xfs/linux-2.6/xfs_globals.c | 4 ++-- 3 files changed, 5 insertions(+), 5 deletions(-) diff -puN fs/xfs/linux-2.6/xfs_buf.c~xfs-laptop-mode fs/xfs/linux-2.6/xfs_buf.c --- linux-2.6-xfs/fs/xfs/linux-2.6/xfs_buf.c~xfs-laptop-mode 2004-04-05 21:50:26.000000000 +0200 +++ linux-2.6-xfs-bsamwel/fs/xfs/linux-2.6/xfs_buf.c 2004-04-05 21:50:26.000000000 +0200 @@ -1497,7 +1497,7 @@ pagebuf_delwri_queue( } list_add_tail(&pb->pb_list, &pbd_delwrite_queue); - pb->pb_flushtime = jiffies + xfs_age_buffer; + pb->pb_creation_time = jiffies; spin_unlock(&pbd_delwrite_lock); if (unlock) @@ -1569,7 +1569,7 @@ pagebuf_daemon( if (!pagebuf_ispin(pb) && !pagebuf_cond_lock(pb)) { if (!force_flush && - time_before(jiffies, pb->pb_flushtime)) { + time_before(jiffies, pb->pb_creation_time + xfs_age_buffer)) { pagebuf_unlock(pb); break; } diff -puN fs/xfs/linux-2.6/xfs_buf.h~xfs-laptop-mode fs/xfs/linux-2.6/xfs_buf.h --- linux-2.6-xfs/fs/xfs/linux-2.6/xfs_buf.h~xfs-laptop-mode 2004-04-05 21:50:26.000000000 +0200 +++ linux-2.6-xfs-bsamwel/fs/xfs/linux-2.6/xfs_buf.h 2004-04-05 21:50:26.000000000 +0200 @@ -131,7 +131,7 @@ typedef int (*page_buf_bdstrat_t)(struct typedef struct xfs_buf { struct semaphore pb_sema; /* semaphore for lockables */ - unsigned long pb_flushtime; /* time to flush pagebuf */ + unsigned long pb_creation_time; /* time pagebuf was created */ atomic_t pb_pin_count; /* pin count */ wait_queue_head_t pb_waiters; /* unpin waiters */ struct list_head pb_list; diff -puN fs/xfs/linux-2.6/xfs_globals.c~xfs-laptop-mode fs/xfs/linux-2.6/xfs_globals.c --- linux-2.6-xfs/fs/xfs/linux-2.6/xfs_globals.c~xfs-laptop-mode 2004-04-05 21:50:26.000000000 +0200 +++ linux-2.6-xfs-bsamwel/fs/xfs/linux-2.6/xfs_globals.c 2004-04-05 21:50:26.000000000 +0200 @@ -56,7 +56,7 @@ xfs_param_t xfs_params = { .symlink_mode = { 0, 0, 1 }, .panic_mask = { 0, 0, 127 }, .error_level = { 0, 3, 11 }, - .sync_interval = { HZ, 30*HZ, 60*HZ }, + .sync_interval = { HZ, 30*HZ, 7200*HZ }, .probe_dmapi = { 0, 1, 1 }, .probe_ioops = { 0, 0, 1 }, .probe_quota = { 0, 1, 1 }, @@ -65,7 +65,7 @@ xfs_param_t xfs_params = { .inherit_nodump = { 0, 1, 1 }, .inherit_noatim = { 0, 1, 1 }, .flush_interval = { HZ/2, HZ, 30*HZ }, - .age_buffer = { 1*HZ, 15*HZ, 300*HZ }, + .age_buffer = { 1*HZ, 15*HZ, 7200*HZ }, }; /* _ From owner-linux-xfs@oss.sgi.com Mon Apr 5 15:45:35 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 05 Apr 2004 15:45:37 -0700 (PDT) Received: from omx2.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i35MjZKO030815 for ; Mon, 5 Apr 2004 15:45:35 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with SMTP id i360oJ85031505 for ; Mon, 5 Apr 2004 17:50:19 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA23888; Tue, 6 Apr 2004 08:45:27 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i35MjLpx216710; Tue, 6 Apr 2004 08:45:21 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id i35NiOQZ000797; Tue, 6 Apr 2004 09:44:24 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i35NiOGf000795; Tue, 6 Apr 2004 09:44:24 +1000 Date: Tue, 6 Apr 2004 09:44:23 +1000 From: Nathan Scott To: Bart Samwel Cc: XFS mailing list Subject: Re: [patch 1/2] From: Bart Samwel Message-ID: <20040405234423.GA648@frodo> References: <20040405084050.B2647@infradead.org> <1081194839.2996.37.camel@samwel.tk> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1081194839.2996.37.camel@samwel.tk> User-Agent: Mutt/1.5.3i Content-Transfer-Encoding: 8bit X-archive-position: 2756 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 974 Lines: 28 On Mon, Apr 05, 2004 at 09:54:00PM +0200, Bart Samwel wrote: > On Mon, 2004-04-05 at 09:40, Christoph Hellwig wrote: > > > * Switch from keeping track of "flush time" to keeping track of "creation time" > > > for a pagebuf, so that changes in xfs_age_buffer can take effect immediately > > > instead of only for pagebufs whose flush time is set anew. > > > > looks good but doesn't apply against the XFS CVS tree which has some > > additional changes vs linus' tree in that area. > Attached patch is against the XFS CVS tree. Minor thing in the original patch - could you name the field pb_queuetime instead of creation time? Also, could you resend (or send patch inline)... > -- Binary/unsupported file stripped by Ecartis -- > -- Type: text/x-patch > -- File: xfs-laptop-mode.patch I think Russell has just switched this Ecartis behavior off, so either should work. The other patches all came through fine as they were in the message body. thanks! -- Nathan From owner-linux-xfs@oss.sgi.com Mon Apr 5 16:38:52 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 05 Apr 2004 16:39:00 -0700 (PDT) Received: from omx2.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i35NcpKO003663 for ; Mon, 5 Apr 2004 16:38:52 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with SMTP id i361hYR6010709 for ; Mon, 5 Apr 2004 18:43:35 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.54.232]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA25083 for ; Tue, 6 Apr 2004 09:38:43 +1000 Received: from sherman.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by sherman.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id i35NcgmX003765 for ; Tue, 6 Apr 2004 09:38:43 +1000 Received: (from nathans@localhost) by sherman.melbourne.sgi.com (8.12.8/8.12.8/Submit) id i35NcgYg003763 for linux-xfs@oss.sgi.com; Tue, 6 Apr 2004 09:38:42 +1000 Date: Tue, 6 Apr 2004 09:38:42 +1000 From: Nathan Scott Message-Id: <200404052338.i35NcgYg003763@sherman.melbourne.sgi.com> Subject: TAKE 904196 - Merge up to 2.6.5 Apparently-To: X-archive-position: 2757 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sherman.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 73635 Lines: 2270 Date: Mon Apr 5 16:04:16 PDT 2004 Workarea: sherman.melbourne.sgi.com:/build/nathans/2.6.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: 2.6.x-xfs:linux:169701a drivers/net/wireless/prism54/Makefile - 1.1 drivers/net/wireless/prism54/isl_38xx.c - 1.1 drivers/net/wireless/prism54/isl_38xx.h - 1.1 drivers/net/wireless/prism54/isl_ioctl.c - 1.1 drivers/net/wireless/prism54/isl_ioctl.h - 1.1 drivers/net/wireless/prism54/isl_oid.h - 1.1 drivers/net/netconsole.c - 1.1 drivers/net/wireless/prism54/islpci_dev.c - 1.1 Documentation/arm/memory.txt - 1.1 drivers/net/wireless/prism54/islpci_dev.h - 1.1 drivers/net/wireless/prism54/islpci_eth.c - 1.1 drivers/message/fusion/lsi/mpi_tool.h - 1.1 drivers/message/fusion/lsi/mpi_sas.h - 1.1 drivers/message/fusion/lsi/mpi_inb.h - 1.1 drivers/net/wireless/prism54/islpci_eth.h - 1.1 drivers/net/wireless/prism54/islpci_hotplug.c - 1.1 drivers/net/wireless/prism54/islpci_mgt.c - 1.1 drivers/net/wireless/prism54/islpci_mgt.h - 1.1 drivers/net/wireless/prism54/oid_mgt.c - 1.1 drivers/net/wireless/prism54/oid_mgt.h - 1.1 drivers/macintosh/therm_adt746x.c - 1.1 drivers/parisc/iommu-helpers.h - 1.1 Documentation/mono.txt - 1.1 drivers/pci/hotplug/rpaphp_slot.c - 1.1 drivers/pci/hotplug/rpaphp_vio.c - 1.1 Documentation/networking/netconsole.txt - 1.1 Documentation/networking/packet_mmap.txt - 1.1 Documentation/power/tricks.txt - 1.1 drivers/input/serio/gscps2.c - 1.1 drivers/input/mouse/vsxxxaa.c - 1.1 drivers/input/keyboard/lkkbd.c - 1.1 drivers/scsi/qlogicfas.h - 1.1 drivers/scsi/sata_vsc.c - 1.1 drivers/ide/pci/atiixp.c - 1.1 drivers/scsi/scsi_transport_fc.c - 1.1 sound/pcmcia/pdaudiocf/pdaudiocf_pcm.c - 1.1 Documentation/sound/alsa/MIXART.txt - 1.1 Documentation/sound/alsa/Procfile.txt - 1.1 drivers/i2c/chips/w83627hf.c - 1.1 drivers/scsi/scsi_transport_spi.c - 1.1 drivers/scsi/sym53c8xx_2/sym_nvram.h - 1.1 drivers/i2c/chips/lm80.c - 1.1 drivers/serial/sh-sci.c - 1.1 Documentation/usb/mtouchusb.txt - 1.1 drivers/serial/sh-sci.h - 1.1 drivers/i2c/chips/ds1621.c - 1.1 drivers/usb/gadget/config.c - 1.1 drivers/usb/gadget/gadget_chips.h - 1.1 drivers/usb/input/ati_remote.c - 1.1 drivers/i2c/busses/i2c-ixp42x.c - 1.1 drivers/firmware/edd.c - 1.1 drivers/firmware/Makefile - 1.1 drivers/firmware/Kconfig - 1.1 drivers/usb/input/mtouchusb.c - 1.1 include/asm-h8300/dma-mapping.h - 1.1 include/asm-ppc/hawk.h - 1.1 drivers/char/viotape.c - 1.1 include/asm-ppc/hawk_defs.h - 1.1 drivers/char/agp/intel-mch-agp.c - 1.1 include/asm-sh/cpu-sh3/dac.h - 1.1 include/asm-sh/hp6xx/hp6xx.h - 1.1 include/asm-sparc/cpudata.h - 1.1 drivers/block/carmel.c - 1.1 include/linux/edd.h - 1.1 crypto/michael_mic.c - 1.1 include/linux/kref.h - 1.1 arch/x86_64/pci/mmconfig.c - 1.1 include/linux/netpoll.h - 1.1 arch/x86_64/ia32/vsyscall-sysenter.S - 1.1 arch/x86_64/ia32/vsyscall-syscall.S - 1.1 arch/x86_64/ia32/vsyscall-sigreturn.S - 1.1 include/scsi/scsi_transport.h - 1.1 arch/sh/mm/hugetlbpage.c - 1.1 arch/sh/mm/consistent.c - 1.1 include/scsi/scsi_transport_fc.h - 1.1 include/scsi/scsi_transport_spi.h - 1.1 include/sound/ak4117.h - 1.1 ipc/compat.c - 1.1 lib/kref.c - 1.1 net/core/netpoll.c - 1.1 net/ipv6/exthdrs_core.c - 1.1 net/sched/sch_delay.c - 1.1 scripts/basic/Makefile - 1.1 scripts/basic/docproc.c - 1.1 arch/sh/configs/systemh_defconfig - 1.1 arch/sh/configs/snapgear_defconfig - 1.1 arch/sh/configs/se7751_defconfig - 1.1 arch/sh/configs/hp680_defconfig - 1.1 arch/sh/configs/dreamcast_defconfig - 1.1 sound/pcmcia/pdaudiocf/pdaudiocf_irq.c - 1.1 scripts/basic/fixdep.c - 1.1 scripts/basic/split-include.c - 1.1 security/selinux/include/conditional.h - 1.1 security/selinux/ss/conditional.c - 1.1 arch/sh/configs/cqreek_defconfig - 1.1 arch/sh/configs/adx_defconfig - 1.1 security/selinux/ss/conditional.h - 1.1 sound/i2c/other/ak4117.c - 1.1 sound/oss/sh_dac_audio.c - 1.1 sound/pci/atiixp.c - 1.1 sound/pci/au88x0/Makefile - 1.1 sound/pci/au88x0/au8810.c - 1.1 sound/pci/au88x0/au8810.h - 1.1 sound/pci/au88x0/au8820.c - 1.1 sound/pci/au88x0/au8820.h - 1.1 sound/pci/au88x0/au8830.c - 1.1 sound/pci/au88x0/au8830.h - 1.1 sound/pci/au88x0/au88x0.c - 1.1 sound/pci/au88x0/au88x0.h - 1.1 sound/pci/au88x0/au88x0_a3d.c - 1.1 sound/pci/au88x0/au88x0_a3d.h - 1.1 sound/pci/au88x0/au88x0_a3ddata.c - 1.1 sound/pci/au88x0/au88x0_core.c - 1.1 sound/pci/au88x0/au88x0_eq.c - 1.1 arch/ppc64/kernel/dma.c - 1.1 sound/pci/au88x0/au88x0_eq.h - 1.1 sound/pci/au88x0/au88x0_eqdata.c - 1.1 sound/pci/au88x0/au88x0_game.c - 1.1 arch/ppc/platforms/spruce.c - 1.1 arch/ppc/platforms/pplus.h - 1.1 arch/ppc/platforms/pplus.c - 1.1 arch/ppc/boot/simple/mpc10x_memory.c - 1.1 arch/ppc/boot/simple/misc-prep.c - 1.1 arch/ppc/boot/simple/cpc700_memory.c - 1.1 arch/ppc/boot/lib/vreset.c - 1.1 arch/ppc/boot/lib/kbd.c - 1.1 arch/ppc/boot/include/iso_font.h - 1.1 sound/pci/au88x0/au88x0_mixer.c - 1.1 arch/parisc/configs/b180_defconfig - 1.1 sound/pci/au88x0/au88x0_mpu401.c - 1.1 sound/pci/au88x0/au88x0_pcm.c - 1.1 sound/pci/au88x0/au88x0_sb.h - 1.1 sound/pci/au88x0/au88x0_synth.c - 1.1 sound/pci/au88x0/au88x0_wt.h - 1.1 arch/h8300/kernel/ints.c - 1.1 sound/pci/au88x0/au88x0_xtalk.c - 1.1 sound/pci/au88x0/au88x0_xtalk.h - 1.1 sound/pci/intel8x0m.c - 1.1 sound/pci/mixart/Makefile - 1.1 sound/pci/mixart/mixart.c - 1.1 sound/pci/mixart/mixart.h - 1.1 sound/pci/mixart/mixart_core.c - 1.1 sound/pci/mixart/mixart_core.h - 1.1 sound/pci/mixart/mixart_hwdep.c - 1.1 sound/pci/mixart/mixart_hwdep.h - 1.1 arch/h8300/platform/h8300h/ints_h8300h.c - 1.1 sound/pci/mixart/mixart_mixer.c - 1.1 sound/pci/mixart/mixart_mixer.h - 1.1 sound/pcmcia/pdaudiocf/Makefile - 1.1 arch/h8300/platform/h8s/ints_h8s.c - 1.1 sound/pcmcia/pdaudiocf/pdaudiocf.c - 1.1 arch/i386/boot/edd.S - 1.1 arch/ia64/configs/zx1_defconfig - 1.1 sound/pcmcia/pdaudiocf/pdaudiocf.h - 1.1 sound/pcmcia/pdaudiocf/pdaudiocf_core.c - 1.1 CREDITS - 1.6 Documentation/DMA-API.txt - 1.3 Documentation/DMA-mapping.txt - 1.2 Documentation/DocBook/Makefile - 1.2 Documentation/DocBook/gadget.tmpl - 1.2 Documentation/DocBook/parportbook.tmpl - 1.2 Documentation/SubmittingDrivers - 1.3 Documentation/arm/README - 1.2 Documentation/computone.txt - 1.3 Documentation/crypto/api-intro.txt - 1.3 Documentation/devices.txt - 1.3 Documentation/filesystems/udf.txt - 1.2 Documentation/filesystems/ufs.txt - 1.2 Documentation/i2c/sysfs-interface - 1.3 Documentation/i386/zero-page.txt - 1.5 Documentation/ide.txt - 1.3 Documentation/input/joystick-parport.txt - 1.2 Documentation/input/joystick.txt - 1.2 Documentation/java.txt - 1.2 Documentation/kbuild/makefiles.txt - 1.2 Documentation/kernel-parameters.txt - 1.6 Documentation/networking/bonding.txt - 1.4 Documentation/networking/e100.txt - 1.2 Documentation/s390/driver-model.txt - 1.4 Documentation/scsi/st.txt - 1.4 Documentation/scsi/sym53c8xx_2.txt - 1.2 Documentation/sh/new-machine.txt - 1.3 Documentation/sound/alsa/ALSA-Configuration.txt - 1.3 Documentation/sound/alsa/DocBook/alsa-driver-api.tmpl - 1.2 Documentation/sound/alsa/DocBook/writing-an-alsa-driver.tmpl - 1.4 Documentation/sound/rme96xx - 1.2 Documentation/sysctl/vm.txt - 1.3 Documentation/usb/acm.txt - 1.2 Documentation/usb/brlvger.txt - 1.2 Documentation/usb/error-codes.txt - 1.2 Documentation/usb/scanner.txt - 1.3 Documentation/x86_64/boot-options.txt - 1.3 MAINTAINERS - 1.6 Makefile - 1.17 arch/alpha/Kconfig - 1.4 arch/alpha/boot/misc.c - 1.3 arch/alpha/defconfig - 1.3 arch/alpha/kernel/setup.c - 1.2 arch/alpha/kernel/smp.c - 1.2 arch/alpha/kernel/sys_nautilus.c - 1.2 arch/alpha/kernel/time.c - 1.3 arch/alpha/kernel/traps.c - 1.2 arch/alpha/lib/dec_and_lock.c - 1.2 arch/alpha/mm/numa.c - 1.2 arch/arm/Kconfig - 1.4 arch/arm/Makefile - 1.4 arch/arm/boot/Makefile - 1.2 arch/arm/boot/compressed/Makefile - 1.3 arch/arm/common/amba.c - 1.5 arch/arm/common/sa1111-pcibuf.c - 1.3 arch/arm/common/sa1111.c - 1.4 arch/arm/configs/a5k_defconfig - 1.2 arch/arm/configs/adi_evb_defconfig - 1.2 arch/arm/configs/adsbitsy_defconfig - 1.2 arch/arm/configs/assabet_defconfig - 1.2 arch/arm/configs/badge4_defconfig - 1.2 arch/arm/configs/cerfcube_defconfig - 1.3 arch/arm/configs/clps7500_defconfig - 1.2 arch/arm/configs/ebsa110_defconfig - 1.2 arch/arm/configs/epxa10db_defconfig - 1.2 arch/arm/configs/flexanet_defconfig - 1.2 arch/arm/configs/footbridge_defconfig - 1.3 arch/arm/configs/fortunet_defconfig - 1.2 arch/arm/configs/graphicsclient_defconfig - 1.2 arch/arm/configs/graphicsmaster_defconfig - 1.2 arch/arm/configs/h3600_defconfig - 1.2 arch/arm/configs/hackkit_defconfig - 1.2 arch/arm/configs/integrator_defconfig - 1.2 arch/arm/configs/iq80310_defconfig - 1.2 arch/arm/configs/iq80321_defconfig - 1.3 arch/arm/configs/jornada720_defconfig - 1.2 arch/arm/configs/lart_defconfig - 1.2 arch/arm/configs/lubbock_defconfig - 1.2 arch/arm/configs/lusl7200_defconfig - 1.2 arch/arm/configs/neponset_defconfig - 1.2 arch/arm/configs/pangolin_defconfig - 1.2 arch/arm/configs/pfs168_mqtft_defconfig - 1.2 arch/arm/configs/pfs168_mqvga_defconfig - 1.2 arch/arm/configs/pfs168_sastn_defconfig - 1.2 arch/arm/configs/pfs168_satft_defconfig - 1.2 arch/arm/configs/pleb_defconfig - 1.2 arch/arm/configs/rpc_defconfig - 1.2 arch/arm/configs/shannon_defconfig - 1.2 arch/arm/configs/shark_defconfig - 1.3 arch/arm/configs/stork_defconfig - 1.2 arch/arm/configs/system3_defconfig - 1.2 arch/arm/configs/trizeps_defconfig - 1.2 arch/arm/kernel/Makefile - 1.3 arch/arm/kernel/armksyms.c - 1.4 arch/arm/kernel/debug.S - 1.2 arch/arm/kernel/entry-armv.S - 1.3 arch/arm/kernel/sys_arm.c - 1.3 arch/arm/kernel/time.c - 1.4 arch/arm/kernel/traps.c - 1.2 arch/arm/lib/Makefile - 1.2 arch/arm/mach-anakin/Makefile - 1.2 arch/arm/mach-anakin/arch.c - 1.2 arch/arm/mach-anakin/irq.c - 1.2 arch/arm/mach-anakin/mm.c - 1.2 arch/arm/mach-sa1100/Kconfig - 1.4 arch/arm/mach-sa1100/adsbitsy.c - 1.2 arch/arm/mach-sa1100/badge4.c - 1.2 arch/arm/mach-sa1100/generic.c - 1.5 arch/arm/mach-sa1100/graphicsmaster.c - 1.2 arch/arm/mach-sa1100/jornada720.c - 1.2 arch/arm/mach-sa1100/neponset.c - 1.3 arch/arm/mach-sa1100/pfs168.c - 1.2 arch/arm/mach-sa1100/system3.c - 1.2 arch/arm/mach-sa1100/xp860.c - 1.2 arch/arm/mm/Kconfig - 1.4 arch/arm/mm/consistent.c - 1.2 arch/arm/mm/fault-common.c - 1.2 arch/arm/tools/mach-types - 1.3 arch/arm26/Kconfig - 1.3 arch/arm26/defconfig - 1.2 arch/arm26/kernel/sys_arm.c - 1.3 arch/cris/kernel/process.c - 1.2 arch/h8300/Kconfig - 1.4 arch/h8300/kernel/Makefile - 1.2 arch/h8300/kernel/setup.c - 1.2 arch/h8300/kernel/sys_h8300.c - 1.3 arch/h8300/kernel/syscalls.S - 1.2 arch/h8300/mm/init.c - 1.2 arch/h8300/platform/h8300h/Makefile - 1.3 arch/h8300/platform/h8300h/aki3068net/Makefile - 1.3 arch/h8300/platform/h8300h/generic/Makefile - 1.3 arch/h8300/platform/h8300h/generic/timer.c - 1.3 arch/h8300/platform/h8300h/h8max/Makefile - 1.3 arch/h8300/platform/h8300h/ints.c - 1.4 arch/h8300/platform/h8s/Makefile - 1.3 arch/h8300/platform/h8s/edosk2674/Makefile - 1.3 arch/h8300/platform/h8s/generic/Makefile - 1.3 arch/i386/Kconfig - 1.9 arch/i386/boot/setup.S - 1.5 arch/i386/boot/tools/build.c - 1.2 arch/i386/defconfig - 1.6 arch/i386/kernel/Makefile - 1.4 arch/i386/kernel/acpi/boot.c - 1.8 arch/i386/kernel/apm.c - 1.4 arch/i386/kernel/asm-offsets.c - 1.2 arch/i386/kernel/bootflag.c - 1.3 arch/i386/kernel/cpu/mcheck/mce.c - 1.3 arch/i386/kernel/dmi_scan.c - 1.4 arch/i386/kernel/edd.c - 1.4 arch/i386/kernel/entry.S - 1.6 arch/i386/kernel/head.S - 1.3 arch/i386/kernel/i386_ksyms.c - 1.3 arch/i386/kernel/i8259.c - 1.7 arch/i386/kernel/init_task.c - 1.2 arch/i386/kernel/io_apic.c - 1.8 arch/i386/kernel/mpparse.c - 1.7 arch/i386/kernel/nmi.c - 1.6 arch/i386/kernel/pci-dma.c - 1.2 arch/i386/kernel/process.c - 1.5 arch/i386/kernel/reboot.c - 1.6 arch/i386/kernel/setup.c - 1.6 arch/i386/kernel/smp.c - 1.6 arch/i386/kernel/smpboot.c - 1.7 arch/i386/kernel/timers/timer_tsc.c - 1.4 arch/i386/kernel/trampoline.S - 1.2 arch/i386/kernel/traps.c - 1.6 arch/i386/kernel/vmlinux.lds.S - 1.5 arch/i386/kernel/vsyscall-int80.S - 1.2 arch/i386/kernel/vsyscall-sigreturn.S - 1.2 arch/i386/kernel/vsyscall-sysenter.S - 1.2 arch/i386/lib/Makefile - 1.2 arch/i386/lib/iodebug.c - 1.2 arch/i386/mach-default/Makefile - 1.2 arch/i386/mach-es7000/Makefile - 1.2 arch/i386/mach-pc9800/Makefile - 1.2 arch/i386/mach-visws/Makefile - 1.2 arch/i386/mach-voyager/voyager_smp.c - 1.3 arch/i386/mm/discontig.c - 1.2 arch/i386/mm/hugetlbpage.c - 1.3 arch/i386/mm/init.c - 1.3 arch/ia64/Kconfig - 1.6 arch/ia64/defconfig - 1.6 arch/ia64/hp/common/sba_iommu.c - 1.5 arch/ia64/hp/sim/simscsi.c - 1.2 arch/ia64/hp/sim/simscsi.h - 1.2 arch/ia64/hp/sim/simserial.c - 1.2 arch/ia64/ia32/ia32_entry.S - 1.3 arch/ia64/ia32/ia32_support.c - 1.2 arch/ia64/ia32/sys_ia32.c - 1.5 arch/ia64/kernel/Makefile - 1.4 arch/ia64/kernel/acpi.c - 1.8 arch/ia64/kernel/efi.c - 1.4 arch/ia64/kernel/gate.S - 1.3 arch/ia64/kernel/head.S - 1.4 arch/ia64/kernel/iosapic.c - 1.5 arch/ia64/kernel/irq_ia64.c - 1.4 arch/ia64/kernel/machvec.c - 1.3 arch/ia64/kernel/mca.c - 1.4 arch/ia64/kernel/process.c - 1.4 arch/ia64/kernel/sal.c - 1.3 arch/ia64/kernel/setup.c - 1.4 arch/ia64/kernel/smp.c - 1.4 arch/ia64/kernel/smpboot.c - 1.6 arch/ia64/kernel/time.c - 1.4 arch/ia64/kernel/traps.c - 1.4 arch/ia64/kernel/unaligned.c - 1.4 arch/ia64/kernel/unwind.c - 1.5 arch/ia64/kernel/vmlinux.lds.S - 1.3 arch/ia64/lib/swiotlb.c - 1.2 arch/ia64/mm/contig.c - 1.2 arch/ia64/mm/discontig.c - 1.5 arch/ia64/mm/extable.c - 1.4 arch/ia64/mm/fault.c - 1.3 arch/ia64/mm/hugetlbpage.c - 1.4 arch/ia64/mm/init.c - 1.5 arch/ia64/pci/pci.c - 1.5 arch/ia64/sn/fakeprom/fw-emu.c - 1.2 arch/ia64/sn/io/hwgfs/ramfs.c - 1.3 arch/ia64/sn/io/machvec/pci_dma.c - 1.5 arch/ia64/sn/io/sn2/pcibr/pcibr_dvr.c - 1.5 arch/ia64/sn/io/sn2/pcibr/pcibr_intr.c - 1.5 arch/ia64/sn/io/sn2/pciio.c - 1.4 arch/ia64/sn/io/sn2/pic.c - 1.5 arch/ia64/sn/io/sn2/shub.c - 1.4 arch/ia64/sn/io/sn2/shub_intr.c - 1.4 arch/ia64/sn/kernel/irq.c - 1.5 arch/ia64/sn/kernel/mca.c - 1.5 arch/ia64/sn/kernel/setup.c - 1.6 arch/ia64/sn/kernel/sn2/sn_proc_fs.c - 1.4 arch/m68k/amiga/amiints.c - 1.2 arch/m68k/bvme6000/bvmeints.c - 1.2 arch/m68k/hp300/time.c - 1.2 arch/m68k/kernel/entry.S - 1.3 arch/m68k/kernel/ints.c - 1.3 arch/m68k/kernel/sys_m68k.c - 1.3 arch/m68k/mac/iop.c - 1.3 arch/m68k/mac/macints.c - 1.3 arch/m68k/mac/oss.c - 1.2 arch/m68k/mac/psc.c - 1.2 arch/m68k/mac/via.c - 1.3 arch/m68k/mvme16x/16xints.c - 1.2 arch/m68k/q40/config.c - 1.2 arch/m68k/q40/q40ints.c - 1.3 arch/m68k/sun3/sun3ints.c - 1.2 arch/m68knommu/kernel/sys_m68k.c - 1.3 arch/m68knommu/kernel/syscalltable.S - 1.2 arch/mips/Kconfig - 1.5 arch/mips/kernel/sysirix.c - 1.3 arch/parisc/Kconfig - 1.4 arch/parisc/defconfig - 1.3 arch/parisc/hpux/entry_hpux.S - 1.2 arch/parisc/kernel/drivers.c - 1.4 arch/parisc/kernel/entry.S - 1.3 arch/parisc/kernel/hardware.c - 1.3 arch/parisc/kernel/head64.S - 1.4 arch/parisc/kernel/module.c - 1.2 arch/parisc/kernel/pacache.S - 1.4 arch/parisc/kernel/parisc_ksyms.c - 1.5 arch/parisc/kernel/pci-dma.c - 1.3 arch/parisc/kernel/pci.c - 1.3 arch/parisc/kernel/process.c - 1.4 arch/parisc/kernel/smp.c - 1.3 arch/parisc/kernel/sys_parisc.c - 1.6 arch/parisc/kernel/sys_parisc32.c - 1.4 arch/parisc/kernel/syscall_table.S - 1.4 arch/parisc/kernel/vmlinux.lds.S - 1.3 arch/ppc/Kconfig - 1.6 arch/ppc/boot/Makefile - 1.2 arch/ppc/boot/common/Makefile - 1.2 arch/ppc/boot/common/cpc700_memory.c - 1.2 arch/ppc/boot/common/mpc10x_memory.c - 1.2 arch/ppc/boot/common/util.S - 1.2 arch/ppc/boot/ld.script - 1.2 arch/ppc/boot/lib/Makefile - 1.2 arch/ppc/boot/openfirmware/Makefile - 1.2 arch/ppc/boot/prep/Makefile - 1.3 arch/ppc/boot/prep/dummy.c - 1.2 arch/ppc/boot/prep/head.S - 1.3 arch/ppc/boot/prep/iso_font.h - 1.2 arch/ppc/boot/prep/kbd.c - 1.2 arch/ppc/boot/prep/misc.c - 1.3 arch/ppc/boot/prep/vreset.c - 1.2 arch/ppc/boot/simple/Makefile - 1.4 arch/ppc/boot/simple/head.S - 1.2 arch/ppc/boot/simple/misc-spruce.c - 1.3 arch/ppc/boot/simple/misc.c - 1.3 arch/ppc/boot/simple/relocate.S - 1.2 arch/ppc/boot/utils/mkprep.c - 1.3 arch/ppc/configs/ash_defconfig - 1.2 arch/ppc/configs/cedar_defconfig - 1.2 arch/ppc/configs/common_defconfig - 1.3 arch/ppc/configs/cpci405_defconfig - 1.2 arch/ppc/configs/ebony_defconfig - 1.2 arch/ppc/configs/pmac_defconfig - 1.3 arch/ppc/configs/power3_defconfig - 1.2 arch/ppc/configs/pplus_defconfig - 1.2 arch/ppc/configs/rainier_defconfig - 1.2 arch/ppc/configs/redwood5_defconfig - 1.2 arch/ppc/configs/walnut_defconfig - 1.2 arch/ppc/defconfig - 1.3 arch/ppc/kernel/align.c - 1.2 arch/ppc/kernel/cputable.c - 1.2 arch/ppc/kernel/entry.S - 1.3 arch/ppc/kernel/head.S - 1.5 arch/ppc/kernel/head_44x.S - 1.3 arch/ppc/kernel/misc.S - 1.5 arch/ppc/kernel/pci.c - 1.4 arch/ppc/kernel/ppc_ksyms.c - 1.5 arch/ppc/kernel/process.c - 1.2 arch/ppc/kernel/ptrace.c - 1.2 arch/ppc/kernel/signal.c - 1.3 arch/ppc/kernel/smp.c - 1.4 arch/ppc/kernel/traps.c - 1.2 arch/ppc/mm/cachemap.c - 1.3 arch/ppc/mm/pgtable.c - 1.3 arch/ppc/platforms/Makefile - 1.4 arch/ppc/platforms/chrp_smp.c - 1.2 arch/ppc/platforms/pmac_feature.c - 1.4 arch/ppc/platforms/pmac_smp.c - 1.3 arch/ppc/platforms/pplus_pci.c - 1.2 arch/ppc/platforms/pplus_setup.c - 1.2 arch/ppc/platforms/prep_setup.c - 1.3 arch/ppc/platforms/proc_rtas.c - 1.2 arch/ppc/platforms/spruce.h - 1.3 arch/ppc/platforms/spruce_pci.c - 1.2 arch/ppc/platforms/spruce_serial.h - 1.2 arch/ppc/platforms/spruce_setup.c - 1.3 arch/ppc/syslib/gen550_dbg.c - 1.3 arch/ppc/syslib/indirect_pci.c - 1.2 arch/ppc/syslib/pplus_common.c - 1.2 arch/ppc/syslib/todc_time.c - 1.2 arch/ppc64/Kconfig - 1.6 arch/ppc64/Makefile - 1.4 arch/ppc64/defconfig - 1.4 arch/ppc64/kernel/HvCall.c - 1.3 arch/ppc64/kernel/HvLpConfig.c - 1.2 arch/ppc64/kernel/Makefile - 1.6 arch/ppc64/kernel/bitops.c - 1.2 arch/ppc64/kernel/chrp_setup.c - 1.5 arch/ppc64/kernel/eeh.c - 1.4 arch/ppc64/kernel/entry.S - 1.4 arch/ppc64/kernel/head.S - 1.7 arch/ppc64/kernel/iSeries_VpdInfo.c - 1.4 arch/ppc64/kernel/iSeries_pci.c - 1.5 arch/ppc64/kernel/iSeries_pci_reset.c - 1.3 arch/ppc64/kernel/iSeries_proc.c - 1.3 arch/ppc64/kernel/iSeries_setup.c - 1.5 arch/ppc64/kernel/idle.c - 1.5 arch/ppc64/kernel/ioctl32.c - 1.3 arch/ppc64/kernel/irq.c - 1.5 arch/ppc64/kernel/mf.c - 1.4 arch/ppc64/kernel/mf_proc.c - 1.4 arch/ppc64/kernel/misc.S - 1.5 arch/ppc64/kernel/pSeries_lpar.c - 1.6 arch/ppc64/kernel/pSeries_pci.c - 1.6 arch/ppc64/kernel/pci.c - 1.5 arch/ppc64/kernel/pci.h - 1.2 arch/ppc64/kernel/pmc.c - 1.2 arch/ppc64/kernel/ppc_ksyms.c - 1.6 arch/ppc64/kernel/proc_pmc.c - 1.4 arch/ppc64/kernel/proc_ppc64.c - 1.5 arch/ppc64/kernel/process.c - 1.6 arch/ppc64/kernel/prom.c - 1.7 arch/ppc64/kernel/ras.c - 1.4 arch/ppc64/kernel/rtas-proc.c - 1.6 arch/ppc64/kernel/rtas.c - 1.4 arch/ppc64/kernel/rtas_flash.c - 1.5 arch/ppc64/kernel/rtasd.c - 1.5 arch/ppc64/kernel/scanlog.c - 1.5 arch/ppc64/kernel/setup.c - 1.7 arch/ppc64/kernel/smp.c - 1.6 arch/ppc64/kernel/sys_ppc32.c - 1.6 arch/ppc64/kernel/traps.c - 1.5 arch/ppc64/kernel/xics.c - 1.5 arch/ppc64/mm/hugetlbpage.c - 1.6 arch/ppc64/mm/init.c - 1.5 arch/ppc64/mm/numa.c - 1.5 arch/ppc64/xmon/xmon.c - 1.6 arch/s390/Kconfig - 1.4 arch/s390/defconfig - 1.5 arch/s390/kernel/asm-offsets.c - 1.2 arch/s390/kernel/binfmt_elf32.c - 1.3 arch/s390/kernel/compat_linux.c - 1.5 arch/s390/kernel/compat_linux.h - 1.4 arch/s390/kernel/compat_signal.c - 1.3 arch/s390/kernel/compat_wrapper.S - 1.5 arch/s390/kernel/entry.S - 1.3 arch/s390/kernel/entry64.S - 1.3 arch/s390/kernel/process.c - 1.3 arch/s390/kernel/ptrace.c - 1.3 arch/s390/kernel/s390_ksyms.c - 1.4 arch/s390/kernel/setup.c - 1.4 arch/s390/kernel/signal.c - 1.3 arch/s390/kernel/sys_s390.c - 1.4 arch/s390/kernel/syscalls.S - 1.4 arch/s390/kernel/traps.c - 1.4 arch/s390/lib/uaccess.S - 1.3 arch/s390/lib/uaccess64.S - 1.3 arch/s390/mm/fault.c - 1.3 arch/s390/mm/init.c - 1.4 arch/sh/Kconfig - 1.6 arch/sh/Makefile - 1.3 arch/sh/boards/hp6xx/hp680/mach.c - 1.4 arch/sh/boards/se/770x/io.c - 1.3 arch/sh/boards/se/770x/irq.c - 1.2 arch/sh/cchips/hd6446x/hd64461/io.c - 1.4 arch/sh/cchips/hd6446x/hd64461/setup.c - 1.3 arch/sh/configs/defconfig-adx - 1.3 arch/sh/configs/defconfig-cqreek - 1.3 arch/sh/configs/defconfig-dreamcast - 1.3 arch/sh/defconfig - 1.3 arch/sh/kernel/cf-enabler.c - 1.2 arch/sh/kernel/cpu/irq_ipr.c - 1.2 arch/sh/kernel/entry.S - 1.4 arch/sh/kernel/io.c - 1.3 arch/sh/kernel/module.c - 1.3 arch/sh/kernel/process.c - 1.4 arch/sh/kernel/sh_ksyms.c - 1.3 arch/sh/kernel/sys_sh.c - 1.4 arch/sh/kernel/time.c - 1.3 arch/sh/kernel/traps.c - 1.3 arch/sh/mm/Makefile - 1.3 arch/sh/mm/cache-sh4.c - 1.3 arch/sh/mm/init.c - 1.3 arch/sh/mm/ioremap.c - 1.3 arch/sh/mm/tlb-sh4.c - 1.2 arch/sparc/Kconfig - 1.6 arch/sparc/Makefile - 1.4 arch/sparc/boot/Makefile - 1.3 arch/sparc/defconfig - 1.2 arch/sparc/kernel/cpu.c - 1.2 arch/sparc/kernel/devices.c - 1.2 arch/sparc/kernel/entry.S - 1.4 arch/sparc/kernel/head.S - 1.3 arch/sparc/kernel/init_task.c - 1.2 arch/sparc/kernel/ioport.c - 1.2 arch/sparc/kernel/module.c - 1.2 arch/sparc/kernel/process.c - 1.5 arch/sparc/kernel/setup.c - 1.4 arch/sparc/kernel/signal.c - 1.4 arch/sparc/kernel/smp.c - 1.4 arch/sparc/kernel/sparc_ksyms.c - 1.5 arch/sparc/kernel/sun4d_irq.c - 1.4 arch/sparc/kernel/sun4d_smp.c - 1.2 arch/sparc/kernel/sun4m_irq.c - 1.3 arch/sparc/kernel/sun4m_smp.c - 1.2 arch/sparc/kernel/sys_sunos.c - 1.3 arch/sparc/kernel/traps.c - 1.5 arch/sparc/lib/Makefile - 1.3 arch/sparc/lib/debuglocks.c - 1.2 arch/sparc/math-emu/math.c - 1.2 arch/sparc/mm/init.c - 1.3 arch/sparc/mm/srmmu.c - 1.6 arch/sparc/mm/sun4c.c - 1.4 arch/sparc64/Kconfig - 1.6 arch/sparc64/defconfig - 1.6 arch/sparc64/kernel/entry.S - 1.2 arch/sparc64/kernel/init_task.c - 1.2 arch/sparc64/kernel/pci_iommu.c - 1.2 arch/sparc64/kernel/process.c - 1.2 arch/sparc64/kernel/sbus.c - 1.2 arch/sparc64/kernel/setup.c - 1.5 arch/sparc64/kernel/signal32.c - 1.2 arch/sparc64/kernel/smp.c - 1.4 arch/sparc64/kernel/sparc64_ksyms.c - 1.4 arch/sparc64/kernel/sys_sparc32.c - 1.5 arch/sparc64/kernel/sys_sunos32.c - 1.3 arch/sparc64/kernel/systbls.S - 1.3 arch/sparc64/mm/hugetlbpage.c - 1.3 arch/sparc64/mm/init.c - 1.5 arch/sparc64/solaris/timod.c - 1.3 arch/v850/kernel/rte_mb_a_pci.c - 1.2 arch/x86_64/Kconfig - 1.5 arch/x86_64/Makefile - 1.4 arch/x86_64/defconfig - 1.6 arch/x86_64/ia32/Makefile - 1.4 arch/x86_64/ia32/ia32_binfmt.c - 1.4 arch/x86_64/ia32/ia32_ioctl.c - 1.4 arch/x86_64/ia32/ia32_signal.c - 1.4 arch/x86_64/ia32/ia32entry.S - 1.4 arch/x86_64/ia32/ipc32.c - 1.3 arch/x86_64/ia32/sys_ia32.c - 1.6 arch/x86_64/ia32/syscall32.c - 1.3 arch/x86_64/ia32/vsyscall.S - 1.2 arch/x86_64/kernel/Makefile - 1.4 arch/x86_64/kernel/acpi/Makefile - 1.2 arch/x86_64/kernel/acpi/boot.c - 1.6 arch/x86_64/kernel/entry.S - 1.4 arch/x86_64/kernel/io_apic.c - 1.5 arch/x86_64/kernel/ioport.c - 1.2 arch/x86_64/kernel/mpparse.c - 1.6 arch/x86_64/kernel/pci-gart.c - 1.7 arch/x86_64/kernel/process.c - 1.5 arch/x86_64/kernel/setup.c - 1.5 arch/x86_64/kernel/setup64.c - 1.3 arch/x86_64/kernel/smpboot.c - 1.3 arch/x86_64/kernel/suspend_asm.S - 1.3 arch/x86_64/kernel/traps.c - 1.5 arch/x86_64/kernel/vsyscall.c - 1.3 arch/x86_64/kernel/x8664_ksyms.c - 1.4 arch/x86_64/lib/Makefile - 1.2 arch/x86_64/lib/csum-copy.S - 1.3 arch/x86_64/lib/io.c - 1.2 arch/x86_64/lib/iodebug.c - 1.2 arch/x86_64/mm/fault.c - 1.5 arch/x86_64/mm/init.c - 1.4 arch/x86_64/mm/numa.c - 1.2 arch/x86_64/pci/Makefile - 1.2 crypto/Kconfig - 1.3 crypto/Makefile - 1.3 crypto/digest.c - 1.2 crypto/tcrypt.c - 1.4 crypto/tcrypt.h - 1.4 drivers/Makefile - 1.3 drivers/acorn/char/Makefile - 1.2 drivers/acorn/char/i2c.c - 1.5 drivers/acpi/Kconfig - 1.5 drivers/acpi/bus.c - 1.4 drivers/acpi/dispatcher/dsmethod.c - 1.3 drivers/acpi/ec.c - 1.4 drivers/acpi/events/evgpe.c - 1.3 drivers/acpi/events/evgpeblk.c - 1.3 drivers/acpi/events/evmisc.c - 1.3 drivers/acpi/events/evxfevnt.c - 1.3 drivers/acpi/executer/excreate.c - 1.3 drivers/acpi/executer/exdump.c - 1.3 drivers/acpi/executer/exmutex.c - 1.3 drivers/acpi/executer/exresnte.c - 1.3 drivers/acpi/executer/exstoren.c - 1.4 drivers/acpi/hardware/hwgpe.c - 1.4 drivers/acpi/hardware/hwsleep.c - 1.4 drivers/acpi/namespace/nsaccess.c - 1.4 drivers/acpi/namespace/nsalloc.c - 1.3 drivers/acpi/namespace/nsdump.c - 1.3 drivers/acpi/namespace/nseval.c - 1.4 drivers/acpi/namespace/nssearch.c - 1.3 drivers/acpi/namespace/nsutils.c - 1.4 drivers/acpi/namespace/nsxfeval.c - 1.3 drivers/acpi/numa.c - 1.4 drivers/acpi/osl.c - 1.5 drivers/acpi/parser/psparse.c - 1.3 drivers/acpi/parser/psscope.c - 1.3 drivers/acpi/pci_irq.c - 1.4 drivers/acpi/pci_link.c - 1.5 drivers/acpi/power.c - 1.4 drivers/acpi/processor.c - 1.6 drivers/acpi/resources/rsaddr.c - 1.3 drivers/acpi/sleep/poweroff.c - 1.2 drivers/acpi/sleep/proc.c - 1.4 drivers/acpi/tables.c - 1.5 drivers/acpi/toshiba_acpi.c - 1.4 drivers/acpi/utilities/uteval.c - 1.4 drivers/acpi/utilities/utglobal.c - 1.4 drivers/acpi/utilities/utmisc.c - 1.3 drivers/atm/fore200e.c - 1.3 drivers/atm/fore200e.h - 1.2 drivers/atm/idt77252.c - 1.3 drivers/atm/nicstar.c - 1.3 drivers/atm/suni.c - 1.3 drivers/base/Makefile - 1.5 drivers/base/bus.c - 1.4 drivers/base/class.c - 1.5 drivers/base/core.c - 1.5 drivers/base/cpu.c - 1.3 drivers/base/driver.c - 1.3 drivers/base/map.c - 1.2 drivers/base/power/Makefile - 1.2 drivers/base/power/main.c - 1.3 drivers/base/power/shutdown.c - 1.3 drivers/base/sys.c - 1.3 drivers/block/Kconfig - 1.4 drivers/block/Makefile - 1.3 drivers/block/cciss.c - 1.4 drivers/block/cciss_scsi.c - 1.2 drivers/block/cpqarray.c - 1.2 drivers/block/cpqarray.h - 1.2 drivers/block/elevator.c - 1.3 drivers/block/genhd.c - 1.5 drivers/block/ll_rw_blk.c - 1.6 drivers/block/loop.c - 1.4 drivers/block/scsi_ioctl.c - 1.3 drivers/block/smart1,2.h - 1.2 drivers/bluetooth/hci_bcsp.c - 1.3 drivers/bluetooth/hci_ldisc.c - 1.3 drivers/bluetooth/hci_usb.c - 1.4 drivers/cdrom/cdrom.c - 1.5 drivers/cdrom/cdu31a.c - 1.2 drivers/cdrom/cm206.c - 1.2 drivers/cdrom/sbpcd.c - 1.2 drivers/cdrom/sjcd.c - 1.2 drivers/char/Kconfig - 1.5 drivers/char/Makefile - 1.4 drivers/char/agp/Kconfig - 1.4 drivers/char/agp/Makefile - 1.3 drivers/char/agp/agp.h - 1.2 drivers/char/agp/ali-agp.c - 1.2 drivers/char/agp/amd-k7-agp.c - 1.2 drivers/char/agp/amd64-agp.c - 1.4 drivers/char/agp/ati-agp.c - 1.3 drivers/char/agp/generic.c - 1.3 drivers/char/agp/hp-agp.c - 1.2 drivers/char/agp/i460-agp.c - 1.2 drivers/char/agp/intel-agp.c - 1.4 drivers/char/agp/nvidia-agp.c - 1.3 drivers/char/agp/sis-agp.c - 1.2 drivers/char/agp/sworks-agp.c - 1.2 drivers/char/agp/via-agp.c - 1.2 drivers/char/applicom.c - 1.2 drivers/char/cyclades.c - 1.3 drivers/char/drm/drm_memory_debug.h - 1.2 drivers/char/drm/drm_stub.h - 1.2 drivers/char/drm/gamma_context.h - 1.2 drivers/char/dz.c - 1.3 drivers/char/efirtc.c - 1.3 drivers/char/ftape/compressor/lzrw3.c - 1.2 drivers/char/genrtc.c - 1.4 drivers/char/hvc_console.c - 1.3 drivers/char/ip2/i2lib.c - 1.2 drivers/char/keyboard.c - 1.11 drivers/char/lp.c - 1.4 drivers/char/mem.c - 1.4 drivers/char/misc.c - 1.4 drivers/char/mwave/smapi.c - 1.2 drivers/char/pcmcia/synclink_cs.c - 1.4 drivers/char/qtronix.c - 1.2 drivers/char/random.c - 1.2 drivers/char/raw.c - 1.4 drivers/char/rtc.c - 1.3 drivers/char/sn_serial.c - 1.11 drivers/char/sonypi.c - 1.2 drivers/char/sonypi.h - 1.3 drivers/char/synclink.c - 1.3 drivers/char/synclinkmp.c - 1.3 drivers/char/tty_io.c - 1.6 drivers/char/vt.c - 1.5 drivers/char/watchdog/Kconfig - 1.5 drivers/char/watchdog/advantechwdt.c - 1.4 drivers/char/watchdog/alim1535_wdt.c - 1.4 drivers/char/watchdog/alim7101_wdt.c - 1.4 drivers/char/watchdog/amd7xx_tco.c - 1.4 drivers/char/watchdog/cpu5wdt.c - 1.4 drivers/char/watchdog/eurotechwdt.c - 1.4 drivers/char/watchdog/ib700wdt.c - 1.5 drivers/char/watchdog/machzwd.c - 1.5 drivers/char/watchdog/pcwd.c - 1.5 drivers/char/watchdog/sbc60xxwdt.c - 1.4 drivers/char/watchdog/sc1200wdt.c - 1.4 drivers/char/watchdog/sc520_wdt.c - 1.3 drivers/char/watchdog/shwdt.c - 1.4 drivers/char/watchdog/softdog.c - 1.5 drivers/char/watchdog/w83877f_wdt.c - 1.4 drivers/char/watchdog/wafer5823wdt.c - 1.4 drivers/char/watchdog/wd501p.h - 1.2 drivers/char/watchdog/wdt.c - 1.4 drivers/char/watchdog/wdt977.c - 1.4 drivers/char/watchdog/wdt_pci.c - 1.4 drivers/eisa/eisa-bus.c - 1.2 drivers/fc4/soc.h - 1.2 drivers/i2c/Kconfig - 1.3 drivers/i2c/Makefile - 1.2 drivers/i2c/algos/Makefile - 1.2 drivers/i2c/algos/i2c-algo-bit.c - 1.3 drivers/i2c/algos/i2c-algo-pcf.c - 1.2 drivers/i2c/busses/Kconfig - 1.5 drivers/i2c/busses/Makefile - 1.4 drivers/i2c/busses/i2c-ali1535.c - 1.3 drivers/i2c/busses/i2c-ali15x3.c - 1.3 drivers/i2c/busses/i2c-amd756.c - 1.4 drivers/i2c/busses/i2c-amd8111.c - 1.4 drivers/i2c/busses/i2c-elektor.c - 1.3 drivers/i2c/busses/i2c-elv.c - 1.4 drivers/i2c/busses/i2c-frodo.c - 1.3 drivers/i2c/busses/i2c-i801.c - 1.3 drivers/i2c/busses/i2c-i810.c - 1.3 drivers/i2c/busses/i2c-ibm_iic.c - 1.4 drivers/i2c/busses/i2c-iop3xx.c - 1.3 drivers/i2c/busses/i2c-isa.c - 1.3 drivers/i2c/busses/i2c-ite.c - 1.3 drivers/i2c/busses/i2c-keywest.c - 1.5 drivers/i2c/busses/i2c-nforce2.c - 1.3 drivers/i2c/busses/i2c-philips-par.c - 1.4 drivers/i2c/busses/i2c-piix4.c - 1.5 drivers/i2c/busses/i2c-prosavage.c - 1.3 drivers/i2c/busses/i2c-rpx.c - 1.3 drivers/i2c/busses/i2c-savage4.c - 1.5 drivers/i2c/busses/i2c-sis5595.c - 1.3 drivers/i2c/busses/i2c-sis630.c - 1.3 drivers/i2c/busses/i2c-sis96x.c - 1.3 drivers/i2c/busses/i2c-velleman.c - 1.5 drivers/i2c/busses/i2c-via.c - 1.3 drivers/i2c/busses/i2c-viapro.c - 1.4 drivers/i2c/busses/i2c-voodoo3.c - 1.4 drivers/i2c/busses/scx200_acb.c - 1.3 drivers/i2c/busses/scx200_i2c.c - 1.3 drivers/i2c/chips/Kconfig - 1.5 drivers/i2c/chips/Makefile - 1.5 drivers/i2c/chips/adm1021.c - 1.3 drivers/i2c/chips/eeprom.c - 1.3 drivers/i2c/chips/it87.c - 1.5 drivers/i2c/chips/lm75.c - 1.5 drivers/i2c/chips/lm78.c - 1.5 drivers/i2c/chips/lm85.c - 1.6 drivers/i2c/chips/via686a.c - 1.4 drivers/i2c/chips/w83781d.c - 1.4 drivers/i2c/i2c-core.c - 1.5 drivers/i2c/i2c-dev.c - 1.4 drivers/i2c/i2c-sensor.c - 1.3 drivers/ide/Kconfig - 1.7 drivers/ide/ide-cd.c - 1.8 drivers/ide/ide-disk.c - 1.5 drivers/ide/ide-dma.c - 1.6 drivers/ide/ide-io.c - 1.4 drivers/ide/ide-iops.c - 1.6 drivers/ide/ide-lib.c - 1.2 drivers/ide/ide-pnp.c - 1.2 drivers/ide/ide-probe.c - 1.4 drivers/ide/ide-taskfile.c - 1.5 drivers/ide/ide-tcq.c - 1.3 drivers/ide/ide.c - 1.10 drivers/ide/legacy/macide.c - 1.2 drivers/ide/legacy/pdc4030.c - 1.3 drivers/ide/pci/Makefile - 1.5 drivers/ide/pci/aec62xx.c - 1.5 drivers/ide/pci/alim15x3.c - 1.5 drivers/ide/pci/amd74xx.c - 1.5 drivers/ide/pci/cmd64x.c - 1.5 drivers/ide/pci/cs5520.c - 1.4 drivers/ide/pci/cs5530.c - 1.5 drivers/ide/pci/cy82c693.c - 1.3 drivers/ide/pci/generic.c - 1.4 drivers/ide/pci/hpt34x.c - 1.5 drivers/ide/pci/hpt366.c - 1.5 drivers/ide/pci/it8172.c - 1.5 drivers/ide/pci/ns87415.c - 1.4 drivers/ide/pci/opti621.c - 1.4 drivers/ide/pci/pdc202xx_new.c - 1.6 drivers/ide/pci/pdc202xx_new.h - 1.4 drivers/ide/pci/pdc202xx_old.c - 1.6 drivers/ide/pci/piix.c - 1.6 drivers/ide/pci/rz1000.c - 1.4 drivers/ide/pci/sc1200.c - 1.6 drivers/ide/pci/serverworks.c - 1.5 drivers/ide/pci/siimage.c - 1.6 drivers/ide/pci/sis5513.c - 1.5 drivers/ide/pci/sl82c105.c - 1.5 drivers/ide/pci/slc90e66.c - 1.5 drivers/ide/pci/triflex.h - 1.5 drivers/ide/pci/trm290.c - 1.5 drivers/ide/pci/via82cxxx.c - 1.4 drivers/ieee1394/amdtp.c - 1.5 drivers/ieee1394/dma.c - 1.4 drivers/ieee1394/dma.h - 1.3 drivers/ieee1394/dv1394.c - 1.5 drivers/ieee1394/ieee1394_core.c - 1.5 drivers/ieee1394/ohci1394.c - 1.5 drivers/ieee1394/raw1394.c - 1.6 drivers/ieee1394/sbp2.c - 1.6 drivers/ieee1394/video1394.c - 1.6 drivers/input/evdev.c - 1.5 drivers/input/gameport/ns558.c - 1.2 drivers/input/input.c - 1.4 drivers/input/joystick/amijoy.c - 1.2 drivers/input/joystick/analog.c - 1.2 drivers/input/joystick/db9.c - 1.3 drivers/input/joystick/gamecon.c - 1.3 drivers/input/joystick/gf2k.c - 1.2 drivers/input/joystick/iforce/iforce-usb.c - 1.2 drivers/input/joystick/turbografx.c - 1.3 drivers/input/keyboard/Kconfig - 1.2 drivers/input/keyboard/Makefile - 1.2 drivers/input/keyboard/atkbd.c - 1.4 drivers/input/keyboard/maple_keyb.c - 1.3 drivers/input/keyboard/sunkbd.c - 1.2 drivers/input/misc/Kconfig - 1.2 drivers/input/misc/Makefile - 1.2 drivers/input/misc/gsc_ps2.c - 1.2 drivers/input/mouse/98busmouse.c - 1.3 drivers/input/mouse/Kconfig - 1.4 drivers/input/mouse/Makefile - 1.2 drivers/input/mouse/inport.c - 1.3 drivers/input/mouse/logibm.c - 1.3 drivers/input/mouse/maplemouse.c - 1.2 drivers/input/mouse/psmouse-base.c - 1.4 drivers/input/mouse/psmouse.h - 1.4 drivers/input/mouse/synaptics.c - 1.4 drivers/input/mouse/synaptics.h - 1.3 drivers/input/serio/Kconfig - 1.2 drivers/input/serio/Makefile - 1.2 drivers/input/serio/i8042-io.h - 1.2 drivers/input/serio/i8042.c - 1.6 drivers/input/serio/serio.c - 1.3 drivers/isdn/capi/capi.c - 1.3 drivers/isdn/capi/kcapi.c - 1.3 drivers/isdn/hardware/eicon/adapter.h - 1.2 drivers/isdn/hardware/eicon/capifunc.c - 1.3 drivers/isdn/hardware/eicon/capifunc.h - 1.2 drivers/isdn/hardware/eicon/diva.c - 1.2 drivers/isdn/hardware/eicon/divasmain.c - 1.4 drivers/isdn/hardware/eicon/divasproc.c - 1.2 drivers/isdn/hardware/eicon/dlist.c - 1.2 drivers/isdn/hardware/eicon/dlist.h - 1.2 drivers/isdn/hardware/eicon/entity.h - 1.2 drivers/isdn/hardware/eicon/i4l_idi.c - 1.2 drivers/isdn/hardware/eicon/i4l_idi.h - 1.2 drivers/isdn/hardware/eicon/i4lididrv.c - 1.2 drivers/isdn/hardware/eicon/i4lididrv.h - 1.2 drivers/isdn/hardware/eicon/idifunc.c - 1.2 drivers/isdn/hardware/eicon/message.c - 1.2 drivers/isdn/hardware/eicon/os_4bri.c - 1.2 drivers/isdn/hardware/eicon/os_bri.c - 1.2 drivers/isdn/hardware/eicon/os_pri.c - 1.2 drivers/isdn/hardware/eicon/platform.h - 1.3 drivers/isdn/hardware/eicon/um_idi.c - 1.3 drivers/isdn/hardware/eicon/um_idi.h - 1.2 drivers/isdn/hardware/eicon/xdi_adapter.h - 1.3 drivers/isdn/hisax/hisax_fcpcipnp.c - 1.3 drivers/isdn/hisax/niccy.c - 1.3 drivers/isdn/hisax/nj_s.c - 1.3 drivers/macintosh/Makefile - 1.3 drivers/macintosh/adbhid.c - 1.4 drivers/macintosh/mediabay.c - 1.3 drivers/macintosh/via-pmu.c - 1.6 drivers/mca/mca-bus.c - 1.2 drivers/md/dm-ioctl.c - 1.3 drivers/md/dm-linear.c - 1.2 drivers/md/dm-stripe.c - 1.3 drivers/md/dm-table.c - 1.4 drivers/md/dm-target.c - 1.2 drivers/md/dm.c - 1.5 drivers/md/dm.h - 1.4 drivers/md/md.c - 1.5 drivers/md/raid0.c - 1.4 drivers/md/raid5.c - 1.6 drivers/media/dvb/frontends/alps_tdlb7.c - 1.3 drivers/media/dvb/frontends/sp887x.c - 1.4 drivers/media/dvb/frontends/tda1004x.c - 1.4 drivers/media/video/meye.c - 1.3 drivers/media/video/meye.h - 1.3 drivers/media/video/video-buf.c - 1.4 drivers/media/video/zoran_driver.c - 1.2 drivers/message/fusion/Kconfig - 1.3 drivers/message/fusion/Makefile - 1.2 drivers/message/fusion/isense.c - 1.3 drivers/message/fusion/linux_compat.h - 1.2 drivers/message/fusion/lsi/mpi.h - 1.2 drivers/message/fusion/lsi/mpi_cnfg.h - 1.2 drivers/message/fusion/lsi/mpi_fc.h - 1.2 drivers/message/fusion/lsi/mpi_init.h - 1.2 drivers/message/fusion/lsi/mpi_ioc.h - 1.2 drivers/message/fusion/lsi/mpi_lan.h - 1.2 drivers/message/fusion/lsi/mpi_raid.h - 1.2 drivers/message/fusion/lsi/mpi_targ.h - 1.2 drivers/message/fusion/lsi/mpi_type.h - 1.2 drivers/message/fusion/mptbase.c - 1.5 drivers/message/fusion/mptbase.h - 1.6 drivers/message/fusion/mptctl.c - 1.3 drivers/message/fusion/mptctl.h - 1.3 drivers/message/fusion/mptlan.c - 1.4 drivers/message/fusion/mptscsih.c - 1.6 drivers/message/fusion/mptscsih.h - 1.4 drivers/message/fusion/scsi3.h - 1.3 drivers/message/i2o/i2o_core.c - 1.3 drivers/mtd/cmdlinepart.c - 1.2 drivers/mtd/devices/blkmtd.c - 1.3 drivers/mtd/nand/nand.c - 1.2 drivers/net/3c501.c - 1.3 drivers/net/3c503.c - 1.4 drivers/net/3c507.c - 1.3 drivers/net/3c509.c - 1.3 drivers/net/3c527.c - 1.4 drivers/net/3c59x.c - 1.4 drivers/net/7990.c - 1.2 drivers/net/8139too.c - 1.4 drivers/net/82596.c - 1.3 drivers/net/8390.c - 1.4 drivers/net/8390.h - 1.3 drivers/net/Kconfig - 1.5 drivers/net/Makefile - 1.5 drivers/net/a2065.c - 1.5 drivers/net/ac3200.c - 1.4 drivers/net/acenic.h - 1.2 drivers/net/amd8111e.c - 1.3 drivers/net/apne.c - 1.5 drivers/net/appletalk/cops.c - 1.3 drivers/net/ariadne.c - 1.4 drivers/net/arm/am79c961a.c - 1.4 drivers/net/arm/ether1.c - 1.4 drivers/net/arm/ether3.c - 1.3 drivers/net/arm/etherh.c - 1.4 drivers/net/at1700.c - 1.3 drivers/net/atari_bionet.c - 1.3 drivers/net/atari_pamsnet.c - 1.4 drivers/net/atp.c - 1.3 drivers/net/b44.c - 1.2 drivers/net/bagetlance.c - 1.3 drivers/net/bmac.c - 1.3 drivers/net/cs89x0.c - 1.4 drivers/net/declance.c - 1.3 drivers/net/dl2k.c - 1.3 drivers/net/e1000/e1000_ethtool.c - 1.3 drivers/net/e2100.c - 1.4 drivers/net/eepro.c - 1.3 drivers/net/eepro100.c - 1.2 drivers/net/eexpress.c - 1.3 drivers/net/epic100.c - 1.2 drivers/net/es3210.c - 1.4 drivers/net/eth16i.c - 1.3 drivers/net/ethertap.c - 1.3 drivers/net/fc/iph5526.c - 1.4 drivers/net/fealnx.c - 1.3 drivers/net/fec.c - 1.3 drivers/net/gt96100eth.c - 1.4 drivers/net/hamachi.c - 1.2 drivers/net/hamradio/6pack.c - 1.4 drivers/net/hamradio/baycom_epp.c - 1.5 drivers/net/hamradio/baycom_par.c - 1.3 drivers/net/hamradio/baycom_ser_fdx.c - 1.2 drivers/net/hamradio/baycom_ser_hdx.c - 1.2 drivers/net/hamradio/hdlcdrv.c - 1.3 drivers/net/hp-plus.c - 1.4 drivers/net/hp.c - 1.4 drivers/net/hplance.c - 1.3 drivers/net/hydra.c - 1.5 drivers/net/irda/vlsi_ir.c - 1.3 drivers/net/isa-skeleton.c - 1.3 drivers/net/lasi_82596.c - 1.4 drivers/net/lne390.c - 1.4 drivers/net/loopback.c - 1.3 drivers/net/mac8390.c - 1.4 drivers/net/mac89x0.c - 1.3 drivers/net/mace.c - 1.4 drivers/net/myri_sbus.c - 1.2 drivers/net/natsemi.c - 1.3 drivers/net/ne.c - 1.5 drivers/net/ne2.c - 1.4 drivers/net/ne2k-pci.c - 1.4 drivers/net/ne2k_cbus.c - 1.4 drivers/net/ne3210.c - 1.3 drivers/net/ni5010.c - 1.3 drivers/net/oaknet.c - 1.4 drivers/net/pcmcia/3c574_cs.c - 1.6 drivers/net/pcmcia/3c589_cs.c - 1.5 drivers/net/pcmcia/com20020_cs.c - 1.4 drivers/net/pcmcia/fmvj18x_cs.c - 1.5 drivers/net/pcmcia/ibmtr_cs.c - 1.4 drivers/net/pcmcia/pcnet_cs.c - 1.6 drivers/net/pcmcia/smc91c92_cs.c - 1.5 drivers/net/pcmcia/xirc2ps_cs.c - 1.4 drivers/net/pcnet32.c - 1.4 drivers/net/plip.c - 1.4 drivers/net/ppp_generic.c - 1.4 drivers/net/rrunner.c - 1.2 drivers/net/sb1000.c - 1.2 drivers/net/sb1250-mac.c - 1.4 drivers/net/seeq8005.c - 1.3 drivers/net/sgiseeq.c - 1.3 drivers/net/sis190.c - 1.3 drivers/net/sis900.c - 1.4 drivers/net/sk98lin/skge.c - 1.7 drivers/net/sk98lin/skgepnmi.c - 1.5 drivers/net/sk_g16.c - 1.3 drivers/net/smc-mca.c - 1.3 drivers/net/smc-ultra.c - 1.4 drivers/net/smc-ultra32.c - 1.4 drivers/net/smc9194.c - 1.3 drivers/net/starfire.c - 1.3 drivers/net/stnic.c - 1.5 drivers/net/sun3lance.c - 1.5 drivers/net/sunbmac.c - 1.2 drivers/net/sundance.c - 1.4 drivers/net/sungem.c - 1.4 drivers/net/sunhme.c - 1.2 drivers/net/sunhme.h - 1.2 drivers/net/sunlance.c - 1.2 drivers/net/tg3.c - 1.6 drivers/net/tlan.c - 1.2 drivers/net/tokenring/3c359.c - 1.5 drivers/net/tokenring/abyss.c - 1.4 drivers/net/tokenring/madgemc.c - 1.4 drivers/net/tokenring/olympic.c - 1.4 drivers/net/tokenring/proteon.c - 1.4 drivers/net/tokenring/skisa.c - 1.4 drivers/net/tokenring/smctr.c - 1.4 drivers/net/tokenring/tms380tr.c - 1.4 drivers/net/tulip/21142.c - 1.2 drivers/net/tulip/de2104x.c - 1.3 drivers/net/tulip/de4x5.c - 1.3 drivers/net/tulip/dmfe.c - 1.3 drivers/net/tulip/eeprom.c - 1.2 drivers/net/tulip/interrupt.c - 1.4 drivers/net/tulip/media.c - 1.2 drivers/net/tulip/pnic.c - 1.2 drivers/net/tulip/pnic2.c - 1.2 drivers/net/tulip/timer.c - 1.2 drivers/net/tulip/tulip.h - 1.3 drivers/net/tulip/tulip_core.c - 1.3 drivers/net/tulip/winbond-840.c - 1.3 drivers/net/tulip/xircom_cb.c - 1.3 drivers/net/tun.c - 1.4 drivers/net/typhoon.c - 1.4 drivers/net/via-rhine.c - 1.2 drivers/net/wan/comx-hw-locomx.c - 1.2 drivers/net/wan/comx-hw-munich.c - 1.3 drivers/net/wan/comx.c - 1.2 drivers/net/wan/cosa.c - 1.3 drivers/net/wan/dscc4.c - 1.3 drivers/net/wan/lapbether.c - 1.4 drivers/net/wan/pc300_drv.c - 1.5 drivers/net/wd.c - 1.4 drivers/net/wireless/Kconfig - 1.5 drivers/net/wireless/Makefile - 1.3 drivers/net/wireless/airo.c - 1.5 drivers/net/wireless/arlan-main.c - 1.3 drivers/net/wireless/atmel.c - 1.5 drivers/net/wireless/hermes.h - 1.2 drivers/net/wireless/orinoco.c - 1.3 drivers/net/yellowfin.c - 1.3 drivers/net/zorro8390.c - 1.5 drivers/parisc/ccio-dma.c - 1.4 drivers/parisc/ccio-rm-dma.c - 1.2 drivers/parisc/eisa.c - 1.2 drivers/parisc/gsc.c - 1.2 drivers/parisc/lba_pci.c - 1.3 drivers/parisc/sba_iommu.c - 1.3 drivers/parisc/superio.c - 1.4 drivers/parport/daisy.c - 1.4 drivers/parport/parport_gsc.c - 1.4 drivers/parport/parport_pc.c - 1.4 drivers/pci/hotplug/Makefile - 1.3 drivers/pci/hotplug/acpiphp.h - 1.3 drivers/pci/hotplug/acpiphp_glue.c - 1.4 drivers/pci/hotplug/acpiphp_pci.c - 1.3 drivers/pci/hotplug/acpiphp_res.c - 1.3 drivers/pci/hotplug/cpqphp_core.c - 1.3 drivers/pci/hotplug/pci_hotplug_core.c - 1.4 drivers/pci/pci.c - 1.3 drivers/pci/probe.c - 1.8 drivers/pci/quirks.c - 1.4 drivers/pci/setup-res.c - 1.4 drivers/pcmcia/Kconfig - 1.2 drivers/pcmcia/Makefile - 1.2 drivers/pcmcia/au1000_generic.c - 1.2 drivers/pcmcia/au1000_pb1x00.c - 1.2 drivers/pcmcia/bulkmem.c - 1.3 drivers/pcmcia/cardbus.c - 1.2 drivers/pcmcia/cistpl.c - 1.3 drivers/pcmcia/cs.c - 1.4 drivers/pcmcia/cs_internal.h - 1.2 drivers/pcmcia/ds.c - 1.3 drivers/pcmcia/i82365.c - 1.3 drivers/pcmcia/sa1100_pangolin.c - 1.2 drivers/pcmcia/sa11xx_core.c - 1.3 drivers/pcmcia/tcic.c - 1.2 drivers/pcmcia/yenta_socket.c - 1.3 drivers/pnp/isapnp/core.c - 1.3 drivers/pnp/resource.c - 1.3 drivers/pnp/system.c - 1.2 drivers/s390/block/Kconfig - 1.3 drivers/s390/block/dasd.c - 1.4 drivers/s390/block/dasd_3990_erp.c - 1.4 drivers/s390/block/dasd_devmap.c - 1.3 drivers/s390/block/dasd_diag.c - 1.3 drivers/s390/block/dasd_eckd.c - 1.4 drivers/s390/block/dasd_genhd.c - 1.4 drivers/s390/block/dasd_int.h - 1.4 drivers/s390/block/dasd_ioctl.c - 1.3 drivers/s390/block/dasd_proc.c - 1.4 drivers/s390/char/Makefile - 1.4 drivers/s390/char/sclp.c - 1.4 drivers/s390/char/tape.h - 1.4 drivers/s390/char/tape_34xx.c - 1.3 drivers/s390/char/tape_block.c - 1.4 drivers/s390/char/tape_char.c - 1.4 drivers/s390/char/tape_core.c - 1.4 drivers/s390/char/tape_std.c - 1.3 drivers/s390/cio/blacklist.c - 1.4 drivers/s390/cio/ccwgroup.c - 1.4 drivers/s390/cio/css.h - 1.4 drivers/s390/cio/device.c - 1.5 drivers/s390/cio/device_fsm.c - 1.4 drivers/s390/cio/device_ops.c - 1.4 drivers/s390/cio/device_status.c - 1.4 drivers/s390/cio/qdio.c - 1.4 drivers/s390/cio/qdio.h - 1.3 drivers/s390/net/ctcmain.c - 1.4 drivers/s390/net/iucv.c - 1.4 drivers/s390/net/lcs.c - 1.4 drivers/s390/net/lcs.h - 1.2 drivers/s390/net/netiucv.c - 1.4 drivers/s390/net/qeth.c - 1.5 drivers/s390/net/qeth.h - 1.3 drivers/s390/scsi/zfcp_erp.c - 1.4 drivers/scsi/53c700.c - 1.3 drivers/scsi/53c700.h - 1.4 drivers/scsi/BusLogic.c - 1.6 drivers/scsi/Kconfig - 1.7 drivers/scsi/Makefile - 1.5 drivers/scsi/aacraid/linit.c - 1.5 drivers/scsi/aacraid/rx.c - 1.4 drivers/scsi/aacraid/sa.c - 1.4 drivers/scsi/aic7xxx/Kconfig.aic79xx - 1.2 drivers/scsi/aic7xxx/Kconfig.aic7xxx - 1.3 drivers/scsi/aic7xxx/aic7770.c - 1.3 drivers/scsi/ata_piix.c - 1.5 drivers/scsi/constants.c - 1.2 drivers/scsi/cpqfcTSinit.c - 1.3 drivers/scsi/dc395x.c - 1.2 drivers/scsi/dc395x.h - 1.2 drivers/scsi/dec_esp.c - 1.3 drivers/scsi/dpt_i2o.c - 1.2 drivers/scsi/eata.c - 1.2 drivers/scsi/gdth.c - 1.3 drivers/scsi/hosts.c - 1.3 drivers/scsi/i91uscsi.c - 1.2 drivers/scsi/ide-scsi.c - 1.4 drivers/scsi/in2000.c - 1.2 drivers/scsi/ini9100u.c - 1.5 drivers/scsi/libata-core.c - 1.6 drivers/scsi/libata-scsi.c - 1.5 drivers/scsi/libata.h - 1.5 drivers/scsi/mac53c94.c - 1.3 drivers/scsi/megaraid.c - 1.4 drivers/scsi/mesh.c - 1.3 drivers/scsi/ncr53c8xx.c - 1.2 drivers/scsi/oktagon_esp.c - 1.3 drivers/scsi/pci2000.c - 1.2 drivers/scsi/pci2220i.c - 1.2 drivers/scsi/pcmcia/qlogic_stub.c - 1.3 drivers/scsi/qlogicfas.c - 1.2 drivers/scsi/qlogicfc.c - 1.5 drivers/scsi/qlogicisp.c - 1.2 drivers/scsi/sata_promise.c - 1.5 drivers/scsi/sata_sil.c - 1.5 drivers/scsi/sata_svw.c - 1.5 drivers/scsi/sata_via.c - 1.5 drivers/scsi/scsi.c - 1.5 drivers/scsi/scsi_devinfo.c - 1.2 drivers/scsi/scsi_error.c - 1.4 drivers/scsi/scsi_lib.c - 1.4 drivers/scsi/scsi_priv.h - 1.4 drivers/scsi/scsi_scan.c - 1.3 drivers/scsi/scsi_sysfs.c - 1.3 drivers/scsi/scsiiom.c - 1.3 drivers/scsi/sd.c - 1.4 drivers/scsi/sg.c - 1.5 drivers/scsi/sr.c - 1.6 drivers/scsi/st.c - 1.6 drivers/scsi/st.h - 1.3 drivers/scsi/sym53c8xx_2/sym53c8xx.h - 1.3 drivers/scsi/sym53c8xx_2/sym_defs.h - 1.2 drivers/scsi/sym53c8xx_2/sym_fw.c - 1.3 drivers/scsi/sym53c8xx_2/sym_glue.c - 1.4 drivers/scsi/sym53c8xx_2/sym_glue.h - 1.3 drivers/scsi/sym53c8xx_2/sym_hipd.c - 1.4 drivers/scsi/sym53c8xx_2/sym_hipd.h - 1.3 drivers/scsi/sym53c8xx_2/sym_misc.c - 1.3 drivers/scsi/sym53c8xx_2/sym_misc.h - 1.2 drivers/scsi/sym53c8xx_2/sym_nvram.c - 1.3 drivers/scsi/sym53c8xx_comm.h - 1.2 drivers/scsi/u14-34f.c - 1.2 drivers/scsi/wd33c93.c - 1.2 drivers/serial/21285.c - 1.2 drivers/serial/8250.c - 1.11 drivers/serial/8250_acpi.c - 1.3 drivers/serial/8250_hcdp.c - 1.3 drivers/serial/8250_pnp.c - 1.6 drivers/serial/Kconfig - 1.4 drivers/serial/Makefile - 1.3 drivers/serial/amba.c - 1.2 drivers/serial/anakin.c - 1.2 drivers/serial/clps711x.c - 1.3 drivers/serial/mux.c - 1.3 drivers/serial/pmac_zilog.c - 1.5 drivers/serial/sa1100.c - 1.3 drivers/usb/Kconfig - 1.3 drivers/usb/Makefile - 1.5 drivers/usb/class/audio.c - 1.3 drivers/usb/class/bluetty.c - 1.2 drivers/usb/class/cdc-acm.c - 1.4 drivers/usb/class/usb-midi.c - 1.2 drivers/usb/class/usblp.c - 1.4 drivers/usb/core/buffer.c - 1.4 drivers/usb/core/config.c - 1.2 drivers/usb/core/devio.c - 1.2 drivers/usb/core/driverfs.c - 1.3 drivers/usb/core/hcd-pci.c - 1.3 drivers/usb/core/hcd.c - 1.5 drivers/usb/core/hub.c - 1.6 drivers/usb/core/message.c - 1.5 drivers/usb/core/urb.c - 1.3 drivers/usb/core/usb.c - 1.6 drivers/usb/gadget/Kconfig - 1.4 drivers/usb/gadget/Makefile - 1.4 drivers/usb/gadget/ether.c - 1.6 drivers/usb/gadget/net2280.c - 1.5 drivers/usb/gadget/usbstring.c - 1.2 drivers/usb/gadget/zero.c - 1.4 drivers/usb/host/Kconfig - 1.2 drivers/usb/host/ehci-dbg.c - 1.4 drivers/usb/host/ehci-hcd.c - 1.5 drivers/usb/host/ehci-sched.c - 1.4 drivers/usb/host/ehci.h - 1.4 drivers/usb/host/uhci-hcd.c - 1.6 drivers/usb/host/uhci-hcd.h - 1.4 drivers/usb/image/hpusbscsi.c - 1.2 drivers/usb/image/mdc800.c - 1.2 drivers/usb/image/microtek.c - 1.2 drivers/usb/input/Kconfig - 1.3 drivers/usb/input/Makefile - 1.2 drivers/usb/input/aiptek.c - 1.3 drivers/usb/input/hid-core.c - 1.5 drivers/usb/input/hid-ff.c - 1.3 drivers/usb/input/hid-input.c - 1.3 drivers/usb/input/hid.h - 1.3 drivers/usb/input/hiddev.c - 1.4 drivers/usb/input/kbtab.c - 1.3 drivers/usb/input/pid.c - 1.2 drivers/usb/input/usbkbd.c - 1.3 drivers/usb/input/usbmouse.c - 1.3 drivers/usb/input/wacom.c - 1.3 drivers/usb/media/Kconfig - 1.5 drivers/usb/media/se401.c - 1.2 drivers/usb/media/stv680.c - 1.3 drivers/usb/misc/Kconfig - 1.6 drivers/usb/misc/Makefile - 1.4 drivers/usb/misc/brlvger.c - 1.2 drivers/usb/misc/usbtest.c - 1.4 drivers/usb/net/Kconfig - 1.4 drivers/usb/net/pegasus.h - 1.3 drivers/usb/net/usbnet.c - 1.6 drivers/usb/serial/empeg.c - 1.2 drivers/usb/serial/ftdi_sio.c - 1.5 drivers/usb/serial/ftdi_sio.h - 1.5 drivers/usb/serial/kl5kusb105.c - 1.2 drivers/usb/serial/mct_u232.c - 1.4 drivers/usb/serial/pl2303.c - 1.4 drivers/usb/serial/usb-serial.c - 1.2 drivers/usb/serial/usb-serial.h - 1.2 drivers/usb/serial/visor.c - 1.5 drivers/usb/serial/visor.h - 1.5 drivers/usb/storage/Kconfig - 1.3 drivers/usb/storage/scsiglue.c - 1.5 drivers/usb/storage/transport.c - 1.5 drivers/usb/storage/unusual_devs.h - 1.7 drivers/usb/storage/usb.c - 1.4 drivers/usb/storage/usb.h - 1.2 drivers/video/Kconfig - 1.8 drivers/video/Makefile - 1.6 drivers/video/acornfb.c - 1.3 drivers/video/acornfb.h - 1.3 drivers/video/anakinfb.c - 1.2 drivers/video/console/fbcon.c - 1.7 drivers/video/dnfb.c - 1.2 drivers/video/fbmem.c - 1.8 drivers/video/fbmon.c - 1.4 drivers/video/fm2fb.c - 1.2 drivers/video/hitfb.c - 1.3 drivers/video/i810/i810_main.c - 1.2 drivers/video/i810/i810_main.h - 1.2 drivers/video/modedb.c - 1.2 drivers/video/pm2fb.c - 1.3 drivers/video/pvr2fb.c - 1.4 drivers/video/sa1100fb.c - 1.3 drivers/video/sa1100fb.h - 1.2 drivers/video/sis/init301.c - 1.4 drivers/video/tgafb.c - 1.2 fs/Kconfig - 1.8 fs/Kconfig.binfmt - 1.4 fs/adfs/super.c - 1.3 fs/affs/super.c - 1.2 fs/afs/inode.c - 1.4 fs/afs/super.c - 1.4 fs/aio.c - 1.3 fs/bfs/dir.c - 1.2 fs/binfmt_elf.c - 1.6 fs/bio.c - 1.4 fs/block_dev.c - 1.5 fs/buffer.c - 1.5 fs/char_dev.c - 1.4 fs/cifs/cifsfs.c - 1.2 fs/cifs/connect.c - 1.2 fs/coda/dir.c - 1.2 fs/coda/inode.c - 1.3 fs/compat.c - 1.4 fs/compat_ioctl.c - 1.7 fs/cramfs/inode.c - 1.4 fs/exportfs/expfs.c - 1.2 fs/ext2/acl.c - 1.3 fs/ext2/dir.c - 1.2 fs/ext2/ialloc.c - 1.4 fs/ext3/acl.c - 1.3 fs/ext3/dir.c - 1.2 fs/ext3/ialloc.c - 1.4 fs/fat/inode.c - 1.3 fs/fcntl.c - 1.4 fs/freevxfs/vxfs_super.c - 1.5 fs/fs-writeback.c - 1.5 fs/hfs/TODO - 1.2 fs/hfs/super.c - 1.3 fs/hpfs/alloc.c - 1.2 fs/hpfs/anode.c - 1.2 fs/hpfs/buffer.c - 1.3 fs/hpfs/dir.c - 1.2 fs/hpfs/dnode.c - 1.2 fs/hpfs/ea.c - 1.2 fs/hpfs/file.c - 1.2 fs/hpfs/hpfs_fn.h - 1.2 fs/hpfs/inode.c - 1.2 fs/hpfs/map.c - 1.2 fs/hpfs/name.c - 1.2 fs/hpfs/namei.c - 1.2 fs/hpfs/super.c - 1.3 fs/hugetlbfs/inode.c - 1.4 fs/inode.c - 1.3 fs/intermezzo/dir.c - 1.3 fs/intermezzo/file.c - 1.3 fs/intermezzo/fileset.c - 1.2 fs/intermezzo/intermezzo_fs.h - 1.4 fs/intermezzo/intermezzo_kml.h - 1.2 fs/intermezzo/journal.c - 1.3 fs/intermezzo/journal_xfs.c - 1.2 fs/intermezzo/kml_reint.c - 1.2 fs/intermezzo/psdev.c - 1.2 fs/intermezzo/upcall.c - 1.2 fs/intermezzo/vfs.c - 1.3 fs/jbd/recovery.c - 1.2 fs/jffs/inode-v23.c - 1.3 fs/jffs2/super.c - 1.2 fs/jfs/jfs_dmap.c - 1.3 fs/jfs/jfs_dtree.c - 1.3 fs/jfs/jfs_imap.c - 1.4 fs/jfs/jfs_logmgr.c - 1.4 fs/jfs/jfs_metapage.c - 1.2 fs/jfs/jfs_txnmgr.c - 1.4 fs/jfs/jfs_xtree.c - 1.3 fs/jfs/super.c - 1.4 fs/libfs.c - 1.4 fs/lockd/clntproc.c - 1.3 fs/lockd/host.c - 1.2 fs/lockd/mon.c - 1.2 fs/lockd/svc4proc.c - 1.2 fs/lockd/svclock.c - 1.2 fs/lockd/svcproc.c - 1.2 fs/minix/dir.c - 1.2 fs/namei.c - 1.5 fs/namespace.c - 1.3 fs/ncpfs/inode.c - 1.3 fs/nfs/dir.c - 1.4 fs/nfs/direct.c - 1.2 fs/nfs/file.c - 1.4 fs/nfs/inode.c - 1.4 fs/nfs/mount_clnt.c - 1.2 fs/nfs/nfs2xdr.c - 1.2 fs/nfs/nfs3proc.c - 1.3 fs/nfs/nfs3xdr.c - 1.2 fs/nfs/nfs4proc.c - 1.3 fs/nfs/nfs4state.c - 1.3 fs/nfs/nfs4xdr.c - 1.3 fs/nfs/nfsroot.c - 1.2 fs/nfs/pagelist.c - 1.2 fs/nfs/proc.c - 1.3 fs/nfs/read.c - 1.2 fs/nfs/unlink.c - 1.2 fs/nfs/write.c - 1.3 fs/nfsd/nfs3xdr.c - 1.3 fs/nfsd/vfs.c - 1.4 fs/open.c - 1.4 fs/pipe.c - 1.4 fs/proc/generic.c - 1.3 fs/proc/inode.c - 1.2 fs/proc/kmsg.c - 1.2 fs/proc/proc_misc.c - 1.6 fs/proc/root.c - 1.2 fs/qnx4/dir.c - 1.2 fs/read_write.c - 1.3 fs/readdir.c - 1.4 fs/reiserfs/dir.c - 1.2 fs/reiserfs/file.c - 1.3 fs/reiserfs/inode.c - 1.3 fs/reiserfs/stree.c - 1.2 fs/smbfs/inode.c - 1.2 fs/smbfs/sock.c - 1.2 fs/stat.c - 1.5 fs/super.c - 1.4 fs/sysfs/dir.c - 1.3 fs/sysfs/group.c - 1.2 fs/sysv/dir.c - 1.2 fs/udf/dir.c - 1.2 fs/udf/file.c - 1.2 fs/udf/inode.c - 1.2 fs/udf/misc.c - 1.2 fs/udf/namei.c - 1.2 fs/udf/osta_udf.h - 1.2 fs/udf/super.c - 1.3 fs/udf/truncate.c - 1.2 fs/udf/udf_sb.h - 1.2 fs/udf/udfdecl.h - 1.2 fs/udf/unicode.c - 1.2 fs/ufs/dir.c - 1.2 fs/ufs/inode.c - 1.2 fs/ufs/namei.c - 1.2 fs/ufs/super.c - 1.3 fs/ufs/util.c - 1.2 fs/ufs/util.h - 1.2 include/acpi/acconfig.h - 1.4 include/acpi/acglobal.h - 1.4 include/acpi/achware.h - 1.3 include/acpi/aclocal.h - 1.3 include/acpi/acmacros.h - 1.3 include/acpi/acobject.h - 1.3 include/acpi/acpi_bus.h - 1.2 include/acpi/acpixf.h - 1.4 include/acpi/actypes.h - 1.4 include/acpi/acutils.h - 1.4 include/acpi/amlcode.h - 1.3 include/asm-alpha/elf.h - 1.3 include/asm-alpha/module.h - 1.2 include/asm-alpha/pci.h - 1.4 include/asm-alpha/unistd.h - 1.3 include/asm-arm/arch-anakin/dma.h - 1.2 include/asm-arm/arch-anakin/hardware.h - 1.2 include/asm-arm/arch-anakin/ide.h - 1.2 include/asm-arm/arch-anakin/io.h - 1.2 include/asm-arm/arch-anakin/irqs.h - 1.2 include/asm-arm/arch-anakin/memory.h - 1.2 include/asm-arm/arch-anakin/param.h - 1.2 include/asm-arm/arch-anakin/serial.h - 1.2 include/asm-arm/arch-anakin/serial_reg.h - 1.2 include/asm-arm/arch-anakin/system.h - 1.2 include/asm-arm/arch-anakin/time.h - 1.2 include/asm-arm/arch-anakin/timex.h - 1.2 include/asm-arm/arch-anakin/uncompress.h - 1.2 include/asm-arm/arch-anakin/vmalloc.h - 1.2 include/asm-arm/arch-ebsa285/irqs.h - 1.2 include/asm-arm/arch-shark/irqs.h - 1.2 include/asm-arm/dma-mapping.h - 1.3 include/asm-arm/hardirq.h - 1.2 include/asm-arm/hardware/amba.h - 1.3 include/asm-arm/system.h - 1.3 include/asm-arm26/thread_info.h - 1.3 include/asm-generic/dma-mapping.h - 1.2 include/asm-generic/pci-dma-compat.h - 1.2 include/asm-generic/siginfo.h - 1.2 include/asm-h8300/bitops.h - 1.4 include/asm-h8300/irq.h - 1.2 include/asm-h8300/traps.h - 1.2 include/asm-h8300/unistd.h - 1.3 include/asm-i386/acpi.h - 1.5 include/asm-i386/dma-mapping.h - 1.2 include/asm-i386/edd.h - 1.3 include/asm-i386/io.h - 1.3 include/asm-i386/mach-default/irq_vectors.h - 1.6 include/asm-i386/module.h - 1.3 include/asm-i386/mpspec.h - 1.3 include/asm-i386/node.h - 1.2 include/asm-i386/pci.h - 1.4 include/asm-i386/pgtable.h - 1.3 include/asm-i386/setup.h - 1.4 include/asm-i386/system.h - 1.3 include/asm-i386/topology.h - 1.3 include/asm-i386/unistd.h - 1.4 include/asm-ia64/acpi.h - 1.5 include/asm-ia64/compat.h - 1.2 include/asm-ia64/dma-mapping.h - 1.2 include/asm-ia64/gcc_intrin.h - 1.2 include/asm-ia64/hardirq.h - 1.2 include/asm-ia64/machvec.h - 1.4 include/asm-ia64/machvec_hpzx1.h - 1.2 include/asm-ia64/machvec_sn2.h - 1.4 include/asm-ia64/pci.h - 1.5 include/asm-ia64/processor.h - 1.6 include/asm-ia64/sal.h - 1.3 include/asm-ia64/sn/router.h - 1.3 include/asm-ia64/sn/sndrv.h - 1.3 include/asm-ia64/spinlock.h - 1.3 include/asm-ia64/uaccess.h - 1.5 include/asm-ia64/unistd.h - 1.3 include/asm-m68k/bitops.h - 1.3 include/asm-m68k/irq.h - 1.3 include/asm-m68k/unistd.h - 1.3 include/asm-m68knommu/unistd.h - 1.3 include/asm-mips/dma-mapping.h - 1.4 include/asm-mips/pci.h - 1.6 include/asm-mips/shmparam.h - 1.2 include/asm-parisc/dma-mapping.h - 1.3 include/asm-parisc/floppy.h - 1.2 include/asm-parisc/grfioctl.h - 1.2 include/asm-parisc/ide.h - 1.2 include/asm-parisc/io.h - 1.3 include/asm-parisc/ioctl.h - 1.3 include/asm-parisc/keyboard.h - 1.2 include/asm-parisc/md.h - 1.2 include/asm-parisc/namei.h - 1.2 include/asm-parisc/pci.h - 1.4 include/asm-parisc/semaphore.h - 1.2 include/asm-parisc/shmparam.h - 1.2 include/asm-parisc/superio.h - 1.3 include/asm-parisc/unistd.h - 1.4 include/asm-ppc/cputable.h - 1.2 include/asm-ppc/dma-mapping.h - 1.2 include/asm-ppc/elf.h - 1.2 include/asm-ppc/io.h - 1.3 include/asm-ppc/machdep.h - 1.4 include/asm-ppc/mmu_context.h - 1.2 include/asm-ppc/pci.h - 1.5 include/asm-ppc/pplus.h - 1.2 include/asm-ppc/ptrace.h - 1.2 include/asm-ppc/reg.h - 1.3 include/asm-ppc/reg_booke.h - 1.3 include/asm-ppc/serial.h - 1.2 include/asm-ppc/thread_info.h - 1.2 include/asm-ppc/todc.h - 1.3 include/asm-ppc/types.h - 1.2 include/asm-ppc/unistd.h - 1.4 include/asm-ppc64/abs_addr.h - 1.2 include/asm-ppc64/dma-mapping.h - 1.2 include/asm-ppc64/eeh.h - 1.3 include/asm-ppc64/hvcall.h - 1.5 include/asm-ppc64/iSeries/HvCallEvent.h - 1.3 include/asm-ppc64/iSeries/iSeries_pci.h - 1.4 include/asm-ppc64/iSeries/iSeries_proc.h - 1.3 include/asm-ppc64/iSeries/mf.h - 1.3 include/asm-ppc64/io.h - 1.5 include/asm-ppc64/lmb.h - 1.4 include/asm-ppc64/machdep.h - 1.5 include/asm-ppc64/mmzone.h - 1.4 include/asm-ppc64/page.h - 1.4 include/asm-ppc64/pci.h - 1.6 include/asm-ppc64/pmc.h - 1.2 include/asm-ppc64/posix_types.h - 1.2 include/asm-ppc64/proc_fs.h - 1.3 include/asm-ppc64/proc_pmc.h - 1.2 include/asm-ppc64/prom.h - 1.5 include/asm-ppc64/rtas.h - 1.3 include/asm-ppc64/unistd.h - 1.4 include/asm-s390/bitops.h - 1.4 include/asm-s390/cio.h - 1.3 include/asm-s390/compat.h - 1.3 include/asm-s390/elf.h - 1.2 include/asm-s390/lowcore.h - 1.2 include/asm-s390/mmu_context.h - 1.3 include/asm-s390/pgtable.h - 1.4 include/asm-s390/processor.h - 1.3 include/asm-s390/ptrace.h - 1.2 include/asm-s390/spinlock.h - 1.4 include/asm-s390/system.h - 1.3 include/asm-s390/types.h - 1.2 include/asm-s390/uaccess.h - 1.4 include/asm-s390/unistd.h - 1.4 include/asm-sh/cpu-sh3/cacheflush.h - 1.2 include/asm-sh/cpu-sh4/dma.h - 1.3 include/asm-sh/dma-mapping.h - 1.2 include/asm-sh/dma.h - 1.3 include/asm-sh/dreamcast/io.h - 1.2 include/asm-sh/hd64461/hd64461.h - 1.3 include/asm-sh/hd64461/io.h - 1.4 include/asm-sh/irq.h - 1.3 include/asm-sh/page.h - 1.3 include/asm-sh/pci.h - 1.5 include/asm-sh/pgtable.h - 1.3 include/asm-sh/processor.h - 1.4 include/asm-sh/sh2000/io.h - 1.2 include/asm-sh/signal.h - 1.2 include/asm-sh/types.h - 1.2 include/asm-sparc/asmmacro.h - 1.3 include/asm-sparc/bugs.h - 1.2 include/asm-sparc/delay.h - 1.2 include/asm-sparc/ide.h - 1.2 include/asm-sparc/oplib.h - 1.2 include/asm-sparc/page.h - 1.3 include/asm-sparc/pci.h - 1.4 include/asm-sparc/pgtable.h - 1.3 include/asm-sparc/sbus.h - 1.2 include/asm-sparc/semaphore.h - 1.3 include/asm-sparc/shmparam.h - 1.2 include/asm-sparc/smp.h - 1.2 include/asm-sparc/thread_info.h - 1.4 include/asm-sparc/unistd.h - 1.4 include/asm-sparc64/ide.h - 1.2 include/asm-sparc64/page.h - 1.2 include/asm-sparc64/pci.h - 1.4 include/asm-sparc64/pgalloc.h - 1.2 include/asm-sparc64/sbus.h - 1.2 include/asm-sparc64/shmparam.h - 1.2 include/asm-sparc64/siginfo.h - 1.2 include/asm-sparc64/svr4.h - 1.2 include/asm-sparc64/unistd.h - 1.4 include/asm-um/processor-generic.h - 1.2 include/asm-v850/pci.h - 1.4 include/asm-x86_64/acpi.h - 1.5 include/asm-x86_64/bitops.h - 1.3 include/asm-x86_64/calling.h - 1.4 include/asm-x86_64/compat.h - 1.3 include/asm-x86_64/hardirq.h - 1.2 include/asm-x86_64/io.h - 1.4 include/asm-x86_64/mpspec.h - 1.2 include/asm-x86_64/msr.h - 1.3 include/asm-x86_64/page.h - 1.2 include/asm-x86_64/pci.h - 1.5 include/asm-x86_64/processor.h - 1.4 include/asm-x86_64/proto.h - 1.4 include/asm-x86_64/siginfo.h - 1.2 include/asm-x86_64/smp.h - 1.5 include/asm-x86_64/system.h - 1.5 include/asm-x86_64/thread_info.h - 1.3 include/asm-x86_64/types.h - 1.2 include/asm-x86_64/vsyscall32.h - 1.3 include/linux/aio.h - 1.3 include/linux/blkdev.h - 1.6 include/linux/brlvger.h - 1.2 include/linux/cdrom.h - 1.4 include/linux/compat.h - 1.5 include/linux/compat_ioctl.h - 1.6 include/linux/compiler.h - 1.5 include/linux/console.h - 1.8 include/linux/cpu.h - 1.5 include/linux/crypto.h - 1.2 include/linux/device-mapper.h - 1.2 include/linux/device.h - 1.5 include/linux/dm-ioctl.h - 1.3 include/linux/dma-mapping.h - 1.2 include/linux/fb.h - 1.6 include/linux/fs.h - 1.6 include/linux/hiddev.h - 1.2 include/linux/hpfs_fs_i.h - 1.2 include/linux/hpfs_fs_sb.h - 1.2 include/linux/hugetlb.h - 1.4 include/linux/ide.h - 1.11 include/linux/init.h - 1.2 include/linux/interrupt.h - 1.2 include/linux/kernel_stat.h - 1.2 include/linux/kobject.h - 1.3 include/linux/libata.h - 1.5 include/linux/lockd/debug.h - 1.2 include/linux/lockd/lockd.h - 1.2 include/linux/loop.h - 1.3 include/linux/major.h - 1.3 include/linux/miscdevice.h - 1.3 include/linux/mm.h - 1.6 include/linux/mmzone.h - 1.6 include/linux/moduleparam.h - 1.3 include/linux/netdevice.h - 1.7 include/linux/netfilter_ipv4/ip_conntrack.h - 1.2 include/linux/nfs_fs.h - 1.4 include/linux/nfs_page.h - 1.3 include/linux/nfs_xdr.h - 1.3 include/linux/notifier.h - 1.2 include/linux/page-flags.h - 1.3 include/linux/pci.h - 1.6 include/linux/pci_ids.h - 1.8 include/linux/pkt_sched.h - 1.3 include/linux/proc_fs.h - 1.5 include/linux/raid/md_k.h - 1.5 include/linux/reiserfs_fs.h - 1.4 include/linux/rmap-locking.h - 1.2 include/linux/sched.h - 1.6 include/linux/security.h - 1.5 include/linux/serialP.h - 1.2 include/linux/serial_core.h - 1.3 include/linux/serio.h - 1.3 include/linux/sunrpc/debug.h - 1.2 include/linux/sunrpc/timer.h - 1.2 include/linux/sunrpc/xdr.h - 1.3 include/linux/sunrpc/xprt.h - 1.3 include/linux/swapops.h - 1.2 include/linux/sysctl.h - 1.12 include/linux/tcp.h - 1.4 include/linux/topology.h - 1.2 include/linux/udf_fs.h - 1.2 include/linux/ufs_fs.h - 1.2 include/linux/ufs_fs_i.h - 1.2 include/linux/usb.h - 1.5 include/linux/usb_gadget.h - 1.3 include/net/flow.h - 1.3 include/net/irda/vlsi_ir.h - 1.2 include/net/scm.h - 1.2 include/net/xfrm.h - 1.3 include/pcmcia/cs.h - 1.3 include/scsi/scsi.h - 1.5 include/scsi/scsi_device.h - 1.2 include/scsi/scsi_host.h - 1.2 include/sound/ac97_codec.h - 1.3 include/sound/asequencer.h - 1.3 include/sound/asound.h - 1.3 include/sound/cs46xx.h - 1.3 include/sound/cs8427.h - 1.2 include/sound/emu10k1.h - 1.3 include/sound/info.h - 1.3 include/sound/memalloc.h - 1.2 include/sound/pcm.h - 1.3 include/sound/pcm_oss.h - 1.3 include/sound/sndmagic.h - 1.3 include/sound/trident.h - 1.3 include/sound/version.h - 1.3 include/sound/ymfpci.h - 1.3 init/do_mounts.c - 1.3 init/do_mounts.h - 1.3 init/do_mounts_devfs.c - 1.3 init/do_mounts_initrd.c - 1.2 init/do_mounts_md.c - 1.2 init/do_mounts_rd.c - 1.3 init/initramfs.c - 1.3 init/main.c - 1.12 ipc/Makefile - 1.2 ipc/sem.c - 1.4 ipc/shm.c - 1.3 kernel/acct.c - 1.3 kernel/cpu.c - 1.4 kernel/exec_domain.c - 1.2 kernel/exit.c - 1.11 kernel/kallsyms.c - 1.8 kernel/module.c - 1.11 kernel/printk.c - 1.11 kernel/ptrace.c - 1.2 kernel/rcupdate.c - 1.3 kernel/resource.c - 1.4 kernel/sched.c - 1.12 kernel/signal.c - 1.8 kernel/softirq.c - 1.3 kernel/sysctl.c - 1.11 kernel/timer.c - 1.4 kernel/uid16.c - 1.3 kernel/workqueue.c - 1.4 lib/Makefile - 1.5 lib/inflate.c - 1.3 lib/radix-tree.c - 1.2 lib/zlib_deflate/deftree.c - 1.2 mm/fadvise.c - 1.4 mm/filemap.c - 1.8 mm/memory.c - 1.11 mm/mempool.c - 1.2 mm/mmap.c - 1.7 mm/mprotect.c - 1.2 mm/page_alloc.c - 1.6 mm/pdflush.c - 1.3 mm/readahead.c - 1.4 mm/rmap.c - 1.4 mm/shmem.c - 1.4 mm/slab.c - 1.5 mm/swap.c - 1.4 mm/swapfile.c - 1.4 mm/truncate.c - 1.2 mm/vmscan.c - 1.5 net/8021q/vlanproc.c - 1.2 net/Kconfig - 1.4 net/Makefile - 1.2 net/atm/lec.c - 1.3 net/atm/mpoa_proc.c - 1.2 net/bluetooth/af_bluetooth.c - 1.6 net/bluetooth/bnep/core.c - 1.5 net/bluetooth/bnep/netdev.c - 1.2 net/bluetooth/bnep/sock.c - 1.3 net/bluetooth/hci_event.c - 1.5 net/bluetooth/l2cap.c - 1.4 net/bluetooth/rfcomm/core.c - 1.5 net/bluetooth/sco.c - 1.3 net/core/Makefile - 1.2 net/core/dev.c - 1.7 net/core/flow.c - 1.4 net/decnet/README - 1.2 net/ipv4/Kconfig - 1.4 net/ipv4/devinet.c - 1.5 net/ipv4/igmp.c - 1.6 net/ipv4/ip_output.c - 1.5 net/ipv4/ipconfig.c - 1.3 net/ipv4/ipvs/Kconfig - 1.3 net/ipv4/ipvs/ip_vs_conn.c - 1.3 net/ipv4/ipvs/ip_vs_ctl.c - 1.3 net/ipv4/ipvs/ip_vs_lblc.c - 1.3 net/ipv4/ipvs/ip_vs_lblcr.c - 1.3 net/ipv4/netfilter/Kconfig - 1.3 net/ipv4/netfilter/ip_fw_compat_masq.c - 1.3 net/ipv4/netfilter/ip_nat_snmp_basic.c - 1.2 net/ipv4/netfilter/ip_nat_standalone.c - 1.3 net/ipv4/netfilter/ipchains_core.c - 1.2 net/ipv4/netfilter/ipt_MASQUERADE.c - 1.3 net/ipv4/netfilter/ipt_REJECT.c - 1.4 net/ipv4/tcp_diag.c - 1.2 net/ipv4/tcp_input.c - 1.3 net/ipv4/tcp_ipv4.c - 1.3 net/ipv4/xfrm4_policy.c - 1.2 net/ipv6/Makefile - 1.2 net/ipv6/addrconf.c - 1.6 net/ipv6/exthdrs.c - 1.6 net/ipv6/ip6_output.c - 1.6 net/ipv6/ipv6_syms.c - 1.3 net/ipv6/tcp_ipv6.c - 1.3 net/ipv6/xfrm6_policy.c - 1.3 net/irda/irlan/irlan_filter.c - 1.2 net/irda/irttp.c - 1.3 net/key/af_key.c - 1.4 net/netlink/netlink_dev.c - 1.2 net/packet/af_packet.c - 1.6 net/sched/Kconfig - 1.4 net/sched/Makefile - 1.3 net/sched/sch_htb.c - 1.4 net/sched/sch_tbf.c - 1.4 net/sctp/Kconfig - 1.4 net/sctp/bind_addr.c - 1.2 net/sctp/sm_make_chunk.c - 1.3 net/sctp/socket.c - 1.5 net/sctp/ulpevent.c - 1.2 net/sunrpc/auth_unix.c - 1.3 net/sunrpc/clnt.c - 1.3 net/sunrpc/pmap_clnt.c - 1.3 net/sunrpc/sched.c - 1.4 net/sunrpc/sunrpc_syms.c - 1.4 net/sunrpc/sysctl.c - 1.3 net/sunrpc/xdr.c - 1.3 net/sunrpc/xprt.c - 1.4 net/unix/af_unix.c - 1.5 net/xfrm/xfrm_policy.c - 1.5 net/xfrm/xfrm_user.c - 1.4 scripts/Makefile - 1.8 scripts/Makefile.build - 1.3 scripts/Makefile.lib - 1.3 scripts/Makefile.modpost - 1.3 scripts/docproc.c - 1.2 scripts/fixdep.c - 1.2 scripts/kallsyms.c - 1.7 scripts/kconfig/Makefile - 1.3 scripts/kconfig/confdata.c - 1.2 scripts/kconfig/expr.c - 1.2 scripts/kconfig/expr.h - 1.2 scripts/kconfig/qconf.cc - 1.3 scripts/kconfig/qconf.h - 1.2 scripts/kconfig/symbol.c - 1.3 scripts/modpost.c - 1.6 scripts/modpost.h - 1.3 scripts/split-include.c - 1.2 scripts/ver_linux - 1.2 security/commoncap.c - 1.4 security/dummy.c - 1.5 security/selinux/hooks.c - 1.6 security/selinux/include/av_perm_to_string.h - 1.4 security/selinux/include/av_permissions.h - 1.4 security/selinux/include/security.h - 1.3 security/selinux/selinuxfs.c - 1.4 security/selinux/ss/Makefile - 1.4 security/selinux/ss/avtab.c - 1.4 security/selinux/ss/avtab.h - 1.2 security/selinux/ss/mls.h - 1.2 security/selinux/ss/policydb.c - 1.4 security/selinux/ss/policydb.h - 1.2 security/selinux/ss/services.c - 1.5 sound/arm/Kconfig - 1.2 sound/arm/sa11xx-uda1341.c - 1.2 sound/core/Kconfig - 1.2 sound/core/Makefile - 1.3 sound/core/init.c - 1.3 sound/core/ioctl32/timer32.c - 1.2 sound/core/memalloc.c - 1.3 sound/core/oss/pcm_oss.c - 1.3 sound/core/pcm.c - 1.3 sound/core/pcm_lib.c - 1.3 sound/core/pcm_memory.c - 1.3 sound/core/pcm_misc.c - 1.3 sound/core/pcm_timer.c - 1.2 sound/core/seq/oss/seq_oss_init.c - 1.2 sound/core/seq/oss/seq_oss_midi.c - 1.2 sound/core/seq/oss/seq_oss_synth.c - 1.2 sound/core/seq/oss/seq_oss_synth.h - 1.2 sound/core/seq/seq_clientmgr.c - 1.3 sound/core/seq/seq_fifo.c - 1.3 sound/core/seq/seq_memory.c - 1.3 sound/core/seq/seq_midi.c - 1.3 sound/core/sgbuf.c - 1.2 sound/drivers/Kconfig - 1.2 sound/drivers/mpu401/Makefile - 1.2 sound/drivers/mpu401/mpu401.c - 1.3 sound/drivers/mpu401/mpu401_uart.c - 1.3 sound/drivers/opl3/Makefile - 1.2 sound/drivers/opl4/Makefile - 1.2 sound/drivers/serial-u16550.c - 1.3 sound/drivers/vx/Makefile - 1.2 sound/drivers/vx/vx_core.c - 1.3 sound/drivers/vx/vx_mixer.c - 1.2 sound/drivers/vx/vx_pcm.c - 1.3 sound/i2c/cs8427.c - 1.3 sound/i2c/other/Makefile - 1.3 sound/isa/Kconfig - 1.2 sound/isa/ad1816a/ad1816a_lib.c - 1.3 sound/isa/ad1848/ad1848_lib.c - 1.3 sound/isa/cmi8330.c - 1.3 sound/isa/cs423x/cs4231_lib.c - 1.3 sound/isa/dt019x.c - 1.3 sound/isa/es1688/es1688.c - 1.3 sound/isa/es1688/es1688_lib.c - 1.3 sound/isa/es18xx.c - 1.3 sound/isa/gus/gus_pcm.c - 1.3 sound/isa/gus/gusclassic.c - 1.3 sound/isa/gus/gusextreme.c - 1.3 sound/isa/gus/gusmax.c - 1.3 sound/isa/gus/interwave.c - 1.3 sound/isa/opti9xx/opti92x-ad1848.c - 1.3 sound/isa/sb/es968.c - 1.3 sound/isa/sb/sb16.c - 1.3 sound/isa/sb/sb16_main.c - 1.2 sound/isa/sb/sb8.c - 1.3 sound/isa/sb/sb8_main.c - 1.2 sound/isa/sscape.c - 1.3 sound/isa/wavefront/wavefront_synth.c - 1.2 sound/oss/Kconfig - 1.4 sound/oss/Makefile - 1.3 sound/oss/cmpci.c - 1.3 sound/oss/cs46xx.c - 1.3 sound/oss/dmasound/dmasound_core.c - 1.3 sound/oss/i810_audio.c - 1.3 sound/oss/nec_vrc5477.c - 1.3 sound/oss/nm256_audio.c - 1.2 sound/oss/opl3sa2.c - 1.2 sound/oss/rme96xx.c - 1.3 sound/oss/soundcard.c - 1.3 sound/oss/sys_timer.c - 1.2 sound/oss/via82cxxx_audio.c - 1.3 sound/oss/wavfront.c - 1.2 sound/parisc/Kconfig - 1.2 sound/parisc/harmony.c - 1.2 sound/pci/Kconfig - 1.3 sound/pci/Makefile - 1.3 sound/pci/ac97/Makefile - 1.3 sound/pci/ac97/ac97_codec.c - 1.3 sound/pci/ac97/ac97_patch.c - 1.3 sound/pci/ac97/ac97_patch.h - 1.3 sound/pci/ac97/ac97_proc.c - 1.3 sound/pci/ac97/ak4531_codec.c - 1.3 sound/pci/ali5451/ali5451.c - 1.3 sound/pci/als4000.c - 1.3 sound/pci/azt3328.c - 1.3 sound/pci/cmipci.c - 1.3 sound/pci/cs4281.c - 1.3 sound/pci/cs46xx/cs46xx.c - 1.2 sound/pci/cs46xx/cs46xx_lib.c - 1.3 sound/pci/cs46xx/dsp_spos.c - 1.2 sound/pci/emu10k1/emu10k1.c - 1.2 sound/pci/emu10k1/emu10k1_callback.c - 1.2 sound/pci/emu10k1/emu10k1_main.c - 1.3 sound/pci/emu10k1/emufx.c - 1.3 sound/pci/emu10k1/emupcm.c - 1.3 sound/pci/emu10k1/emuproc.c - 1.3 sound/pci/emu10k1/memory.c - 1.3 sound/pci/ens1370.c - 1.3 sound/pci/es1938.c - 1.3 sound/pci/es1968.c - 1.3 sound/pci/fm801.c - 1.3 sound/pci/ice1712/amp.c - 1.2 sound/pci/ice1712/aureon.c - 1.3 sound/pci/ice1712/delta.c - 1.3 sound/pci/ice1712/ews.c - 1.2 sound/pci/ice1712/hoontech.c - 1.2 sound/pci/ice1712/ice1712.c - 1.3 sound/pci/ice1712/ice1712.h - 1.3 sound/pci/ice1712/ice1724.c - 1.3 sound/pci/ice1712/revo.c - 1.2 sound/pci/intel8x0.c - 1.4 sound/pci/korg1212/korg1212.c - 1.3 sound/pci/maestro3.c - 1.3 sound/pci/rme32.c - 1.3 sound/pci/rme96.c - 1.3 sound/pci/rme9652/hdsp.c - 1.3 sound/pci/rme9652/rme9652.c - 1.3 sound/pci/sonicvibes.c - 1.3 sound/pci/trident/trident_main.c - 1.3 sound/pci/trident/trident_memory.c - 1.2 sound/pci/trident/trident_synth.c - 1.2 sound/pci/via82xx.c - 1.3 sound/pci/ymfpci/ymfpci_main.c - 1.3 sound/pcmcia/Kconfig - 1.3 sound/pcmcia/Makefile - 1.2 sound/ppc/Kconfig - 1.2 sound/ppc/pmac.c - 1.2 sound/ppc/powermac.c - 1.2 sound/ppc/tumbler.c - 1.3 sound/sparc/Kconfig - 1.2 sound/sparc/amd7930.c - 1.2 sound/sparc/cs4231.c - 1.2 sound/synth/Makefile - 1.2 sound/usb/Kconfig - 1.2 sound/usb/usbaudio.c - 1.4 sound/usb/usbaudio.h - 1.4 sound/usb/usbmidi.c - 1.3 sound/usb/usbmixer.c - 1.2 sound/usb/usbmixer_maps.c - 1.2 sound/usb/usbquirks.h - 1.3 arch/arm/configs/netwinder_defconfig - 1.3 drivers/ide/pci/sgiioc4.c - 1.6 drivers/i2c/chips/lm83.c - 1.3 drivers/char/watchdog/w83627hf_wdt.c - 1.4 arch/parisc/configs/712_defconfig - 1.2 arch/ia64/configs/sn2_defconfig - 1.4 net/bluetooth/cmtp/core.c - 1.2 drivers/usb/misc/emi62.c - 1.2 include/asm-ppc64/iSeries/vio.h - 1.4 include/asm-ppc64/vio.h - 1.4 arch/ia64/configs/generic_defconfig - 1.3 include/asm-x86_64/hpet.h - 1.2 drivers/net/forcedeth.c - 1.3 drivers/md/raid6main.c - 1.4 drivers/md/mktables.c - 1.2 drivers/input/keyboard/hpps2atkbd.h - 1.2 lib/bitmap.c - 1.5 drivers/i2c/chips/w83l785ts.c - 1.3 drivers/i2c/chips/lm90.c - 1.2 drivers/i2c/chips/asb100.c - 1.2 drivers/i2c/busses/i2c-parport.c - 1.2 drivers/i2c/busses/i2c-parport-light.c - 1.2 drivers/char/viocons.c - 1.3 drivers/bluetooth/bfusb.c - 1.3 drivers/bluetooth/bcm203x.c - 1.2 drivers/base/class_simple.c - 1.4 arch/sh/mm/pg-dma.c - 1.2 arch/sh/kernel/cpu/sh4/sq.c - 1.2 arch/sh/drivers/pci/pci.c - 1.2 arch/sh/drivers/pci/pci-dma.c - 1.2 arch/sh/drivers/pci/dma-dreamcast.c - 1.2 arch/sh/drivers/pci/Makefile - 1.2 arch/sh/drivers/pci/Kconfig - 1.2 arch/sh/drivers/dma/dma-sh.h - 1.2 arch/sh/drivers/dma/dma-sh.c - 1.2 arch/sh/drivers/dma/dma-api.c - 1.2 arch/sh/drivers/dma/Kconfig - 1.2 arch/sh/configs/defconfig-systemh - 1.2 arch/sh/configs/defconfig-snapgear - 1.2 arch/sh/configs/defconfig-se7751 - 1.2 arch/sh/cchips/Kconfig - 1.2 arch/ppc64/mm/hash_utils.c - 1.4 arch/ppc64/kernel/viopath.c - 1.4 arch/ppc64/kernel/vio.c - 1.4 drivers/macintosh/therm_windtunnel.c - 1.2 Documentation/sound/alsa/Joystick.txt - 1.2 drivers/macintosh/therm_pm72.h - 1.2 drivers/macintosh/therm_pm72.c - 1.2 drivers/macintosh/therm_adt7467.c - 1.2 drivers/macintosh/Kconfig - 1.4 net/sched/sch_hfsc.c - 1.3 sound/pci/ac97/ac97_pcm.c - 1.2 arch/parisc/configs/c3000_defconfig - 1.2 arch/parisc/configs/a500_defconfig - 1.2 sound/pci/bt87x.c - 1.2 sound/pci/ice1712/prodigy.c - 1.2 drivers/pnp/isapnp/Kconfig - 1.2 drivers/i2c/chips/gl518sm.c - 1.2 drivers/i2c/chips/fscher.c - 1.2 drivers/char/watchdog/pcwd_pci.c - 1.2 drivers/video/aty/radeon_monitor.c - 1.3 arch/sh/configs/defconfig-hp680 - 1.2 arch/sh/boards/hp6xx/hp680/setup.c - 1.2 arch/ppc64/kernel/pmac_time.c - 1.3 arch/ppc64/kernel/pmac_smp.c - 1.3 arch/ppc64/kernel/pmac_setup.c - 1.3 arch/ppc64/kernel/pci_dma_direct.c - 1.2 arch/ppc64/configs/pSeries_defconfig - 1.3 arch/ppc64/configs/g5_defconfig - 1.3 drivers/net/ibmveth.c - 1.2 drivers/net/e100.c - 1.2 drivers/pci/hotplug/pciehp_hpc.c - 1.2 drivers/pci/hotplug/pciehp_pci.c - 1.2 scripts/sumversion.c - 1.2 net/sunrpc/auth_gss/svcauth_gss.c - 1.2 drivers/pci/hotplug/pciehprm_acpi.c - 1.2 drivers/pci/hotplug/rpadlpar_core.c - 1.2 drivers/pci/hotplug/rpaphp.h - 1.2 drivers/pci/hotplug/rpaphp_core.c - 1.2 drivers/pci/hotplug/rpaphp_pci.c - 1.2 drivers/pci/hotplug/shpchp_pci.c - 1.2 drivers/s390/char/tape_class.c - 1.2 drivers/s390/char/tape_class.h - 1.2 drivers/scsi/aacraid/rkt.c - 1.2 drivers/md/dm-crypt.c - 1.2 drivers/isdn/hisax/hfc_usb.c - 1.2 drivers/char/watchdog/pcwd_usb.c - 1.2 drivers/cdrom/viocd.c - 1.2 crypto/arc4.c - 1.2 arch/x86_64/kernel/mce.c - 1.2 include/asm-ppc64/iommu.h - 1.2 arch/s390/appldata/appldata_os.c - 1.2 arch/s390/appldata/appldata_net_sum.c - 1.2 arch/s390/appldata/appldata_mem.c - 1.2 arch/s390/appldata/appldata_base.c - 1.2 arch/ppc64/kernel/pmac_iommu.c - 1.2 include/linux/syscalls.h - 1.2 arch/ppc64/kernel/pci_iommu.c - 1.2 arch/ppc64/kernel/pSeries_iommu.c - 1.2 arch/ppc64/kernel/iommu.c - 1.2 arch/ppc64/kernel/iSeries_iommu.c - 1.2 kernel/kthread.c - 1.2 arch/ppc64/configs/iSeries_defconfig - 1.2 kernel/stop_machine.c - 1.2 net/bluetooth/hci_sysfs.c - 1.2 arch/mips/mm/dma-noncoherent.c - 1.2 arch/mips/mm/dma-ip27.c - 1.2 arch/mips/mm/dma-coherent.c - 1.2 arch/mips/configs/workpad_defconfig - 1.2 arch/mips/configs/tb0226_defconfig - 1.2 arch/mips/configs/rm200_defconfig - 1.2 arch/mips/configs/pb1500_defconfig - 1.2 arch/mips/configs/lasat200_defconfig - 1.2 arch/mips/configs/ivr_defconfig - 1.2 arch/mips/configs/it8172_defconfig - 1.2 arch/mips/configs/hp-lj_defconfig - 1.2 arch/mips/configs/eagle_defconfig - 1.2 arch/mips/configs/capcella_defconfig - 1.2 arch/mips/configs/cobalt_defconfig - 1.2 arch/mips/configs/db1500_defconfig - 1.2 arch/mips/configs/ddb5476_defconfig - 1.2 arch/mips/configs/e55_defconfig - 1.2 From owner-linux-xfs@oss.sgi.com Mon Apr 5 23:24:13 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 05 Apr 2004 23:24:15 -0700 (PDT) Received: from samwel.tk (kluizenaar.xs4all.nl [213.84.184.247]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i366O8KO030091 for ; Mon, 5 Apr 2004 23:24:13 -0700 Received: from localhost ([127.0.0.1] helo=localhost.localdomain) by samwel.tk with esmtp (Exim 4.30) id 1BAk0A-00006j-9x; Tue, 06 Apr 2004 08:24:02 +0200 Subject: [patch 1/1] Laptop mode for XFS (patch against CVS) To: hch@infradead.org Cc: linux-xfs@oss.sgi.com, bart@samwel.tk From: bart@samwel.tk Date: Tue, 06 Apr 2004 08:24:00 +0200 Message-ID: X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bart@samwel.tk X-SA-Exim-Scanned: No (on samwel.tk); SAEximRunCond expanded to false X-archive-position: 2758 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bart@samwel.tk Precedence: bulk X-list: linux-xfs Content-Length: 3009 Lines: 78 From: Bart Samwel This is the same patch as earlier, but against the XFS CVS tree. Changelog: * Increase maximums for age_buffer and sync_interval so that values useful for laptop-mode are within the allowed range. * Switch from keeping track of "flush time" to keeping track of "creation time" for a pagebuf, so that changes in xfs_age_buffer can take effect immediately instead of only for pagebufs whose flush time is set anew. --- linux-2.6-xfs-bsamwel/fs/xfs/linux-2.6/xfs_buf.c | 4 ++-- linux-2.6-xfs-bsamwel/fs/xfs/linux-2.6/xfs_buf.h | 2 +- linux-2.6-xfs-bsamwel/fs/xfs/linux-2.6/xfs_globals.c | 4 ++-- 3 files changed, 5 insertions(+), 5 deletions(-) diff -puN fs/xfs/linux-2.6/xfs_buf.c~xfs-laptop-mode fs/xfs/linux-2.6/xfs_buf.c --- linux-2.6-xfs/fs/xfs/linux-2.6/xfs_buf.c~xfs-laptop-mode 2004-04-06 08:23:19.000000000 +0200 +++ linux-2.6-xfs-bsamwel/fs/xfs/linux-2.6/xfs_buf.c 2004-04-06 08:23:19.000000000 +0200 @@ -1497,7 +1497,7 @@ pagebuf_delwri_queue( } list_add_tail(&pb->pb_list, &pbd_delwrite_queue); - pb->pb_flushtime = jiffies + xfs_age_buffer; + pb->pb_queuetime = jiffies; spin_unlock(&pbd_delwrite_lock); if (unlock) @@ -1569,7 +1569,7 @@ pagebuf_daemon( if (!pagebuf_ispin(pb) && !pagebuf_cond_lock(pb)) { if (!force_flush && - time_before(jiffies, pb->pb_flushtime)) { + time_before(jiffies, pb->pb_queuetime + xfs_age_buffer)) { pagebuf_unlock(pb); break; } diff -puN fs/xfs/linux-2.6/xfs_buf.h~xfs-laptop-mode fs/xfs/linux-2.6/xfs_buf.h --- linux-2.6-xfs/fs/xfs/linux-2.6/xfs_buf.h~xfs-laptop-mode 2004-04-06 08:23:19.000000000 +0200 +++ linux-2.6-xfs-bsamwel/fs/xfs/linux-2.6/xfs_buf.h 2004-04-06 08:23:19.000000000 +0200 @@ -131,7 +131,7 @@ typedef int (*page_buf_bdstrat_t)(struct typedef struct xfs_buf { struct semaphore pb_sema; /* semaphore for lockables */ - unsigned long pb_flushtime; /* time to flush pagebuf */ + unsigned long pb_queuetime; /* time pagebuf was queued */ atomic_t pb_pin_count; /* pin count */ wait_queue_head_t pb_waiters; /* unpin waiters */ struct list_head pb_list; diff -puN fs/xfs/linux-2.6/xfs_globals.c~xfs-laptop-mode fs/xfs/linux-2.6/xfs_globals.c --- linux-2.6-xfs/fs/xfs/linux-2.6/xfs_globals.c~xfs-laptop-mode 2004-04-06 08:23:19.000000000 +0200 +++ linux-2.6-xfs-bsamwel/fs/xfs/linux-2.6/xfs_globals.c 2004-04-06 08:23:19.000000000 +0200 @@ -56,7 +56,7 @@ xfs_param_t xfs_params = { .symlink_mode = { 0, 0, 1 }, .panic_mask = { 0, 0, 127 }, .error_level = { 0, 3, 11 }, - .sync_interval = { HZ, 30*HZ, 60*HZ }, + .sync_interval = { HZ, 30*HZ, 7200*HZ }, .probe_dmapi = { 0, 1, 1 }, .probe_ioops = { 0, 0, 1 }, .probe_quota = { 0, 1, 1 }, @@ -65,7 +65,7 @@ xfs_param_t xfs_params = { .inherit_nodump = { 0, 1, 1 }, .inherit_noatim = { 0, 1, 1 }, .flush_interval = { HZ/2, HZ, 30*HZ }, - .age_buffer = { 1*HZ, 15*HZ, 300*HZ }, + .age_buffer = { 1*HZ, 15*HZ, 7200*HZ }, }; /* _ From owner-linux-xfs@oss.sgi.com Tue Apr 6 00:50:18 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 06 Apr 2004 00:50:22 -0700 (PDT) Received: from omx2.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i367oHKO004381 for ; Tue, 6 Apr 2004 00:50:18 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with SMTP id i369t4Kl006478 for ; Tue, 6 Apr 2004 02:55:05 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA05553; Tue, 6 Apr 2004 17:50:07 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i367nvpx239193; Tue, 6 Apr 2004 17:49:57 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id i368n02u000781; Tue, 6 Apr 2004 18:49:01 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i368mx3m000779; Tue, 6 Apr 2004 18:48:59 +1000 Date: Tue, 6 Apr 2004 18:48:59 +1000 From: Nathan Scott To: Christoph Hellwig , Kai Makisara Cc: linux-scsi@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: ST alloc failures Message-ID: <20040406084858.GA752@frodo> References: <20040402051355.GA1604@frodo> <20040402073207.A31736@infradead.org> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i Content-Transfer-Encoding: 8bit X-archive-position: 2759 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2371 Lines: 66 Hi there, On Sat, Apr 03, 2004 at 10:19:51AM +0300, Kai Makisara wrote: > On Fri, 2 Apr 2004, Christoph Hellwig wrote: > > > [linux-scsi is the right list for st problems, moving the thread there] > > > > On Fri, Apr 02, 2004 at 03:13:55PM +1000, Nathan Scott wrote: > > > Hi all, > > > > > > I'm seeing a bunch of large allocation attempts failing from > > > the SCSI tape driver when doing dumps and restores ... (this > > > is with a stock 2.6.4 kernel). > > > > > > xfsdump: page allocation failure. order:8, mode:0xd0 > > > Call Trace: > > > [] __alloc_pages+0x33b/0x3d0 > > > [] enlarge_buffer+0xdc/0x1b0 > > > [] st_map_user_pages+0x33/0x90 > > > [] setup_buffering+0xb4/0x160 > > > > This looks like the driver tries to pin down the userpages first > > (st_map_user_pages) but then fails and needs to use an inkernel > > buffer. Can you put some debug printks into st_map_user_pages > > to see why it fails? Apologies for the delay; after whacking in some printk's it looks like the point st decides to not pin down the user pages for me is here in sgl_map_user_pages: /* Too big */ if (nr_pages > max_pages) { return -ENOMEM; } In my cases nr_pages is always 256 and max_pages is always 96 (I see this printk a fair few times, and its always from this point). > Pinning down pages should not fail with most modern hardware except for > the following three cases: > > 1) A change in 2.6.4 (*) mandates st (and sg) not to use direct transfers > unless the user buffer is aligned at 512 byte boundary. This means, for > instance, that in most cases transfers from/to malloced/calloced buffers > are forced to use bounce buffers (alignment at 8 or 16 byte boundaries). > > 2) There is a bug in checking the allowed address range. Most SCSI > adapters support 64-bit addresses and so even lots of memory should not > prevent using direct transfers. I guess its not either of these two, from the printk? > 3) Some resource shortage that happened just now. This is not a bug. Hmm... I see this alot, but I have a fair bit of memory in the machine (its during stress and regression testing that I hit this, so not sure about the exact memory usage at each particular printk I see). Is this something we should be tuning in xfsdump/xfsrestore, Kai? (to make smaller requests?) cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Apr 6 02:57:55 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 06 Apr 2004 02:57:58 -0700 (PDT) Received: from vcgwp1.bit-drive.ne.jp (vcgwp1.bit-drive.ne.jp [211.9.32.211]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i369vsKO013266 for ; Tue, 6 Apr 2004 02:57:54 -0700 Received: (qmail 6783 invoked from network); 6 Apr 2004 18:57:52 +0900 Received: from unknown (HELO dns01.miraclelinux.com) (219.118.163.66) by vcgwp1.bit-drive.ne.jp with SMTP; 6 Apr 2004 18:57:52 +0900 Received: from miraclelinux.com (dhcp-0139.miraclelinux.com [10.1.0.139]) by dns01.miraclelinux.com (8.9.3+3.2W/3.7W/03090111) with ESMTP id SAA05349 for ; Tue, 6 Apr 2004 18:57:52 +0900 Message-ID: <40727F1D.9070204@miraclelinux.com> Date: Tue, 06 Apr 2004 18:57:49 +0900 From: "IKARASHI, Seiichi" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: XFS and grub Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2760 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ikarashi@miraclelinux.com Precedence: bulk X-list: linux-xfs Content-Length: 457 Lines: 17 Hi, Here is one more issue between XFS and grub. When you install grub, you have two options of the place where the grub goes into. One is MBR, the other is the first sector of the boot partition. For XFS, MBR is ok but installting into the first sector causes a problem though no problem for ext2/3 partitons, because a XFS partition seems to have its volume string at from 108th byte to 120th byte and it will be overwritten by grub. Is it FAQ? Sei From owner-linux-xfs@oss.sgi.com Tue Apr 6 04:34:33 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 06 Apr 2004 04:34:38 -0700 (PDT) Received: from K-7.stesmi.com (1-2-2-1a.has.sth.bostream.se [82.182.130.86]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i36BYWKO021491 for ; Tue, 6 Apr 2004 04:34:33 -0700 Received: from stesmi.com (deltaflyer.stesmi.com [192.168.1.14]) by K-7.stesmi.com (8.12.8/8.12.5) with ESMTP id i36BYRId020042; Tue, 6 Apr 2004 13:34:27 +0200 Message-ID: <407295B8.6050601@stesmi.com> Date: Tue, 06 Apr 2004 13:34:16 +0200 From: Stefan Smietanowski User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "IKARASHI, Seiichi" CC: linux-xfs@oss.sgi.com Subject: Re: XFS and grub References: <40727F1D.9070204@miraclelinux.com> In-Reply-To: <40727F1D.9070204@miraclelinux.com> Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2761 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stesmi@stesmi.com Precedence: bulk X-list: linux-xfs Content-Length: 818 Lines: 22 Hi. > Here is one more issue between XFS and grub. > > When you install grub, you have two options of the place > where the grub goes into. > One is MBR, the other is the first sector of the boot partition. > For XFS, MBR is ok but installting into the first sector > causes a problem though no problem for ext2/3 partitons, because > a XFS partition seems to have its volume string at from 108th byte > to 120th byte and it will be overwritten by grub. > > Is it FAQ? Yup. The reason is that XFS comes from the IRIX world and they don't have the same partition tables, etc as "we" do. XFS uses the partition format but not the partition table and on a PC you can install the first part of a bootloader right at the beginning of a partition, that's why it's there. On IRIX it works differently simply. // Stefan From owner-linux-xfs@oss.sgi.com Tue Apr 6 12:09:26 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 06 Apr 2004 12:09:31 -0700 (PDT) Received: from fep07-app.kolumbus.fi (fep07-0.kolumbus.fi [193.229.0.51]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i36J9PKO015769 for ; Tue, 6 Apr 2004 12:09:25 -0700 Received: from kai.makisara.local ([80.186.81.222]) by fep07-app.kolumbus.fi with ESMTP id <20040406190923.KJIH14522.fep07-app.kolumbus.fi@kai.makisara.local>; Tue, 6 Apr 2004 22:09:23 +0300 Date: Tue, 6 Apr 2004 22:09:22 +0300 (EEST) From: Kai Makisara X-X-Sender: makisara@kai.makisara.local To: Nathan Scott cc: Christoph Hellwig , linux-scsi@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: ST alloc failures In-Reply-To: <20040406084858.GA752@frodo> Message-ID: References: <20040402051355.GA1604@frodo> <20040402073207.A31736@infradead.org> <20040406084858.GA752@frodo> MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit X-archive-position: 2762 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Kai.Makisara@kolumbus.fi Precedence: bulk X-list: linux-xfs Content-Length: 4541 Lines: 104 On Tue, 6 Apr 2004, Nathan Scott wrote: > Hi there, > > On Sat, Apr 03, 2004 at 10:19:51AM +0300, Kai Makisara wrote: > > On Fri, 2 Apr 2004, Christoph Hellwig wrote: > > > > > [linux-scsi is the right list for st problems, moving the thread there] > > > > > > On Fri, Apr 02, 2004 at 03:13:55PM +1000, Nathan Scott wrote: > > > > Hi all, > > > > > > > > I'm seeing a bunch of large allocation attempts failing from > > > > the SCSI tape driver when doing dumps and restores ... (this > > > > is with a stock 2.6.4 kernel). > > > > > > > > xfsdump: page allocation failure. order:8, mode:0xd0 > > > > Call Trace: > > > > [] __alloc_pages+0x33b/0x3d0 > > > > [] enlarge_buffer+0xdc/0x1b0 > > > > [] st_map_user_pages+0x33/0x90 > > > > [] setup_buffering+0xb4/0x160 > > > > > > This looks like the driver tries to pin down the userpages first > > > (st_map_user_pages) but then fails and needs to use an inkernel > > > buffer. Can you put some debug printks into st_map_user_pages > > > to see why it fails? > > Apologies for the delay; after whacking in some printk's it looks > like the point st decides to not pin down the user pages for me is > here in sgl_map_user_pages: > > /* Too big */ > if (nr_pages > max_pages) { > return -ENOMEM; > } > > In my cases nr_pages is always 256 and max_pages is always 96 (I > see this printk a fair few times, and its always from this point). > OK. max_pages is the maximum number of scatter/gather segments supported by the SCSI adapter. > > Pinning down pages should not fail with most modern hardware except for > > the following three cases: > > > > 1) A change in 2.6.4 (*) mandates st (and sg) not to use direct transfers > > unless the user buffer is aligned at 512 byte boundary. This means, for > > instance, that in most cases transfers from/to malloced/calloced buffers > > are forced to use bounce buffers (alignment at 8 or 16 byte boundaries). > > > > 2) There is a bug in checking the allowed address range. Most SCSI > > adapters support 64-bit addresses and so even lots of memory should not > > prevent using direct transfers. > > I guess its not either of these two, from the printk? > Correct. 1) was something that would have explained why you see this starting from 2.6.4. I am happy that it is not 2 :-) > > 3) Some resource shortage that happened just now. This is not a bug. > > Hmm... I see this alot, but I have a fair bit of memory in the machine > (its during stress and regression testing that I hit this, so not sure > about the exact memory usage at each particular printk I see). > Having a lot of memory does not help because it gets fragmented, too. st is trying to allocate big chunks so that it can satisfy the user requests with the available number of s/g segments even when the user successively requests bigger and bigger block sizes. Usually smaller than maximum chunks can be used if the user just uses the same block size for subsequent requests. The driver tries to allocate smaller chunks if allocation of big chunks fails and the smaller chunks are big enough for the current user request. This is what happens in your case now. Earlier allocations with the big chunk size have succeeded and no error messages have been written. > Is this something we should be tuning in xfsdump/xfsrestore, Kai? > (to make smaller requests?) > There are actually two problems. As Christoph said, the messages you see are harmless. I have already sent to linux-scsi a patch that adds __GFP_NOWARN to the allocation. This should remove these error messages. The other problem is that you probably would like to use direct transfers between the xfsdump/xfsrestore buffer and the drive instead of using the "bounce" buffer in the driver. This is not possible unless the tape requests are small enough for the SCSI adapter. In your case the limit is 96 pages. You can try to increase this limit but it is not a general solution. I would recommend xfsdump/xfsrestore to use smaller requests if possible. 64 pages of 4 kB would make 256 kB. Using this request size should not limit throughput even with the fastest tape drives. I would like to make st somehow tell the users when it is using the driver buffer instead of direct transfers. Some users would probably like to know this because it limits throughput in some cases. The best idea I have so far is to log a message once for each open if this happens. Even this may be too much. Good ideas are welcome. -- Kai From owner-linux-xfs@oss.sgi.com Tue Apr 6 21:08:01 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 06 Apr 2004 21:08:03 -0700 (PDT) Received: from omx1.americas.sgi.com (cfcafw.sgi.com [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i37480KO011424 for ; Tue, 6 Apr 2004 21:08:01 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with SMTP id i3747rVC004317 for ; Tue, 6 Apr 2004 23:07:54 -0500 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.54.232]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA09757 for ; Wed, 7 Apr 2004 14:07:51 +1000 Received: from sherman.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by sherman.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id i3747pmX029901 for ; Wed, 7 Apr 2004 14:07:51 +1000 Received: (from nathans@localhost) by sherman.melbourne.sgi.com (8.12.8/8.12.8/Submit) id i3747ogM029899 for linux-xfs@oss.sgi.com; Wed, 7 Apr 2004 14:07:50 +1000 Date: Wed, 7 Apr 2004 14:07:50 +1000 From: Nathan Scott Message-Id: <200404070407.i3747ogM029899@sherman.melbourne.sgi.com> Subject: TAKE 904196 - merge fixups Apparently-To: X-archive-position: 2763 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sherman.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 524 Lines: 19 Put back a few odds and ends dropped in the previous kernel merge. Date: Tue Apr 6 21:04:16 PDT 2004 Workarea: sherman.melbourne.sgi.com:/build/nathans/2.6.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: 2.6.x-xfs:linux:169795a arch/i386/kernel/entry.S - 1.7 arch/i386/kernel/i8259.c - 1.8 arch/i386/kernel/io_apic.c - 1.9 arch/i386/kernel/nmi.c - 1.7 arch/i386/kernel/reboot.c - 1.7 arch/i386/kernel/smpboot.c - 1.8 arch/i386/kernel/traps.c - 1.7 fs/Kconfig - 1.9 From owner-linux-xfs@oss.sgi.com Tue Apr 6 23:23:28 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 06 Apr 2004 23:23:31 -0700 (PDT) Received: from zok.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i376NSKO015709 for ; Tue, 6 Apr 2004 23:23:28 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id i377QFiQ025169 for ; Wed, 7 Apr 2004 00:26:16 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA12312; Wed, 7 Apr 2004 16:23:18 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i376NG7X010301; Wed, 7 Apr 2004 16:23:16 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i376NFti010291; Wed, 7 Apr 2004 16:23:15 +1000 (EST) Date: Wed, 7 Apr 2004 16:23:14 +1000 From: Nathan Scott To: Oliver Kiddle Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: xfs and page allocation failures Message-ID: <20040407162314.A10240@wobbly.melbourne.sgi.com> References: <22084.1081244015@trentino.logica.co.uk> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <22084.1081244015@trentino.logica.co.uk>; from okiddle@yahoo.co.uk on Tue, Apr 06, 2004 at 11:33:35AM +0200 Content-Transfer-Encoding: 8bit X-archive-position: 2764 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2167 Lines: 57 Hi there, On Tue, Apr 06, 2004 at 11:33:35AM +0200, Oliver Kiddle wrote: > I posted back in January about problems I was having with 2.6.1. Thanks > for the help back then. I'm still having problems with the same > machine, though. > > 2.6.3 is usable (just three page allocation failures printed when I run > xfsdump). xfsdump crashed 2.6.4 and I never got around to trying to > capture the console output. I tried 2.6.5 yesterday and have had two > issues. The first, relatively harmless problem was two page allocation > failures printed when running xfsdump (output is below). > > Then, this morning, mountd was no longer working. NFS was still happily > working where clients had mounted the filesystems. rpcinfo -u was > getting a timeout for mountd. I tried first restarting rpc.mountd which > had no effect and then tried `/etc/init.d/nfs-kernel-server restart', > also to no effect. > > I've attached the relevant part of the dmesg output below. > > Thanks > > Oliver > > st0: Block limits 1 - 16777215 bytes. > xfsdump: page allocation failure. order:9, mode:0xd0 > Call Trace: > [] __alloc_pages+0x2e0/0x325 > [] enlarge_buffer+0xcf/0x182 This is xfsdump making requests of the SCSI tape driver with buffers which are too large for it to pin down, the warning is harmless and ST chugs on. I believe the warnings will be fixed in future kernels, and xfsdump/xfsrestore will need some tweaks to use more appropriately sized buffers. > Unable to handle kernel NULL pointer dereference at virtual address 00000004 > EIP is at free_block+0x48/0xc8 > Process kswapd0 (pid: 7, threadinfo=c1b74000 task=c1b791e0) > Call Trace: > [] cache_flusharray+0x3f/0xbc > [] kmem_cache_free+0x48/0x4c > [] linvfs_destroy_inode+0x1b/0x1f This looks like a use-after-free - freeing an inode for a second time, I think - I haven't come across this one before. I expect the second oops and pagebuf warnings will be a follow-on effect from this initial failure. The initial failure will need some more investigation - if you can reliably hit it pls let me know what/how you're doing that. thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Apr 7 00:13:45 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 07 Apr 2004 00:14:10 -0700 (PDT) Received: from zok.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i377DjKO018280 for ; Wed, 7 Apr 2004 00:13:45 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i3786qiQ027955 for ; Wed, 7 Apr 2004 01:06:52 -0700 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i3773sAL39921192; Wed, 7 Apr 2004 17:03:55 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i3773rT139848157; Wed, 7 Apr 2004 17:03:53 +1000 (EST) Date: Wed, 7 Apr 2004 17:03:53 +1000 (EST) From: Nathan Scott Message-Id: <200404070703.i3773rT139848157@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 912498 - fix 2.6 page state corruption X-archive-position: 2765 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 452 Lines: 15 Only use page->private to track page state for page cache pages. Affects people using filesystems with blocksize smaller than the page size, and with hugetlbfs enabled. Date: Wed Apr 7 00:00:13 PDT 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/clean-xfs-linux Inspected by: hch@lst.de The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:169801a linux-2.6/xfs_buf.c - 1.163 From owner-linux-xfs@oss.sgi.com Wed Apr 7 18:33:07 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 07 Apr 2004 18:33:09 -0700 (PDT) Received: from K-7.stesmi.com (1-2-2-1a.has.sth.bostream.se [82.182.130.86]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i381X5KO026066 for ; Wed, 7 Apr 2004 18:33:06 -0700 Received: from stesmi.com (deltaflyer.stesmi.com [192.168.1.14]) by K-7.stesmi.com (8.12.8/8.12.5) with ESMTP id i381WmId014446; Thu, 8 Apr 2004 03:32:49 +0200 Message-ID: <4074ABB3.500@stesmi.com> Date: Thu, 08 Apr 2004 03:32:35 +0200 From: Stefan Smietanowski User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steve Lord CC: "IKARASHI, Seiichi" , Christoph Hellwig , Chris Wedgwood , linux-xfs@oss.sgi.com Subject: Re: synchronization of XFS References: <4060F7FC.8090602@miraclelinux.com> <20040325063902.GA9697@dingdong.cryptoapps.com> <4062C97A.6030702@miraclelinux.com> <20040325124152.GA12078@dingdong.cryptoapps.com> <4062D7E5.6070501@stesmi.com> <20040325132200.GA12333@dingdong.cryptoapps.com> <4062E19A.90207@xfs.org> <20040325140723.GA12558@dingdong.cryptoapps.com> <20040325144519.A23764@infradead.org> <40635F04.6010109@xfs.org> <40636032.3000402@stesmi.com> <4063612E.4030109@xfs.org> <406361F2.6060308@stesmi.com> <4063650B.20600@xfs.org> <406365DE.2050006@stesmi.com> <4067B496.8060501@miraclelinux.com> <40682301.50508@xfs.org> In-Reply-To: <40682301.50508@xfs.org> Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2766 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stesmi@stesmi.com Precedence: bulk X-list: linux-xfs Content-Length: 1270 Lines: 40 Steve Lord wrote: > IKARASHI, Seiichi wrote: > >> >> How was this testing result? >> I suppose setting sync_interval to 1000 and sleeping 2 seconds >> after sync is basically same as sleeping 4 seconds or more with >> the default sync_interval value (3000?). >> >> Seiich >> > Except the default setting is 30000 or 30 seconds. > > I have not heard back from Stefan. > > Steve Alright. I took my x86-64 machine and installed FC2-test2 on it and it has the problem (original). I then just took the DVD and burnt me a new one. Same problem, naturally. Then I changed booty and added some code that checked if /proc/sys/fs/xfs/sync_interval existed and was writable at all and if it was, it wrote 1000 to it (1 second). Then I added a time.sleep(5) (5 seconds delay), a few more isys.sync() after that and finally another time.sleep(5) just to be on the safe side. And guess what - still no go :( At least I now have something I can work with again. Any more ideas? The kernel is based on 2.6.3 and I haven't looked into it if they patch anything relevant for us. Any more things anyone wants me to try - go right ahead and ask - it now takes me only roughly an hour to build and burn and test it, so it's not really painful as most of it's automated. // Stefan From owner-linux-xfs@oss.sgi.com Wed Apr 7 19:56:41 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 07 Apr 2004 19:56:44 -0700 (PDT) Received: from omx1.americas.sgi.com (cfcafw.sgi.com [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i382ufKO030130 for ; Wed, 7 Apr 2004 19:56:41 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i382uUVC032597 for ; Wed, 7 Apr 2004 21:56:34 -0500 Received: from boing.melbourne.sgi.com (localhost [127.0.0.1]) by boing.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i382uNTp289165; Thu, 8 Apr 2004 12:56:25 +1000 (AEST) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i382uKtB252783; Thu, 8 Apr 2004 12:56:20 +1000 (AEST) Date: Thu, 8 Apr 2004 12:56:20 +1000 From: Tim Shimmin To: linux-xfs@oss.sgi.com Cc: Kai.Makisara@metla.fi Subject: Re: ST alloc failures Message-ID: <20040408125620.R74050@boing.melbourne.sgi.com> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Content-Transfer-Encoding: 8bit X-archive-position: 2767 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1084 Lines: 28 Hi, Kai Makisara wrote: > The other problem is that you probably would like to use direct transfers > between the xfsdump/xfsrestore buffer and the drive instead of using the > "bounce" buffer in the driver. This is not possible unless the tape > requests are small enough for the SCSI adapter. In your case the limit is > 96 pages. You can try to increase this limit but it is not a general > solution. > > I would recommend xfsdump/xfsrestore to use smaller requests if possible. > 64 pages of 4 kB would make 256 kB. Using this request size should not > limit throughput even with the fastest tape drives. > Okay. Thanks for the advice, Kai. Would have been nice to realise this at the outset of the port...nevermind, I should have asked you then ;-) xfsdump/restore on Linux use a default blocksize of 1Mb for local tapes. (xfsdump/restore on IRIX uses 2MB). One can specify the blocksize to use for xfsdump/xfsrestore using the -b option (given in bytes, so for 256K, one would use "-b 262144"). One must remember to use the same option for the restore. Cheers, Tim. From owner-linux-xfs@oss.sgi.com Wed Apr 7 22:00:42 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 07 Apr 2004 22:00:44 -0700 (PDT) Received: from zok.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3850gKO004592 for ; Wed, 7 Apr 2004 22:00:42 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i3863XiQ021802 for ; Wed, 7 Apr 2004 23:03:36 -0700 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i3850BAL37213558; Thu, 8 Apr 2004 15:00:11 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i3850AGo40729447; Thu, 8 Apr 2004 15:00:10 +1000 (EST) Date: Thu, 8 Apr 2004 15:00:10 +1000 (EST) From: Nathan Scott Message-Id: <200404080500.i3850AGo40729447@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 912646 - 2.6 mount fixes X-archive-position: 2768 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 364 Lines: 13 Fix some cases where we returned fill_super success, instead of failing. Date: Wed Apr 7 21:59:21 PDT 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/clean-xfs-linux Inspected by: cattelan@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:169865a linux-2.6/xfs_super.c - 1.300 From owner-linux-xfs@oss.sgi.com Thu Apr 8 00:48:33 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 08 Apr 2004 00:48:38 -0700 (PDT) Received: from dingdong.cryptoapps.com (uslink-66.173.43-129.uslink.net [66.173.43.129] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i387mWKO013010 for ; Thu, 8 Apr 2004 00:48:33 -0700 Received: by dingdong.cryptoapps.com (Postfix, from userid 1001) id A7319FB8FB; Thu, 8 Apr 2004 02:48:26 -0500 (CDT) Date: Thu, 8 Apr 2004 00:48:26 -0700 From: Chris Wedgwood To: Stefan Smietanowski Cc: Steve Lord , "IKARASHI, Seiichi" , Christoph Hellwig , linux-xfs@oss.sgi.com Subject: Re: synchronization of XFS Message-ID: <20040408074826.GA25688@dingdong.cryptoapps.com> References: <20040325144519.A23764@infradead.org> <40635F04.6010109@xfs.org> <40636032.3000402@stesmi.com> <4063612E.4030109@xfs.org> <406361F2.6060308@stesmi.com> <4063650B.20600@xfs.org> <406365DE.2050006@stesmi.com> <4067B496.8060501@miraclelinux.com> <40682301.50508@xfs.org> <4074ABB3.500@stesmi.com> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4074ABB3.500@stesmi.com> Content-Transfer-Encoding: 8bit X-archive-position: 2769 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 140 Lines: 9 On Thu, Apr 08, 2004 at 03:32:35AM +0200, Stefan Smietanowski wrote: > Any more ideas? did freeze/unfreeze make any difference? --cw From owner-linux-xfs@oss.sgi.com Thu Apr 8 03:48:44 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 08 Apr 2004 03:48:46 -0700 (PDT) Received: from K-7.stesmi.com (1-2-2-1a.has.sth.bostream.se [82.182.130.86]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i38AmhKO031090 for ; Thu, 8 Apr 2004 03:48:44 -0700 Received: from stesmi.com (deltaflyer.stesmi.com [192.168.1.14]) by K-7.stesmi.com (8.12.8/8.12.5) with ESMTP id i38AmXId004641; Thu, 8 Apr 2004 12:48:33 +0200 Message-ID: <40752DF3.2070109@stesmi.com> Date: Thu, 08 Apr 2004 12:48:19 +0200 From: Stefan Smietanowski User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Wedgwood CC: Steve Lord , "IKARASHI, Seiichi" , Christoph Hellwig , linux-xfs@oss.sgi.com Subject: Re: synchronization of XFS References: <20040325144519.A23764@infradead.org> <40635F04.6010109@xfs.org> <40636032.3000402@stesmi.com> <4063612E.4030109@xfs.org> <406361F2.6060308@stesmi.com> <4063650B.20600@xfs.org> <406365DE.2050006@stesmi.com> <4067B496.8060501@miraclelinux.com> <40682301.50508@xfs.org> <4074ABB3.500@stesmi.com> <20040408074826.GA25688@dingdong.cryptoapps.com> In-Reply-To: <20040408074826.GA25688@dingdong.cryptoapps.com> Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2770 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stesmi@stesmi.com Precedence: bulk X-list: linux-xfs Content-Length: 137 Lines: 10 Hi Chris. >>Any more ideas? > > did freeze/unfreeze make any difference? Haven't tried - Can you tell me how to do that ? // Stefan From owner-linux-xfs@oss.sgi.com Thu Apr 8 05:20:56 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 08 Apr 2004 05:21:00 -0700 (PDT) Received: from vcgwp1.bit-drive.ne.jp (vcgwp1.bit-drive.ne.jp [211.9.32.211]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i38CKtKO019565 for ; Thu, 8 Apr 2004 05:20:55 -0700 Received: (qmail 12222 invoked from network); 8 Apr 2004 21:20:53 +0900 Received: from unknown (HELO dns01.miraclelinux.com) (219.118.163.66) by vcgwp1.bit-drive.ne.jp with SMTP; 8 Apr 2004 21:20:53 +0900 Received: from miraclelinux.com (dhcp-0139.miraclelinux.com [10.1.0.139]) by dns01.miraclelinux.com (8.9.3+3.2W/3.7W/03090111) with ESMTP id VAA10270; Thu, 8 Apr 2004 21:20:53 +0900 Message-ID: <407543A1.7090306@miraclelinux.com> Date: Thu, 08 Apr 2004 21:20:49 +0900 From: "IKARASHI, Seiichi" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja MIME-Version: 1.0 To: Stefan Smietanowski CC: Chris Wedgwood , Steve Lord , Christoph Hellwig , linux-xfs@oss.sgi.com Subject: Re: synchronization of XFS References: <20040325144519.A23764@infradead.org> <40635F04.6010109@xfs.org> <40636032.3000402@stesmi.com> <4063612E.4030109@xfs.org> <406361F2.6060308@stesmi.com> <4063650B.20600@xfs.org> <406365DE.2050006@stesmi.com> <4067B496.8060501@miraclelinux.com> <40682301.50508@xfs.org> <4074ABB3.500@stesmi.com> <20040408074826.GA25688@dingdong.cryptoapps.com> <40752DF3.2070109@stesmi.com> In-Reply-To: <40752DF3.2070109@stesmi.com> Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2771 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ikarashi@miraclelinux.com Precedence: bulk X-list: linux-xfs Content-Length: 231 Lines: 18 Hi Stefan Smietanowski wrote: > Hi Chris. > >>> Any more ideas? >> >> >> did freeze/unfreeze make any difference? > > > Haven't tried - Can you tell me how to do that ? xfs_freeze -f /mount-point xfs_freeze -u /mount-point From owner-linux-xfs@oss.sgi.com Thu Apr 8 05:36:36 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 08 Apr 2004 05:36:39 -0700 (PDT) Received: from K-7.stesmi.com (1-2-2-1a.has.sth.bostream.se [82.182.130.86]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i38CaZKO020481 for ; Thu, 8 Apr 2004 05:36:36 -0700 Received: from stesmi.com (deltaflyer.stesmi.com [192.168.1.14]) by K-7.stesmi.com (8.12.8/8.12.5) with ESMTP id i38CaRId009150; Thu, 8 Apr 2004 14:36:27 +0200 Message-ID: <4075473E.40702@stesmi.com> Date: Thu, 08 Apr 2004 14:36:14 +0200 From: Stefan Smietanowski User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "IKARASHI, Seiichi" CC: Chris Wedgwood , Steve Lord , Christoph Hellwig , linux-xfs@oss.sgi.com Subject: Re: synchronization of XFS References: <20040325144519.A23764@infradead.org> <40635F04.6010109@xfs.org> <40636032.3000402@stesmi.com> <4063612E.4030109@xfs.org> <406361F2.6060308@stesmi.com> <4063650B.20600@xfs.org> <406365DE.2050006@stesmi.com> <4067B496.8060501@miraclelinux.com> <40682301.50508@xfs.org> <4074ABB3.500@stesmi.com> <20040408074826.GA25688@dingdong.cryptoapps.com> <40752DF3.2070109@stesmi.com> <407543A1.7090306@miraclelinux.com> In-Reply-To: <407543A1.7090306@miraclelinux.com> Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2772 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stesmi@stesmi.com Precedence: bulk X-list: linux-xfs Content-Length: 747 Lines: 44 IKARASHI, Seiichi wrote: > Hi > > Stefan Smietanowski wrote: > >> Hi Chris. >> >>>> Any more ideas? >>> >>> >>> >>> did freeze/unfreeze make any difference? >> >> >> >> Haven't tried - Can you tell me how to do that ? > > > xfs_freeze -f /mount-point > xfs_freeze -u /mount-point > Alright. I'll try that. Thanx. Now another question that I just thought about : Can I freeze the root ("/") ? (I need that possibility) And what happens if I try to freeze a dir that's not it's own partition? Going to rebuild the thing now to try that though. Get back to you all soon. Oh yes, I just remembered a thought from someone to modify GRUB to open using O_DIRECT as well - that might help. I'm going to try these things out now. // Stefan From owner-linux-xfs@oss.sgi.com Thu Apr 8 11:24:26 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 08 Apr 2004 11:24:38 -0700 (PDT) Received: from dingdong.cryptoapps.com (uslink-66.173.43-129.uslink.net [66.173.43.129] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i38IOOKO013229 for ; Thu, 8 Apr 2004 11:24:26 -0700 Received: by dingdong.cryptoapps.com (Postfix, from userid 1001) id 08202FB8FB; Thu, 8 Apr 2004 13:24:19 -0500 (CDT) Date: Thu, 8 Apr 2004 11:24:19 -0700 From: Chris Wedgwood To: Stefan Smietanowski Cc: "IKARASHI, Seiichi" , Steve Lord , Christoph Hellwig , linux-xfs@oss.sgi.com Subject: Re: synchronization of XFS Message-ID: <20040408182419.GA30488@dingdong.cryptoapps.com> References: <406361F2.6060308@stesmi.com> <4063650B.20600@xfs.org> <406365DE.2050006@stesmi.com> <4067B496.8060501@miraclelinux.com> <40682301.50508@xfs.org> <4074ABB3.500@stesmi.com> <20040408074826.GA25688@dingdong.cryptoapps.com> <40752DF3.2070109@stesmi.com> <407543A1.7090306@miraclelinux.com> <4075473E.40702@stesmi.com> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4075473E.40702@stesmi.com> Content-Transfer-Encoding: 8bit X-archive-position: 2774 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 504 Lines: 20 On Thu, Apr 08, 2004 at 02:36:14PM +0200, Stefan Smietanowski wrote: > Can I freeze the root ("/") ? (I need that possibility) yes > And what happens if I try to freeze a dir that's not it's own > partition? the partition will be frozen > Oh yes, I just remembered a thought from someone to modify GRUB to > open using O_DIRECT as well - that might help. that was probably me, however, i realise now it won't work either. you need to convince the fs to flush all dirty data and metadata --cw From owner-linux-xfs@oss.sgi.com Thu Apr 8 13:18:18 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 08 Apr 2004 13:18:23 -0700 (PDT) Received: from K-7.stesmi.com (1-2-2-1a.has.sth.bostream.se [82.182.130.86]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i38KIHKO022479 for ; Thu, 8 Apr 2004 13:18:18 -0700 Received: from stesmi.com (deltaflyer.stesmi.com [192.168.1.14]) by K-7.stesmi.com (8.12.8/8.12.5) with ESMTP id i38KI7Id027985; Thu, 8 Apr 2004 22:18:07 +0200 Message-ID: <4075B371.8050705@stesmi.com> Date: Thu, 08 Apr 2004 22:17:53 +0200 From: Stefan Smietanowski User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Wedgwood CC: "IKARASHI, Seiichi" , Steve Lord , Christoph Hellwig , linux-xfs@oss.sgi.com Subject: Re: synchronization of XFS References: <406361F2.6060308@stesmi.com> <4063650B.20600@xfs.org> <406365DE.2050006@stesmi.com> <4067B496.8060501@miraclelinux.com> <40682301.50508@xfs.org> <4074ABB3.500@stesmi.com> <20040408074826.GA25688@dingdong.cryptoapps.com> <40752DF3.2070109@stesmi.com> <407543A1.7090306@miraclelinux.com> <4075473E.40702@stesmi.com> <20040408182419.GA30488@dingdong.cryptoapps.com> In-Reply-To: <20040408182419.GA30488@dingdong.cryptoapps.com> Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2775 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stesmi@stesmi.com Precedence: bulk X-list: linux-xfs Content-Length: 1221 Lines: 39 Hi Chris. >>Can I freeze the root ("/") ? (I need that possibility) > > yes I noticed as much. And guess what - it worked! No delays or anything (extra) needed. It just works fine now. What I'm about to test is a different way of doing it since I can't be arsed to (in the installer) try to figure out which the boot device is I'll simply freeze /, unfreeze /, freeze /boot and finally unfreeze /boot. Yes, cumbersome, yes, might slow things down, but what the hell, it's right at the end of the install. >>And what happens if I try to freeze a dir that's not it's own >>partition? > > the partition will be frozen That's nice. Oh well, nothing to worry about, it just means that if you don't have a seperate /boot your root partition will be frozen and unfrozen twice. >>Oh yes, I just remembered a thought from someone to modify GRUB to >>open using O_DIRECT as well - that might help. > > that was probably me, however, i realise now it won't work either. > you need to convince the fs to flush all dirty data and metadata Right. Well, what I have left to test is what happens if the root and/or /boot partition isn't xfs. I'll only try using ext3 though. But partial success so far at least. // Stefan From owner-linux-xfs@oss.sgi.com Thu Apr 8 13:25:42 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 08 Apr 2004 13:25:53 -0700 (PDT) Received: from dingdong.cryptoapps.com (uslink-66.173.43-129.uslink.net [66.173.43.129] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i38KPeKO023066 for ; Thu, 8 Apr 2004 13:25:42 -0700 Received: by dingdong.cryptoapps.com (Postfix, from userid 1001) id CBE67FB8FB; Thu, 8 Apr 2004 15:25:35 -0500 (CDT) Date: Thu, 8 Apr 2004 13:25:35 -0700 From: Chris Wedgwood To: Stefan Smietanowski Cc: "IKARASHI, Seiichi" , Steve Lord , Christoph Hellwig , linux-xfs@oss.sgi.com Subject: Re: synchronization of XFS Message-ID: <20040408202535.GA31618@dingdong.cryptoapps.com> References: <406365DE.2050006@stesmi.com> <4067B496.8060501@miraclelinux.com> <40682301.50508@xfs.org> <4074ABB3.500@stesmi.com> <20040408074826.GA25688@dingdong.cryptoapps.com> <40752DF3.2070109@stesmi.com> <407543A1.7090306@miraclelinux.com> <4075473E.40702@stesmi.com> <20040408182419.GA30488@dingdong.cryptoapps.com> <4075B371.8050705@stesmi.com> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4075B371.8050705@stesmi.com> Content-Transfer-Encoding: 8bit X-archive-position: 2776 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 995 Lines: 31 On Thu, Apr 08, 2004 at 10:17:53PM +0200, Stefan Smietanowski wrote: > I noticed as much. And guess what - it worked! ok cool, that also confirms what people suspected isgoing on really is i still wonder about grub using O_DIRECT though for another reason, that is corruption/nasties when doing block access on a mounted fs hch --- can you comment here perhaps? would that be a dafer way to go? > That's nice. Oh well, nothing to worry about, it just means > that if you don't have a seperate /boot your root partition > will be frozen and unfrozen twice. freezing a second time w/o much dirty data will be pretty quick and painless > Right. Well, what I have left to test is what happens if the root > and/or /boot partition isn't xfs. I'll only try using ext3 though. maybe hack the installer to check the fs-type then perhaps and do thr freeze only if it's xfs using the ioctl's rather than calling out to an external program let me know if you want example code for that --cw From owner-linux-xfs@oss.sgi.com Thu Apr 8 15:29:48 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 08 Apr 2004 15:29:50 -0700 (PDT) Received: from K-7.stesmi.com (1-2-2-1a.has.sth.bostream.se [82.182.130.86]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i38MTkKO028672 for ; Thu, 8 Apr 2004 15:29:47 -0700 Received: from stesmi.com (deltaflyer.stesmi.com [192.168.1.14]) by K-7.stesmi.com (8.12.8/8.12.5) with ESMTP id i38MTcId000778; Fri, 9 Apr 2004 00:29:38 +0200 Message-ID: <4075D244.2070905@stesmi.com> Date: Fri, 09 Apr 2004 00:29:24 +0200 From: Stefan Smietanowski User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Wedgwood CC: "IKARASHI, Seiichi" , Steve Lord , Christoph Hellwig , linux-xfs@oss.sgi.com Subject: Re: synchronization of XFS References: <406365DE.2050006@stesmi.com> <4067B496.8060501@miraclelinux.com> <40682301.50508@xfs.org> <4074ABB3.500@stesmi.com> <20040408074826.GA25688@dingdong.cryptoapps.com> <40752DF3.2070109@stesmi.com> <407543A1.7090306@miraclelinux.com> <4075473E.40702@stesmi.com> <20040408182419.GA30488@dingdong.cryptoapps.com> <4075B371.8050705@stesmi.com> <20040408202535.GA31618@dingdong.cryptoapps.com> In-Reply-To: <20040408202535.GA31618@dingdong.cryptoapps.com> Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2777 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stesmi@stesmi.com Precedence: bulk X-list: linux-xfs Content-Length: 2339 Lines: 66 >>I noticed as much. And guess what - it worked! > > ok cool, that also confirms what people suspected isgoing on really is > > i still wonder about grub using O_DIRECT though for another reason, > that is corruption/nasties when doing block access on a mounted fs Yeah, but it's only reading it, not writing it. Nasties - could happen I guess. Corruption - don't see exactly how that could happen. > hch --- can you comment here perhaps? would that be a dafer way to > go? > >>That's nice. Oh well, nothing to worry about, it just means >>that if you don't have a seperate /boot your root partition >>will be frozen and unfrozen twice. > > freezing a second time w/o much dirty data will be pretty quick and > painless Yeah, I can't clock any difference here at all. >>Right. Well, what I have left to test is what happens if the root >>and/or /boot partition isn't xfs. I'll only try using ext3 though. > > maybe hack the installer to check the fs-type then perhaps and do thr > freeze only if it's xfs using the ioctl's rather than calling out to > an external program Checking the FS type - yes, it involves some hackery pokery but it is doable. Right now all it does is check if xfs_freeze is installed and calls it twice each for both / and /boot (one freeze and one unfreeze). > let me know if you want example code for that Well, the installer's written in python so I need to call out to an external program anyway (don't I?) to do the ioctl so I don't see the win there - it's either calling some_program or xfs_freeze. To be strict - it's actually not the installer itself I'm hacking on right now - it's booty, but it's also written in python so the same applies. Latest status is that I have tested the following combinations: / xfs => works / ext3 => works /, /boot xfs => works /, /boot ext3 => works / xfs, /boot ext3 => works / ext3, /boot xfs => works That's basically all combinations possible using ext3 and/or xfs. xfs_freeze simply tells us that it only works on xfs if I call it on an ext3 part and if we don't have any xfs at all then the program xfs_freeze isn't installed and then it's not called at all. As soon as I resurrect the x86 distro building machine I'll incoroprate these changes into the installer there and then there'll be a new DVD out that works even better now :) // Stefan From owner-linux-xfs@oss.sgi.com Thu Apr 8 17:43:04 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 08 Apr 2004 17:43:08 -0700 (PDT) Received: from vcgwp1.bit-drive.ne.jp (vcgwp1.bit-drive.ne.jp [211.9.32.211]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i390h3KO003414 for ; Thu, 8 Apr 2004 17:43:03 -0700 Received: (qmail 14823 invoked from network); 9 Apr 2004 09:43:01 +0900 Received: from unknown (HELO dns01.miraclelinux.com) (219.118.163.66) by vcgwp1.bit-drive.ne.jp with SMTP; 9 Apr 2004 09:43:01 +0900 Received: from miraclelinux.com (dhcp-0139.miraclelinux.com [10.1.0.139]) by dns01.miraclelinux.com (8.9.3+3.2W/3.7W/03090111) with ESMTP id JAA16543; Fri, 9 Apr 2004 09:43:01 +0900 Message-ID: <4075F191.5040406@miraclelinux.com> Date: Fri, 09 Apr 2004 09:42:57 +0900 From: "IKARASHI, Seiichi" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja MIME-Version: 1.0 To: Stefan Smietanowski CC: Chris Wedgwood , Steve Lord , Christoph Hellwig , linux-xfs@oss.sgi.com Subject: Re: synchronization of XFS References: <406365DE.2050006@stesmi.com> <4067B496.8060501@miraclelinux.com> <40682301.50508@xfs.org> <4074ABB3.500@stesmi.com> <20040408074826.GA25688@dingdong.cryptoapps.com> <40752DF3.2070109@stesmi.com> <407543A1.7090306@miraclelinux.com> <4075473E.40702@stesmi.com> <20040408182419.GA30488@dingdong.cryptoapps.com> <4075B371.8050705@stesmi.com> <20040408202535.GA31618@dingdong.cryptoapps.com> <4075D244.2070905@stesmi.com> In-Reply-To: <4075D244.2070905@stesmi.com> Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2778 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ikarashi@miraclelinux.com Precedence: bulk X-list: linux-xfs Content-Length: 711 Lines: 29 Stefan Smietanowski wrote: >>> I noticed as much. And guess what - it worked! >> Good news! >> >> maybe hack the installer to check the fs-type then perhaps and do thr >> freeze only if it's xfs using the ioctl's rather than calling out to >> an external program > > > Checking the FS type - yes, it involves some hackery pokery but it is > doable. Right now all it does is check if xfs_freeze is installed and > calls it twice each for both / and /boot (one freeze and one unfreeze). Checking the filesystem type can be done in bootloaderInfo.py of booty as follows: import fsset if fsset.isValidXFS(bootDev): // execute xfs_freeze -f for bootDev // execute xfs_freeze -u for bootDev -Sei From owner-linux-xfs@oss.sgi.com Thu Apr 8 18:22:43 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 08 Apr 2004 18:23:06 -0700 (PDT) Received: from K-7.stesmi.com (1-2-2-1a.has.sth.bostream.se [82.182.130.86]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i391MfKO008213 for ; Thu, 8 Apr 2004 18:22:42 -0700 Received: from stesmi.com (deltaflyer.stesmi.com [192.168.1.14]) by K-7.stesmi.com (8.12.8/8.12.5) with ESMTP id i391MYId007731; Fri, 9 Apr 2004 03:22:34 +0200 Message-ID: <4075FACC.3010105@stesmi.com> Date: Fri, 09 Apr 2004 03:22:20 +0200 From: Stefan Smietanowski User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "IKARASHI, Seiichi" CC: Chris Wedgwood , Steve Lord , Christoph Hellwig , linux-xfs@oss.sgi.com Subject: Re: synchronization of XFS References: <406365DE.2050006@stesmi.com> <4067B496.8060501@miraclelinux.com> <40682301.50508@xfs.org> <4074ABB3.500@stesmi.com> <20040408074826.GA25688@dingdong.cryptoapps.com> <40752DF3.2070109@stesmi.com> <407543A1.7090306@miraclelinux.com> <4075473E.40702@stesmi.com> <20040408182419.GA30488@dingdong.cryptoapps.com> <4075B371.8050705@stesmi.com> <20040408202535.GA31618@dingdong.cryptoapps.com> <4075D244.2070905@stesmi.com> <4075F191.5040406@miraclelinux.com> In-Reply-To: <4075F191.5040406@miraclelinux.com> Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2779 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stesmi@stesmi.com Precedence: bulk X-list: linux-xfs Content-Length: 1365 Lines: 46 IKARASHI, Seiichi wrote: > Stefan Smietanowski wrote: > >>>> I noticed as much. And guess what - it worked! >>> >>> > > Good news! > >>> >>> maybe hack the installer to check the fs-type then perhaps and do thr >>> freeze only if it's xfs using the ioctl's rather than calling out to >>> an external program >> >> >> >> Checking the FS type - yes, it involves some hackery pokery but it is >> doable. Right now all it does is check if xfs_freeze is installed and >> calls it twice each for both / and /boot (one freeze and one unfreeze). > > > Checking the filesystem type can be done in > bootloaderInfo.py of booty as follows: > > import fsset > if fsset.isValidXFS(bootDev): > // execute xfs_freeze -f for bootDev > // execute xfs_freeze -u for bootDev Excellent. I take it "if fsset.isValidXFS(bootDev)" is code and not pseudo-code. I'll have to try that. I know the "execute xfs_freeze..." is pseudo-code. Hmmm. Wait, I just thought of something actually. Regardless of if I have that if there or not I only need to do xfs_freese -[fu] /boot actually since it just dawned on me what Chris W said. Doing xfs_freeze -f /boot will freeze the partition where /boot is located if /boot is a dir on /. I'll try that if you wrote there and get back to you tomorrow. Right now it's pretty late .. 0320. ouch... Yup, definately tomorrow. // Stefan From owner-linux-xfs@oss.sgi.com Fri Apr 9 02:21:51 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 09 Apr 2004 02:22:01 -0700 (PDT) Received: from smtp-out6.xs4all.nl (smtp-out6.xs4all.nl [194.109.24.7]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i399LnKO028962 for ; Fri, 9 Apr 2004 02:21:50 -0700 Received: from auto-nb1.xs4all.nl (host-2.coltex.demon.nl [212.238.252.66]) (authenticated bits=0) by smtp-out6.xs4all.nl (8.12.10/8.12.10) with ESMTP id i399LbYl072064; Fri, 9 Apr 2004 11:21:46 +0200 (CEST) Message-Id: <4.3.2.7.2.20040409111158.024eaea0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 09 Apr 2004 11:21:34 +0200 To: Colin Guthrie , knuffie@xs4all.nl From: Seth Mos Subject: Re: Advice! Raid Array mess up with raidreconf - you managed to fix so..... Cc: linux-xfs@oss.sgi.com In-Reply-To: <40765DF9.9050107@guthr.ie> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2780 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: seth.mos@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 2285 Lines: 61 At 09:25 9-4-2004 +0100, Colin Guthrie wrote: >Hi there, > >I saw your post on http://oss.sgi.com/archives/linux-xfs/2003-01/msg00300.html > >I have just done exactly the same thing. > >I have backups of the most important files that are on the raid array, but >I simply don't have the space for a full backup. >Anyway, I got very close to the end of my array before raidreconf borked >on me. This happened to you as well? >I was just wondering how to acheive the following bit: > >Because this happened with just one hash mark to go I ad some hope that >the filesystem would be mostly intact. The process already ran for about 2 >hours. I recreated the /dev/md0 array with the new raidtab and it started >resyncing. > > >How to I "recreate the /dev/md0 array witht he new raidtab?" > >I'm guessing it will be a mkraid /dev/md0 with some form of switch or two, >but when I type "mkraid --really-force --upgrade /dev/md0" I get a dire >warning about detroying all data. I used mkraid --force with the new raidtab. Because the array was nearly done reconfiguring the array is actually closer to the new configuration then the old one. That is why you should recreate it in this case with the new config. Using mkraid on an existing array is really dangerous if the configuration you are writing is not identical to the existing configuration. In this case alsmost all data is allready reconfigured. If you recreate the array with the new configuration it will start resyncing the on disk data according to the new configuration. Raidreconf also moves the parity bits around to the new configuration so it will basically force a rebuild of the array in the "correct" configuration and thus no data will be lost. *However* if there is data which was not yet moved around by raidreconf this data will be incorrectly rebuilt using the new raid configuration and as such will be lost. For my case it involved just a few files and I got lucky. >Is there anyway to run mkraid (and perhaps the --upgrade switch is wrong, >it's really for kernel upgrades) without it destroying the data currently >on the raid? --upgrade probably will not work. >Many thanks for your insight. Cheers -- Seth I don't make sense, I don't pretend to either. Questions? From owner-linux-xfs@oss.sgi.com Fri Apr 9 08:51:57 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 09 Apr 2004 08:52:06 -0700 (PDT) Received: from omx1.americas.sgi.com (cfcafw.sgi.com [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i39FpuKO011659 for ; Fri, 9 Apr 2004 08:51:56 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i39FpoVC005191 for ; Fri, 9 Apr 2004 10:51:50 -0500 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i39FpoKe36723457; Fri, 9 Apr 2004 10:51:50 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i39FpmEr4822767; Fri, 9 Apr 2004 10:51:49 -0500 (CDT) Date: Fri, 9 Apr 2004 10:51:48 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Stefan Smietanowski cc: "IKARASHI, Seiichi" , Chris Wedgwood , Steve Lord , Christoph Hellwig , Subject: Re: synchronization of XFS In-Reply-To: <4075FACC.3010105@stesmi.com> Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit X-archive-position: 2781 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1076 Lines: 34 On Fri, 9 Apr 2004, Stefan Smietanowski wrote: > > import fsset > > if fsset.isValidXFS(bootDev): > > // execute xfs_freeze -f for bootDev > > // execute xfs_freeze -u for bootDev > > Excellent. I take it "if fsset.isValidXFS(bootDev)" is code and not > pseudo-code. Correct - that reads the first few bytes and looks for the xfs magic number. > I'll have to try that. I know the "execute xfs_freeze..." > is pseudo-code. > > Hmmm. Wait, I just thought of something actually. > > Regardless of if I have that if there or not I only need to do > xfs_freese -[fu] /boot actually since it just dawned on me what Chris W > said. Doing xfs_freeze -f /boot will freeze the partition where /boot > is located if /boot is a dir on /. Yep, was going to suggest that. > I'll try that if you wrote there and get back to you tomorrow. > Right now it's pretty late .. 0320. ouch... Yup, definately tomorrow. Great, thanks for doing all the work on this. Perhaps when you get it tidied up you can add this info to the Red Hat bugzilla bug tracking this problem? -Eric From owner-linux-xfs@oss.sgi.com Fri Apr 9 13:59:48 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 09 Apr 2004 13:59:51 -0700 (PDT) Received: from K-7.stesmi.com (1-2-2-1a.has.sth.bostream.se [82.182.130.86]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i39KxkKO011429 for ; Fri, 9 Apr 2004 13:59:47 -0700 Received: from stesmi.com (deltaflyer.stesmi.com [192.168.1.14]) by K-7.stesmi.com (8.12.8/8.12.5) with ESMTP id i39KxWId022349; Fri, 9 Apr 2004 22:59:32 +0200 Message-ID: <40770EA5.9010609@stesmi.com> Date: Fri, 09 Apr 2004 22:59:17 +0200 From: Stefan Smietanowski User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Sandeen CC: "IKARASHI, Seiichi" , Chris Wedgwood , Steve Lord , Christoph Hellwig , linux-xfs@oss.sgi.com Subject: Re: synchronization of XFS References: In-Reply-To: Content-type: text/plain Content-Transfer-Encoding: 8bit X-archive-position: 2782 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stesmi@stesmi.com Precedence: bulk X-list: linux-xfs Content-Length: 2165 Lines: 56 Hi Eric. > Correct - that reads the first few bytes and looks for > the xfs magic number. I knew there was a sort-of simple way but I thought that that function was out of booty's context (or something) so that I couldn't call it directly. I'm glad I was wrong. >>I'll try that if you wrote there and get back to you tomorrow. >>Right now it's pretty late .. 0320. ouch... Yup, definately tomorrow. > > Great, thanks for doing all the work on this. Perhaps when you > get it tidied up you can add this info to the Red Hat bugzilla > bug tracking this problem? How does this patch look? I only tried it when the root was either XFS or EXT3 with no /boot partition but I don't see why it wouldn't work in other cases. If you think it's ok then I'll post it to that bugzilla entry. Know the number of it (or have a link) ? // Stefan -- Attached file included as plaintext by Ecartis -- -- File: booty-xfs-workaround.patch diff -urN booty-0.34-orig/bootloaderInfo.py booty-0.34/bootloaderInfo.py --- booty-0.34-orig/bootloaderInfo.py 2004-03-16 19:16:51.000000000 +0100 +++ booty-0.34/bootloaderInfo.py 2004-04-09 03:47:13.000000000 +0200 @@ -818,6 +818,20 @@ isys.sync() isys.sync() + # GRUB does a Bad Thing(TM) trying to read from the block + # device directly so we sort of have to force data to disk + # Note: It IS GRUB's fault, not XFS's fault. + import fsset + if fsset.isValidXFS(bootDev): + rhpl.executil.execWithRedirect( "/usr/sbin/xfs_freeze", + ["/usr/sbin/xfs_freeze", "-f", "/boot"], + stdout = "/dev/tty5", stderr = "/dev/tty5", + root = instRoot) + rhpl.executil.execWithRedirect( "/usr/sbin/xfs_freeze", + ["/usr/sbin/xfs_freeze", "-u", "/boot"], + stdout = "/dev/tty5", stderr = "/dev/tty5", + root = instRoot) + # really install the bootloader p = os.pipe() os.write(p[1], cmd + '\n') From owner-linux-xfs@oss.sgi.com Fri Apr 9 14:56:54 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 09 Apr 2004 14:56:56 -0700 (PDT) Received: from omx2.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i39LupKO014958 for ; Fri, 9 Apr 2004 14:56:51 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i3A02BqD029246 for ; Fri, 9 Apr 2004 17:02:11 -0700 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i39LujKe36726366; Fri, 9 Apr 2004 16:56:45 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i39LuiEr4701347; Fri, 9 Apr 2004 16:56:44 -0500 (CDT) Date: Fri, 9 Apr 2004 16:56:44 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Stefan Smietanowski cc: "IKARASHI, Seiichi" , Chris Wedgwood , Steve Lord , Christoph Hellwig , Subject: Re: synchronization of XFS In-Reply-To: <40770EA5.9010609@stesmi.com> Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit X-archive-position: 2783 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 461 Lines: 20 On Fri, 9 Apr 2004, Stefan Smietanowski wrote: > How does this patch look? I'd leave the "it's grub's fault" bit out ;-) no need to start a flamewar. Maybe just something like # Freeze the xfs filesystem to force every last bit of data # to disk before we go try to read the block device underneath # the filesystem > Know the number of it (or have a link) ? https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=117968 looks good to me. Thanks, -Eric From owner-linux-xfs@oss.sgi.com Fri Apr 9 15:02:39 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 09 Apr 2004 15:02:41 -0700 (PDT) Received: from K-7.stesmi.com (1-2-2-1a.has.sth.bostream.se [82.182.130.86]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i39M2cKO015675 for ; Fri, 9 Apr 2004 15:02:38 -0700 Received: from stesmi.com (deltaflyer.stesmi.com [192.168.1.14]) by K-7.stesmi.com (8.12.8/8.12.5) with ESMTP id i39M2VId024875; Sat, 10 Apr 2004 00:02:31 +0200 Message-ID: <40771D67.8030308@stesmi.com> Date: Sat, 10 Apr 2004 00:02:15 +0200 From: Stefan Smietanowski User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Sandeen CC: "IKARASHI, Seiichi" , Chris Wedgwood , Steve Lord , Christoph Hellwig , linux-xfs@oss.sgi.com Subject: Re: synchronization of XFS References: In-Reply-To: Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2784 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stesmi@stesmi.com Precedence: bulk X-list: linux-xfs Content-Length: 1245 Lines: 34 Hi Eric >>How does this patch look? > > I'd leave the "it's grub's fault" bit out ;-) no need to start > a flamewar. Maybe just something like > > # Freeze the xfs filesystem to force every last bit of data > # to disk before we go try to read the block device underneath > # the filesystem But that's basically mirroring the comment above and it _IS_ XFS specific after all. Besides, I already posted the patch to that exact same bugzilla entry that you just posted (I think that was the one at least :)). I found the bugzilla entry using their search. The reason I put the comment that way was that I'm hearing more and more people saying XFS sucks because of this single issue. I correct people when I can but there are a number of people that don't even test XFS for that reason and when they then see "another workaround for another one of those stupid XFS bugs" in FC2 they'll never touch it. It's their loss of course but I try to rectify that whenever I can. >>Know the number of it (or have a link) ? > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=117968 looks good > to me. Yeah, that is the exact entry I posted on. Hopefully they'll at least take the code from the patch and insert it into FC2 test 3. // Stefan From owner-linux-xfs@oss.sgi.com Sun Apr 11 09:20:16 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 11 Apr 2004 09:20:19 -0700 (PDT) Received: from smtp3.adl2.internode.on.net (smtp3.adl2.internode.on.net [203.16.214.203]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3BGKFKO011768 for ; Sun, 11 Apr 2004 09:20:16 -0700 Received: from overclockers.com.au (ppp40-211.lns1.adl1.internode.on.net [150.101.40.211]) by smtp3.adl2.internode.on.net (8.12.9/8.12.9) with SMTP id i3BGK8vM068491 for ; Mon, 12 Apr 2004 01:50:14 +0930 (CST) Received: by overclockers.com.au (sSMTP sendmail emulation); Mon, 12 Apr 2004 01:52:04 +0930 Date: Mon, 12 Apr 2004 01:52:04 +0930 From: "Mark Williams (MWP)" To: linux-xfs@oss.sgi.com Subject: Linux XFS Errors Message-ID: <20040411162203.GA21229@linux.comp> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Content-Transfer-Encoding: 8bit X-archive-position: 2785 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mwp@internode.on.net Precedence: bulk X-list: linux-xfs Content-Length: 3052 Lines: 64 Hi all, First, could you please CC any replies to me as im not on the list. Ive been running XFS for a little while now on a couple of drives. This is the first problem ive had. Im running kernel 2.6.5. Obviously i cant run fsck to fix the problem, so what can i do? Thanks. [root@linux1 WD1200JB-2]# rm -Rf .squid rm: cannot remove `.squid/00/0E/00000E00': Unknown error 990 rm: cannot remove `.squid/00/0E/00000E01': Unknown error 990 rm: cannot remove `.squid/00/0E/00000E02': Unknown error 990 rm: cannot remove `.squid/00/0E/00000E03': Unknown error 990 rm: cannot remove `.squid/00/0E/00000E04': Unknown error 990 rm: cannot remove `.squid/00/0E/00000E05': Unknown error 990 rm: cannot remove `.squid/00/0E/00000E06': Unknown error 990 rm: cannot remove `.squid/00/0E/00000E07': Unknown error 990 rm: cannot remove `.squid/00/0E/00000E08': Unknown error 990 rm: cannot remove `.squid/00/0E/00000E09': Unknown error 990 rm: cannot remove `.squid/00/0E/00000E0A': Unknown error 990 rm: cannot remove `.squid/00/0E/00000E0B': Unknown error 990 rm: cannot remove `.squid/00/0E/00000E0C': Unknown error 990 rm: cannot remove directory `.squid/00/0E': Directory not empty rm: cannot remove directory `.squid/00': Directory not empty rm: cannot remove `.squid/0A/59': Unknown error 990 rm: cannot remove `.squid/0A/75': Unknown error 990 rm: cannot remove `.squid/0A/8C': Unknown error 990 rm: cannot remove `.squid/0A/91': Unknown error 990 rm: cannot remove `.squid/0A/A8': Unknown error 990 rm: cannot remove `.squid/0A/AD': Unknown error 990 rm: cannot remove `.squid/0A/C4': Unknown error 990 rm: cannot remove `.squid/0A/C9': Unknown error 990 rm: cannot remove `.squid/0A/E0': Unknown error 990 rm: cannot remove `.squid/0A/E5': Unknown error 990 rm: cannot remove `.squid/0A/FC': Unknown error 990 rm: cannot remove directory `.squid/0A': Directory not empty rm: cannot remove `.squid/0B/00': Unknown error 990 rm: cannot remove `.squid/0B/17': Unknown error 990 rm: cannot remove `.squid/0B/1C': Unknown error 990 rm: cannot remove `.squid/0B/33': Unknown error 990 rm: cannot remove `.squid/0B/38': Unknown error 990 rm: cannot remove `.squid/0B/4F': Unknown error 990 rm: cannot remove `.squid/0B/54': Unknown error 990 rm: cannot remove `.squid/0B/6B': Unknown error 990 rm: cannot remove `.squid/0B/70': Unknown error 990 rm: cannot remove `.squid/0B/87': Unknown error 990 rm: cannot remove `.squid/0B/8C': Unknown error 990 rm: cannot remove `.squid/0B/A3': Unknown error 990 rm: cannot remove `.squid/0B/A8': Unknown error 990 rm: cannot remove `.squid/0B/BF': Unknown error 990 rm: cannot remove `.squid/0B/C4': Unknown error 990 ............... more rm: cannot remove `.squid/0F/BF': Unknown error 990 rm: cannot remove `.squid/0F/D6': Unknown error 990 rm: cannot remove `.squid/0F/DB': Unknown error 990 rm: cannot remove `.squid/0F/F2': Unknown error 990 rm: cannot remove `.squid/0F/F7': Unknown error 990 rm: cannot remove directory `.squid/0F': Directory not empty rm: cannot remove directory `.squid': Directory not empty From owner-linux-xfs@oss.sgi.com Sun Apr 11 10:20:24 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 11 Apr 2004 10:20:27 -0700 (PDT) Received: from internalmx.vasoftware.com (internalmx1.vasoftware.com [12.152.184.149]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3BHKNKO013283 for ; Sun, 11 Apr 2004 10:20:24 -0700 Received: from adsl-67-123-175-112.dsl.sntc01.pacbell.net ([67.123.175.112]:61326 helo=linux-sxs.org) by internalmx.vasoftware.com with asmtp (Cipher TLSv1:RC4-MD5:128) (Exim 4.22 #1 (Debian)) id 1BCid3-0002mH-PN by VAauthid with fixed_plain; Sun, 11 Apr 2004 10:20:21 -0700 Message-ID: <40797E51.3060402@linux-sxs.org> Date: Sun, 11 Apr 2004 10:20:17 -0700 From: "Net Llama!" Organization: HAL III User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040326 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Mark Williams (MWP)" CC: linux-xfs@oss.sgi.com Subject: Re: Linux XFS Errors References: <20040411162203.GA21229@linux.comp> In-Reply-To: <20040411162203.GA21229@linux.comp> Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-EA-Verified: internalmx.vasoftware.com 1BCid3-0002mH-PN 81b053e5141ca3bc5b8bb4f42a25dd47 X-archive-position: 2786 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@linux-sxs.org Precedence: bulk X-list: linux-xfs Content-Length: 808 Lines: 28 On 04/11/04 09:22, Mark Williams (MWP) wrote: > Hi all, > > First, could you please CC any replies to me as im not on the list. > > Ive been running XFS for a little while now on a couple of drives. > This is the first problem ive had. > Im running kernel 2.6.5. > > Obviously i cant run fsck to fix the problem, so what can i do? > > Thanks. > > [root@linux1 WD1200JB-2]# rm -Rf .squid > rm: cannot remove `.squid/00/0E/00000E00': Unknown error 990 > rm: cannot remove `.squid/00/0E/00000E01': Unknown error 990 xfs_repair -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ L. Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo: http://netllama.ipfox.com 10:15:01 up 126 days, 13:50, 1 user, load average: 0.01, 0.05, 0.06 From owner-linux-xfs@oss.sgi.com Sun Apr 11 17:47:33 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 11 Apr 2004 17:47:35 -0700 (PDT) Received: from jdc.local (ppp1FAC.dsl.pacific.net.au [203.100.245.172]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3C0lVKO030317 for ; Sun, 11 Apr 2004 17:47:32 -0700 Received: from jdc.local (localhost [127.0.0.1]) by jdc.local (8.12.11/8.12.11/Debian-4) with ESMTP id i3C0l9tO009498; Mon, 12 Apr 2004 10:47:09 +1000 Received: (from jason@localhost) by jdc.local (8.12.11/8.12.11/Debian-4) id i3C0l9cp009489; Mon, 12 Apr 2004 10:47:09 +1000 From: Jason White MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Message-ID: <16505.59149.38045.717130@jdc.local> Date: Mon, 12 Apr 2004 10:47:09 +1000 To: "Net Llama!" Cc: "Mark Williams (MWP)" , linux-xfs@oss.sgi.com Subject: Re: Linux XFS Errors In-Reply-To: <40797E51.3060402@linux-sxs.org> References: <20040411162203.GA21229@linux.comp> <40797E51.3060402@linux-sxs.org> X-Mailer: VM 7.18 under Emacs 21.3.1 Reply-To: jasonw@ariel.ucs.unimelb.edu.au X-archive-position: 2787 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jasonw@ariel.ucs.unimelb.edu.au Precedence: bulk X-list: linux-xfs Content-Length: 412 Lines: 12 Net Llama! writes: > On 04/11/04 09:22, Mark Williams (MWP) wrote: > > > > Obviously i cant run fsck to fix the problem, so what can i do? > > xfs_repair being sure to unmount the filesystem before running it. I would also suggest saving the output of xfs_repair in case the developers want to examine it. Another useful tool is xfs_check which just scans the filesystem for errors and inconsistencies. From owner-linux-xfs@oss.sgi.com Sun Apr 11 20:00:28 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 11 Apr 2004 20:00:30 -0700 (PDT) Received: from dingdong.cryptoapps.com (uslink-66.173.43-129.uslink.net [66.173.43.129] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3C30RKO001285 for ; Sun, 11 Apr 2004 20:00:28 -0700 Received: by dingdong.cryptoapps.com (Postfix, from userid 1001) id DF29AFB834; Sun, 11 Apr 2004 22:00:24 -0500 (CDT) Date: Sun, 11 Apr 2004 20:00:24 -0700 From: Chris Wedgwood To: Jason White Cc: Net Llama! , "Mark Williams (MWP)" , linux-xfs@oss.sgi.com Subject: Re: Linux XFS Errors Message-ID: <20040412030024.GA29697@dingdong.cryptoapps.com> References: <20040411162203.GA21229@linux.comp> <40797E51.3060402@linux-sxs.org> <16505.59149.38045.717130@jdc.local> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16505.59149.38045.717130@jdc.local> Content-Transfer-Encoding: 8bit X-archive-position: 2788 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 457 Lines: 14 On Mon, Apr 12, 2004 at 10:47:09AM +1000, Jason White wrote: > Another useful tool is xfs_check which just scans the filesystem for > errors and inconsistencies. be aware xfs_check misses things... sometimes it will give a clean bill of health when xfs_repair will later find problems to the original posted, the -990 error code is EDSCORRUPTED which is used internally by XFS but not exported beyond that (so perror and friends don't recognize it). From owner-linux-xfs@oss.sgi.com Sun Apr 11 21:00:44 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 11 Apr 2004 21:00:46 -0700 (PDT) Received: from smtp3.adl2.internode.on.net (smtp3.adl2.internode.on.net [203.16.214.203]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3C40hKO005750 for ; Sun, 11 Apr 2004 21:00:43 -0700 Received: from overclockers.com.au (ppp40-211.lns1.adl1.internode.on.net [150.101.40.211]) by smtp3.adl2.internode.on.net (8.12.9/8.12.9) with SMTP id i3C40cvM086205; Mon, 12 Apr 2004 13:30:39 +0930 (CST) Received: by overclockers.com.au (sSMTP sendmail emulation); Mon, 12 Apr 2004 13:32:40 +0930 Date: Mon, 12 Apr 2004 13:32:40 +0930 From: "Mark Williams (MWP)" To: Chris Wedgwood Cc: linux-xfs@oss.sgi.com Subject: Re: Linux XFS Errors Message-ID: <20040412040240.GA3525@linux.comp> References: <20040411162203.GA21229@linux.comp> <40797E51.3060402@linux-sxs.org> <16505.59149.38045.717130@jdc.local> <20040412030024.GA29697@dingdong.cryptoapps.com> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040412030024.GA29697@dingdong.cryptoapps.com> User-Agent: Mutt/1.4.2.1i Content-Transfer-Encoding: 8bit X-archive-position: 2789 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mwp@internode.on.net Precedence: bulk X-list: linux-xfs Content-Length: 545 Lines: 18 Thanks guys. xfs_repair appears to have fixed the problems. > On Mon, Apr 12, 2004 at 10:47:09AM +1000, Jason White wrote: > > > Another useful tool is xfs_check which just scans the filesystem for > > errors and inconsistencies. > > be aware xfs_check misses things... sometimes it will give a clean > bill of health when xfs_repair will later find problems > > to the original posted, the -990 error code is EDSCORRUPTED which is > used internally by XFS but not exported beyond that (so perror and > friends don't recognize it). > > From owner-linux-xfs@oss.sgi.com Mon Apr 12 06:21:04 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 12 Apr 2004 06:21:08 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.176]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3CDL2KO026453 for ; Mon, 12 Apr 2004 06:21:03 -0700 Received: from [212.227.126.208] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1BD1Mz-0006oA-00 for linux-xfs@oss.sgi.com; Mon, 12 Apr 2004 15:21:01 +0200 Received: from [217.88.246.88] (helo=aevum.de) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1BD1Mz-0000tU-00 for linux-xfs@oss.sgi.com; Mon, 12 Apr 2004 15:21:01 +0200 Message-ID: <407A97BC.3020200@aevum.de> Date: Mon, 12 Apr 2004 15:21:00 +0200 From: Nick Wellnhofer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Solved: Can't mount XFS root if HFS enabled Content-type: text/plain X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:c08e9f7b972d32210f9ff65436486d50 Content-Transfer-Encoding: 8bit X-archive-position: 2790 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: wellnhofer@aevum.de Precedence: bulk X-list: linux-xfs Content-Length: 1180 Lines: 47 This might be helpful to XFS users: With Linux 2.6.4 and later versions I couldn't boot from my XFS root partition. I eventually found out that the new HFS driver which I had enabled was the culprit. The kernel first tried to mount the root fs as HFS and due to a wrong return value it bailed out. If you have HFS enabled and want to boot from a XFS root partition you should pass "rootfstype=xfs" as boot parameter or apply the attached patch (against fs/hfs/super.c in 2.6.5). This also might explain the problem John Palkovic posted here: http://oss.sgi.com/archives/linux-xfs/2004-03/msg00185.html I have forwarded the fix to the HFS maintainer and hope to see it in a release kernel soon. Nick -- aevum gmbh leopoldstr. 87 80802 münchen germany fon: +4989 38380653 fax: +4989 38799384 wellnhofer@aevum.de http://aevum.de/ -- Attached file included as plaintext by Ecartis -- -- File: hfs.patch --- super.c.old 2004-04-10 22:01:39.000000000 +0200 +++ super.c 2004-04-10 22:00:57.000000000 +0200 @@ -276,6 +276,7 @@ if (!silent) hfs_warn("VFS: Can't find a HFS filesystem on dev %s.\n", hfs_mdb_name(sb)); + res = -EINVAL; goto bail2; } From owner-linux-xfs@oss.sgi.com Mon Apr 12 17:41:25 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 12 Apr 2004 17:41:29 -0700 (PDT) Received: from omx2.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3D0fPKO023479 for ; Mon, 12 Apr 2004 17:41:25 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with SMTP id i3D2lCiQ027947 for ; Mon, 12 Apr 2004 19:47:13 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA29614; Tue, 13 Apr 2004 10:41:14 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i3D0fC7X176591; Tue, 13 Apr 2004 10:41:13 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i3D0fB7I176473; Tue, 13 Apr 2004 10:41:11 +1000 (EST) Date: Tue, 13 Apr 2004 10:41:10 +1000 From: Nathan Scott To: Daniel Brahneborg Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: block -> name ? Message-ID: <20040413104110.A176038@wobbly.melbourne.sgi.com> References: <20040412084148.A11645@infoflexconnect.se> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20040412084148.A11645@infoflexconnect.se>; from daniel.brahneborg@infoflexconnect.se on Mon, Apr 12, 2004 at 08:41:48AM +0200 Content-Transfer-Encoding: 8bit X-archive-position: 2791 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 740 Lines: 23 On Mon, Apr 12, 2004 at 08:41:48AM +0200, Daniel Brahneborg wrote: > Hi, > > Recently my computer running Linux kernel 2.4.25 started > halting all of a sudden, and running badblocks a couple > of times showed that it was caused by reading around block > 20.200.000 on one of the SATA disks. I'll replace the > drive eventually, but is there a way of finding out what > file is currently residing in a specific block? I'd prefer > something a bit more efficient than doing a 'wc' on 300GB > of data (which also would miss all the directories). To > make things more interesting, the disk is 1 of 4 in a RAID5 > array, and is formatted with XFS. > > Best regards, See xfs_db(8) and its blockget/blockuse commands. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Apr 12 17:52:25 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 12 Apr 2004 17:52:30 -0700 (PDT) Received: from icq.com ([218.86.43.76]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3D0qEKP024018 for ; Mon, 12 Apr 2004 17:52:21 -0700 Received: from cienciaficcion.com (cienciaficcion-com-bk.mr.outblaze.com [205.158.62.137]) by icq.com (Postfix) with ESMTP id 89D660C7DB for ; Mon, 12 Apr 2004 20:49:31 -0400 Message-ID: <110001c420f1$dfffd32e$4335b1f6@cienciaficcion.com> From: "Hyphen S. Shearer" To: Linux Subject: =?windows-1251?B?UmVbOV06IMfIyywgysDMwMcsIMzAxywgytDAxywg09DAyywgw8DHLA==?= Date: Mon, 12 Apr 2004 20:49:31 -0400 MIME-Version: 1.0 Content-type: text/plain; charset=windows-1251 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.4682 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 X-AntiVirus: Checked by Dr.Web (http://www.drweb.net) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i3D0qPKO024025 X-archive-position: 2792 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: zap4asti@cienciaficcion.com Precedence: bulk X-list: linux-xfs Content-Length: 359 Lines: 14 ÐÏࡱá>18;59:9 h}h+d;h+d; K9lmTo: =?koi8-r?B?5MXNyc7V?= Subject: =?koi8-r?B?68/NzcXS3i7Q0sXEzM/WIG5ldw==?= Date: Tue, 6 Apr 2004 23:43:08 +0400 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 f From owner-linux-xfs@oss.sgi.com Mon Apr 12 23:41:52 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 12 Apr 2004 23:42:03 -0700 (PDT) Received: from cache1.synergon.hu (cache.synergon.hu [194.149.60.26]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3D6foKO003504 for ; Mon, 12 Apr 2004 23:41:51 -0700 Date: Mon, 12 Apr 2004 23:41:50 -0700 Message-Id: <200404130641.i3D6foKO003504@oss.sgi.com> Received: (qmail 1388 invoked from network); 13 Apr 2004 06:41:50 -0000 Received: from unknown (HELO sy2ba-smtp.synergon.hu) (194.149.60.55) by cache.synergon.hu with SMTP; 13 Apr 2004 06:41:50 -0000 From: _Svc_NortonAV@synergon.hu To: linux-xfs@oss.sgi.com Subject: (SMTP) Virus found in a message you sent X-archive-position: 2793 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: _Svc_NortonAV@synergon.hu Precedence: bulk X-list: linux-xfs Content-Length: 597 Lines: 20 (SMTP) A virus was found in a message sent by this account. --- Scan information follows --- Result: Virus Detected Virus Name: W32.Netsky.P@mm File Attachment: message.scr Attachment Status: deleted --- Original message information follows --- From: linux-xfs@oss.sgi.com To: bajan.peter@synergon.hu Date: Tue, 13 Apr 2004 14:41:26 +0800 Subject: Mail Delivery (failure bajan.peter@synergon.hu) Received: from cache1.synergon.hu ([194.149.60.26]) by sy2ba-smtp.synergon.hu (SAVSMTP 3.1.0.29) with SMTP id M2004041308411905831 for ; Tue, 13 Apr 2004 08:41:19 +0200 From owner-linux-xfs@oss.sgi.com Tue Apr 13 10:49:21 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 13 Apr 2004 10:49:28 -0700 (PDT) Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3DHnIKO005136 for ; Tue, 13 Apr 2004 10:49:20 -0700 Received: (qmail 21259 invoked by uid 65534); 13 Apr 2004 17:49:12 -0000 Received: from 217-162-109-96.dclient.hispeed.ch (EHLO vaio.gigerstyle.ch) (217.162.109.96) by mail.gmx.net (mp021) with SMTP; 13 Apr 2004 19:49:12 +0200 X-Authenticated: #1226656 Date: Tue, 13 Apr 2004 19:49:07 +0200 From: Marc Giger To: Ivan Kokshaysky , linux-xfs@oss.sgi.com Cc: =?ISO-8859-1?Q?M=E5ns_Rullg=E5rd?= , linux-kernel@vger.kernel.org Subject: Re: status of Linux on Alpha? Message-Id: <20040413194907.7ce8ceb7@vaio.gigerstyle.ch> In-Reply-To: <20040409230651.A727@den.park.msu.ru> References: <20040328201719.A14868@jurassic.park.msu.ru> <20040328204308.C14868@jurassic.park.msu.ru> <20040328221806.7fa20502@vaio.gigerstyle.ch> <20040329205233.5b7905aa@vaio.gigerstyle.ch> <20040404121032.7bb42b35@vaio.gigerstyle.ch> <20040409134534.67805dfd@vaio.gigerstyle.ch> <20040409134828.0e2984e5@vaio.gigerstyle.ch> <20040409230651.A727@den.park.msu.ru> X-Mailer: Sylpheed version 0.9.9claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit X-archive-position: 2795 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gigerstyle@gmx.ch Precedence: bulk X-list: linux-xfs Content-Length: 1455 Lines: 46 Hi Ivan, All First, sorry for the cross posting... After long sessions of patching, recompiling, and testing I finally found the cause of my problems. XFS people, please read: http://marc.theaimsgroup.com/?l=linux-kernel&m=108047692409817&w=2 and http://marc.theaimsgroup.com/?l=linux-kernel&m=107910319729364&w=2 After reverting 1.1608.29.12 all is fine again. Interestingly, this patch was listed on bkbits between 2.6.3 and 2.6.4-rc1 but was added to the source tree between 2.6.4-rc1 and 2.6.4-rc2 :-( Again something learned for the future... Ivan, I think your new semaphore code is still ok because it doesn't matter if it is the new or old code. Both versions have a problem with the xfs-patch. For further questions you know how to reach me:-) greets Marc On Fri, 9 Apr 2004 23:06:51 +0400 Ivan Kokshaysky wrote: > On Fri, Apr 09, 2004 at 01:48:28PM +0200, Marc Giger wrote: > > > Presently, I reached a stage on which I don't know longer what to > > > do:-( I isolated the problem between 2.6.3-rc1 and 2.6.3-rc2. I > > ^^^^^^^^^^^^^^^^^^^^^^^ > > read as 2.6.4-rc1 and 2.6.4-rc2 > > Thanks for your work. > > > > also reverted 1.1608.56.1 , 1.1608.51.36 and all xfs related > > > patches from rc2 with no luck. > > > All other changes seems unrelated to me. > > I'd also revert 1.1608.51.22 and all networking changes. > > Ivan. > From owner-linux-xfs@oss.sgi.com Tue Apr 13 10:59:03 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 13 Apr 2004 10:59:07 -0700 (PDT) Received: from localhost.localdomain ([63.81.117.28]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3DHx1KO005663 for ; Tue, 13 Apr 2004 10:59:02 -0700 Received: from xfs.org (jen [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id i3DHrj1g032302; Tue, 13 Apr 2004 12:53:46 -0500 Message-ID: <407C2929.20401@xfs.org> Date: Tue, 13 Apr 2004 12:53:45 -0500 From: Steve Lord User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gustavo Franco CC: linux-kernel@vger.kernel.org, XFS Linux , Christoph Hellwig Subject: Re: 2.6.5 - kernel BUG at fs/xfs/support/debug.c:106! References: <407B4479.7090702@acm.org> In-Reply-To: <407B4479.7090702@acm.org> Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2796 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 1416 Lines: 40 Gustavo Franco wrote: xfs_iget_core: ambiguous vns: vp/0xed46edc0, invp/0xc79b9b00 ------------[ cut here ]------------ kernel BUG at fs/xfs/support/debug.c:106! invalid operand: 0000 [#1] SMP CPU: 0 EIP: 0060:[] Not tainted EFLAGS: 00010246 (2.6.5) EIP is at cmn_err+0x9e/0xb0 eax: 00000040 ebx: 00000000 ecx: 00000002 edx: c03b55bc esi: c0384e2f edi: c0480f1e ebp: 00000293 esp: dd081d48 ds: 007b es: 007b ss: 0068 Process rsync (pid: 951, threadinfo=dd080000 task=f167b920) Stack: c036f000 c0375165 c0480ee0 c037ecc0 004d8ea0 00000000 d2c1d680 c021d07e 00000000 c037ecc0 ed46edc0 c79b9b00 c016deca f6569c00 c1ad2e00 f64b08a4 f63da128 dd080000 f6569c00 c1ad2e00 f64b08a0 00000000 00000000 d2c1d680 Call Trace: [] xfs_iget_core+0x4ae/0x5d0 [] get_new_inode_fast+0x4a/0xf0 [] xfs_iget+0x162/0x1a0 [] xfs_dir_lookup_int+0xac/0x130 [] xfs_lookup+0x50/0x90 [] linvfs_lookup+0x5f/0xa0 [] real_lookup+0xd5/0x100 [] do_lookup+0x96/0xb0 [] link_path_walk+0x49c/0x900 [] __user_walk+0x49/0x60 [] vfs_lstat+0x1c/0x60 [] sys_lstat64+0x1b/0x40 [] syscall_call+0x7/0xb Code: 0f 0b 6a 00 85 51 37 c0 83 c4 0c 5b 5e 5f 5d c3 89 f6 83 ec This has been seen before on nfs servers, Christoph was looking into it. Steve From owner-linux-xfs@oss.sgi.com Tue Apr 13 10:59:16 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 13 Apr 2004 10:59:23 -0700 (PDT) Received: from goku.engr.colostate.edu (goku.engr.colostate.edu [129.82.224.16]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3DHxFKO005732 for ; Tue, 13 Apr 2004 10:59:15 -0700 Received: from engr.colostate.edu (vegeta.engr.colostate.edu [129.82.224.6]) by goku.engr.colostate.edu (8.12.8/8.12.0.Beta7) with ESMTP id i3DHwhpk015668 for ; Tue, 13 Apr 2004 11:58:43 -0600 (MDT) Date: Tue, 13 Apr 2004 11:58:37 -0600 Mime-Version: 1.0 (Apple Message framework v553) Content-type: text/plain; charset=US-ASCII Subject: Linux XFS file system size From: CJ Keist To: linux-xfs@oss.sgi.com Content-Transfer-Encoding: 8bit Message-Id: <30A79E68-8D74-11D8-A97B-000393B500B6@engr.colostate.edu> X-Mailer: Apple Mail (2.553) X-ECS-MailScanner: Found to be clean X-archive-position: 2797 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cjay@engr.colostate.edu Precedence: bulk X-list: linux-xfs Content-Length: 516 Lines: 16 I didn't find this in the FAQ area, but what is the maximum file system size that XFS can do on RedHat Linux? Thanks... ------------------------------------------------------------------------ --------------------------- C. J. Keist Email: cj.keist@engr.colostate.edu UNIX/Network Manager Phone: 970-491-0630 Engineering Network Services Fax: 970-491-5569 College of Engineering, CSU Ft. Collins, CO 80523-1301 All I want is a chance to prove 'Money can't buy happiness'" From owner-linux-xfs@oss.sgi.com Tue Apr 13 11:40:10 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 13 Apr 2004 11:40:15 -0700 (PDT) Received: from tamu-relay.tamu.edu (smtp-relay.tamu.edu [165.91.143.199]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3DIe9KO008875 for ; Tue, 13 Apr 2004 11:40:09 -0700 Received: from hellas.tamu.edu (hellas.TAMU.EDU [165.91.251.188]) by tamu-relay.tamu.edu (8.12.10/8.12.10) with ESMTP id i3DIdZQ6064842; Tue, 13 Apr 2004 13:39:36 -0500 (CDT) Received: from hellas.tamu.edu (localhost [127.0.0.1]) by hellas.tamu.edu (SGI-8.12.5/8.12.5) with ESMTP id i3DIWchM208353; Tue, 13 Apr 2004 13:32:38 -0500 (CDT) Received: from localhost (miket@localhost) by hellas.tamu.edu (SGI-8.12.5/8.12.5/Submit) with ESMTP id i3DIWbi6208328; Tue, 13 Apr 2004 13:32:37 -0500 (CDT) Date: Tue, 13 Apr 2004 13:32:36 -0500 From: "Michael E. Thomadakis" To: linux-xfs@oss.sgi.com, andeen@sgi.com, lord@xfs.org, linux-kernel@kernel.vger.org.sgi.com Subject: IA64 Linux VM performance woes. Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit X-archive-position: 2798 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: miket@hellas.tamu.edu Precedence: bulk X-list: linux-xfs Content-Length: 5023 Lines: 122 Hello all. We are trying to deploy a 128 PE SGI Altix 3700 running Linux, with 265GB main memory and 10TB RAID disk (TP9500) : # cat /etc/redhat-release Red Hat Linux Advanced Server release 2.1AS (Derry) # cat /etc/sgi-release SGI ProPack 2.4 for Linux, Build 240rp04032500_10054-0403250031 # uname -a Linux c 2.4.21-sgi240rp04032500_10054 #1 SMP Thu Mar 25 00:45:27 PST 2004 ia64 unknown We have been experiencing bad performance and downright bad behavior when we are trying to read or write large files (10-100GB). File Throughput Issues ---------------------- At first the throughtput we are getting without file cache bypass is at around 440MB/sec MAX. This specific file system has LUNs whose primary FC paths go over all four 2Gb/sec FC channels and the max throughput should have been close to 800MB/sec. I've also noticed that the FC adapter driver threads are running at 100% CPU utilization, when they are pumping data to the RAID for long time. Is there any data copy taking place at the drivers? The HBAs are from QLogic. VM Untoward Behavior ------------------- A more disturbing issue is that the system does NOT clean up the file cache and eventually all memory gets occupied by FS pages. Then the system simply hungs. We tried enabling / removing bootCPUsets, bcfree and anything else available to us. The crashes are just keep comming. Recently we started experiencing a lot of 'Cannot do kernel page out at address' by the bdflush and kupdated threads as well. This complicates any attempt to tune the FS in a way that can maximize the throughput and finally setup sub-volumes on the RAID in a way that different FS performance objectives can be attained. Tunning bdlsuh/kupdated Behavior ------------------------------- One of our main objectives at our center is to maximize file thoughput for our systems. We are a medium size Supercomputing Center were compute and I/O intensive numerical computation code runs in batch sub-systems. Several programs expect and generate often very large files, in the order of 10-70GBs. Minimizing file access time is importand in a batch environment since processors remain allocated and idle while data is shuttled back and forth from the file system. Another common problem is the competition between file cache and computation pages. We definitely do NOT want file cache pages being cached, while computation pages are reclaimed. As far as I know, the only place in Linux that the VM / file cache behavior can be tuned is with the 'bdflush/kupdated' settings. We need a good way to tuneup the 'bdflush' parameters. I have been trying very hard to find in-depth documentation on this. Unfortunately I have only gleaned some general and abstract advices on the bdflush parameters, mainly in the kernel source documentation tree (/usr/src/kernel/Documentation/). For instance, what is a 'buffer'? Is it a fixed size block (e.g., a VM page) or it can be of any size? This is important as bdlush uses number and percentages of dirty buffers. A small number of large buffers require much more data to get transferred to the disks, vs. a large number of small buffers. Controls that are Needed ------------------------ Ideally we need to: 1. Set an upper bound on the number of memory pages ever caching FS blocks. 2. Control the amount of data flushed out to disk in set time periods; that is we need to be able to match the long term flushing rate with the service rate that the I/O subsystem is capable of delivering, tolerating possible transient spikes. We also need to be able to control the amount of read-ahead, write behind or even hint that data are only being streamed through, never to be reused again. 3. Specify different parameters for 2., above, per file system: we have file systems that are meant to transfer wide stripes of sequential data, vs. file systems that need to perform well with smaller block, random I/O, vs. ones that need to provide access to numerous smaller files. Also, cache percentages per file system would be useful. 4. Specify, if else fails, what parts of the FS cache should flushed in the near future. 5. Provide in-depth technical documentation on the internal workings of the file system cache, its interaction with the VM and the interaction of XFS/LVM with the VM. 6. We do operate IRIX Origins and IBM Regatta SMPs where all these issues have been addressed to a far more satisfying degree than on Linux. Is the IRIX file system cache going to be ported to ALTIX Linux? There is already a LOT of experience in IRIX for these types of matters that should NOT remain unleveraged. Any information/hint or pointers for in-depth discussion on the bugs and tunning of VM/FS and I/O subsystems or other relevant topics would be GREATLY appreciated! We are willing to share our experience with anyone who is interested in improving any of the above kernel sub-systems and provide feedback with experimental results and insights. Thanks Michael Thomadakis Supercomputing Center Texas A&M University From owner-linux-xfs@oss.sgi.com Tue Apr 13 11:44:55 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 13 Apr 2004 11:44:57 -0700 (PDT) Received: from coredumps.de (coredumps.de [217.160.213.75]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3DIisKO009301 for ; Tue, 13 Apr 2004 11:44:55 -0700 Received: from port-212-202-52-125.reverse.qsc.de ([212.202.52.125] helo=ente.berdmann.de) by coredumps.de with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.30) id 1BDStx-0008VP-Sh for linux-xfs@oss.sgi.com; Tue, 13 Apr 2004 20:44:53 +0200 Received: from octane.berdmann.de ([192.168.1.14] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.36 #1) id 1BDStx-00069N-00 for linux-xfs@oss.sgi.com; Tue, 13 Apr 2004 20:44:53 +0200 Message-ID: <407C3524.5010407@berdmann.de> Date: Tue, 13 Apr 2004 20:44:52 +0200 From: Bernhard Erdmann User-Agent: Mozilla/5.0 (X11; U; IRIX64 IP30; en-US; rv:1.6) Gecko/20040228 X-Accept-Language: de, en, fr MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: Linux XFS file system size References: <30A79E68-8D74-11D8-A97B-000393B500B6@engr.colostate.edu> In-Reply-To: <30A79E68-8D74-11D8-A97B-000393B500B6@engr.colostate.edu> Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2799 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: be@berdmann.de Precedence: bulk X-list: linux-xfs Content-Length: 170 Lines: 5 > I didn't find this in the FAQ area, but what is the maximum file system > size that XFS can do on RedHat Linux? IMHO 4 TB due to limitations of Linux' block driver From owner-linux-xfs@oss.sgi.com Tue Apr 13 13:22:50 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 13 Apr 2004 13:23:02 -0700 (PDT) Received: from omx1.americas.sgi.com (cfcafw.sgi.com [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3DKMnKO015461 for ; Tue, 13 Apr 2004 13:22:50 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i3DKMi1J024522 for ; Tue, 13 Apr 2004 15:22:44 -0500 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i3DKMhKe36998025; Tue, 13 Apr 2004 15:22:43 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i3DKMd7V265869; Tue, 13 Apr 2004 15:22:43 -0500 (CDT) Subject: Re: Linux XFS file system size From: Eric Sandeen To: Bernhard Erdmann Cc: linux-xfs@oss.sgi.com In-Reply-To: <407C3524.5010407@berdmann.de> References: <30A79E68-8D74-11D8-A97B-000393B500B6@engr.colostate.edu> <407C3524.5010407@berdmann.de> Content-type: text/plain Organization: Eric Conspiracy Secret Labs Message-Id: <1081887758.12804.75.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 13 Apr 2004 15:22:39 -0500 Content-Transfer-Encoding: 8bit X-archive-position: 2800 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 515 Lines: 16 More like 1T for ia32, 2T if you're lucky. 2.6 kernels have CONFIG_LBD, which should get you past the 2T barrier but is still a relatively new feature. -Eric On Tue, 2004-04-13 at 13:44, Bernhard Erdmann wrote: > > I didn't find this in the FAQ area, but what is the maximum file system > > size that XFS can do on RedHat Linux? > > IMHO 4 TB due to limitations of Linux' block driver -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Tue Apr 13 16:47:37 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 13 Apr 2004 16:47:43 -0700 (PDT) Received: from zok.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3DNlbKO026643 for ; Tue, 13 Apr 2004 16:47:37 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id i3DNk8hv015377 for ; Tue, 13 Apr 2004 16:46:08 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA24374; Wed, 14 Apr 2004 09:45:57 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i3DNjt7X204539; Wed, 14 Apr 2004 09:45:56 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i3DNjss3204074; Wed, 14 Apr 2004 09:45:54 +1000 (EST) Date: Wed, 14 Apr 2004 09:45:53 +1000 From: Nathan Scott To: CJ Keist Cc: linux-xfs@oss.sgi.com Subject: Re: Linux XFS file system size Message-ID: <20040414094553.B203776@wobbly.melbourne.sgi.com> References: <30A79E68-8D74-11D8-A97B-000393B500B6@engr.colostate.edu> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <30A79E68-8D74-11D8-A97B-000393B500B6@engr.colostate.edu>; from cjay@engr.colostate.edu on Tue, Apr 13, 2004 at 11:58:37AM -0600 Content-Transfer-Encoding: 8bit X-archive-position: 2801 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 665 Lines: 20 On Tue, Apr 13, 2004 at 11:58:37AM -0600, CJ Keist wrote: > I didn't find this in the FAQ area, but what is the maximum file system > size that XFS can do on RedHat Linux? > We've tested XFS on a petabyte, on Altix - thats a modified version of Redhat (most Redhat versions that have XFS are modified versions) and its a 64 bit machine - very important to get past the small TB numbers. The theoretical maximum for a 64 bit box is some number of exabytes (can't remember off the top of my head), or something ridiculous like that. But for 32 bit machines, I'd test extensively before going past the 1 or 2 TB range, as others have said. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Apr 13 23:41:49 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 13 Apr 2004 23:41:56 -0700 (PDT) Received: from omx1.americas.sgi.com (cfcafw.sgi.com [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3E6fmKO006439 for ; Tue, 13 Apr 2004 23:41:49 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i3E6ff1J016856 for ; Wed, 14 Apr 2004 01:41:43 -0500 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i3E6fSAL43956637; Wed, 14 Apr 2004 16:41:29 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i3E6fQHs37389568; Wed, 14 Apr 2004 16:41:26 +1000 (EST) Date: Wed, 14 Apr 2004 16:41:26 +1000 (EST) From: Nathan Scott Message-Id: <200404140641.i3E6fQHs37389568@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 901975 - laptop mode change X-archive-position: 2802 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 522 Lines: 18 Allow xfsbufd flush intervals to take immediate effect after changing the flush sysctl value. Fix from Bart Samwel. Date: Tue Apr 13 23:39:17 PDT 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/ultra-clean-xfs-linux Inspected by: hch@lst.de,bart@samwel.tk The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:170053a xfsidbg.c - 1.259 linux-2.6/xfs_buf.h - 1.96 linux-2.6/xfs_buf.c - 1.164 linux-2.4/xfs_buf.h - 1.101 linux-2.4/xfs_buf.c - 1.184 From owner-linux-xfs@oss.sgi.com Wed Apr 14 00:53:30 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 14 Apr 2004 00:53:32 -0700 (PDT) Received: from omx1.americas.sgi.com (cfcafw.sgi.com [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3E7rTKO011546 for ; Wed, 14 Apr 2004 00:53:30 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i3E7rN1J009570 for ; Wed, 14 Apr 2004 02:53:24 -0500 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i3E7rDAL44703432; Wed, 14 Apr 2004 17:53:13 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i3E7rASU44794350; Wed, 14 Apr 2004 17:53:10 +1000 (EST) Date: Wed, 14 Apr 2004 17:53:10 +1000 (EST) From: Nathan Scott Message-Id: <200404140753.i3E7rASU44794350@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 912975 - fix sysctls using HZ X-archive-position: 2803 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 387 Lines: 14 Use USER_HZ in XFS sysctl interfaces. Fix from Bart Samwel. Date: Wed Apr 14 00:39:38 PDT 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/ultra-clean-xfs-linux Inspected by: bart@samwel.tk The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:170056a linux-2.6/xfs_globals.c - 1.61 linux-2.6/xfs_linux.h - 1.120 From owner-linux-xfs@oss.sgi.com Wed Apr 14 00:59:05 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 14 Apr 2004 00:59:07 -0700 (PDT) Received: from omx1.americas.sgi.com (cfcafw.sgi.com [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3E7x4KO012056 for ; Wed, 14 Apr 2004 00:59:04 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i3E7ww1J011768 for ; Wed, 14 Apr 2004 02:58:58 -0500 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i3E7wrAL44675225; Wed, 14 Apr 2004 17:58:54 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i3E7wqc844658115; Wed, 14 Apr 2004 17:58:52 +1000 (EST) Date: Wed, 14 Apr 2004 17:58:52 +1000 (EST) From: Nathan Scott Message-Id: <200404140758.i3E7wqc844658115@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 912975 - bump sync/age sysctl max in 2.6 X-archive-position: 2804 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 386 Lines: 14 Bump up age_buffer and sync_interval maxima for laptop mode. From Bart Samwel. Date: Wed Apr 14 00:57:52 PDT 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/ultra-clean-xfs-linux Inspected by: hch@lst.de,bart@samwel.tk The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:170057a linux-2.6/xfs_globals.c - 1.62 From owner-linux-xfs@oss.sgi.com Wed Apr 14 04:34:26 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 14 Apr 2004 04:34:36 -0700 (PDT) Received: from dingdong.cryptoapps.com (uslink-66.173.43-129.uslink.net [66.173.43.129] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3EBYPKO008194 for ; Wed, 14 Apr 2004 04:34:26 -0700 Received: by dingdong.cryptoapps.com (Postfix, from userid 1001) id 47A09FB834; Wed, 14 Apr 2004 06:34:20 -0500 (CDT) Date: Wed, 14 Apr 2004 04:34:20 -0700 From: Chris Wedgwood To: "Michael E. Thomadakis" Cc: linux-xfs@oss.sgi.com, andeen@sgi.com, lord@xfs.org Subject: Re: IA64 Linux VM performance woes. Message-ID: <20040414113420.GA19964@dingdong.cryptoapps.com> References: Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Content-Transfer-Encoding: 8bit X-archive-position: 2805 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 4899 Lines: 113 On Tue, Apr 13, 2004 at 01:32:36PM -0500, Michael E. Thomadakis wrote: > I've also noticed that the FC adapter driver threads are running at > 100% CPU utilization, when they are pumping data to the RAID for > long time. Is there any data copy taking place at the drivers? The > HBAs are from QLogic. I would bitch to your SGI support channel about this. Off the top of your head do you have any idea where in the driver the cycles are being spent? > A more disturbing issue is that the system does NOT clean up the > file cache and eventually all memory gets occupied by FS pages. Then > the system simply hungs. Are you sure about this? How can you tell? I guess it's redundant to mention linux will cache all fs pages it can and release them as required but not before then. A umount will force them to be released however. Are you perhaps seeing bad slab behaviour (unbounded growth with weak pressure to shrink it) instead I wonder? Looking at /proc/slabinfo will give you some idea of how much slab is being use and by what. > One of our main objectives at our center is to maximize file > thoughput for our systems. We are a medium size Supercomputing > Center were compute and I/O intensive numerical computation code > runs in batch sub-systems. Several programs expect and generate > often very large files, in the order of 10-70GBs. Are these C or fortran programs? SGI has a fortran library that's supposed to do good stuff for file-IO using O_DIRECT and other smarts. I forget what it's called but the SGI support people should know. > Another common problem is the competition between file cache and > computation pages. We definitely do NOT want file cache pages being > cached, while computation pages are reclaimed. Known problem that's especially bad with 2.4.x --- it's even apparent when doing a backup on a live system as that will cause swapping. I'ts acutally a vm balancing problem and not specific to XFS. There are a couple of ways you can 'hack' around this I an think of right now. Either mlock you applications pages or use O_DIRECT IO in your applications. For the latter you want to be a little clever to do write-behind and read-ahead sort of stuff in another thread or just use really large IO-sizes and assume that's good enouugh. Also, do current propack 2.4.x kernels use rmap? > 1. Set an upper bound on the number of memory pages ever caching FS > blocks. Presently not possible. Discussed a few times with various vm people but nothing ever came of it as far as I know. > 2. Control the amount of data flushed out to disk in set time > periods; that is we need to be able to match the long term flushing > rate with the service rate that the I/O subsystem is capable of > delivering, tolerating possible transient spikes. We also need to be > able to control the amount of read-ahead, write behind or even hint > that data are only being streamed through, never to be reused again. I think with some care you should be able to tune that a little better. > 3. Specify different parameters for 2., above, per file system: we > have file systems that are meant to transfer wide stripes of > sequential data, vs. file systems that need to perform well with > smaller block, random I/O, vs. ones that need to provide access to > numerous smaller files. You can tune the fs parameters to some extent that may help here. You might also want to look at using a real-time subvolume if you have lots of streaming data (again, this implies O_DIRECT). > Also, cache percentages per file system would be useful. That's starting to sound pretty complex to manage and tune. > 4. Specify, if else fails, what parts of the FS cache should flushed > in the near future. Does madvise suffice? Actually, I'm not sure that it will, I'd have to check to see how much of it is actually implemented in a useful way but I recall noise about it not being very useful at one point. > 5. Provide in-depth technical documentation on the internal workings > of the file system cache, its interaction with the VM and the > interaction of XFS/LVM with the VM. This is starting to sound really complicated. The page-cache semantics are pretty clear but when it comes to interactions with slab and slab pressure it gets a little more muddy and I'm not sure. There is also an XFS-specific buffer layer for metadata. > 6. We do operate IRIX Origins and IBM Regatta SMPs where all these > issues have been addressed to a far more satisfying degree than on > Linux. Is the IRIX file system cache going to be ported to ALTIX > Linux? I sersiously doubt such a thing is possible in any reasonable time frame. Or desirable. I'm almost tempted to suggest you try mainline 2.6.x and see if that behaves any better. Normally I would expect Propack's XFS performance to be much better than 2.6.x but I wonder if you're not hitting 2.4.x VM suckage. --cw From owner-linux-xfs@oss.sgi.com Wed Apr 14 08:34:55 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 14 Apr 2004 08:35:00 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i3EFYtKO001914 for ; Wed, 14 Apr 2004 08:34:55 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i3EFYtjs001913 for linux-xfs@oss.sgi.com; Wed, 14 Apr 2004 08:34:55 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i3EFYqKQ001898 for ; Wed, 14 Apr 2004 08:34:53 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i3EFJcNK001592; Wed, 14 Apr 2004 08:19:38 -0700 Date: Wed, 14 Apr 2004 08:19:38 -0700 Message-Id: <200404141519.i3EFJcNK001592@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 323] New: Bug to collect xfs_repair/xfs_check output for corrupted fs's X-Bugzilla-Reason: AssignedTo X-archive-position: 2806 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 800 Lines: 28 http://oss.sgi.com/bugzilla/show_bug.cgi?id=323 Summary: Bug to collect xfs_repair/xfs_check output for corrupted fs's Product: Linux XFS Version: Current Platform: All OS/Version: Linux Status: NEW Severity: major Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: cattelan@thebarn.com Opening a bug as a repository for any fs corruptions. Please use attach output vs pasting in to the bug description. Add system into to the attached file. kernel version, type of fs (lvm,md,scsi,ide, etc) and size of fs. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Apr 14 10:57:47 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 14 Apr 2004 10:57:48 -0700 (PDT) Received: from omr1.netsolmail.com (omr1.netsolmail.com [216.168.230.162]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3EHvkKO005540 for ; Wed, 14 Apr 2004 10:57:46 -0700 Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr1.netsolmail.com (8.12.10/8.12.10) with ESMTP id i3EHq7Mc023488 for ; Wed, 14 Apr 2004 13:52:09 -0400 (EDT) Received: from ms8.netsolmail.com (localhost.netsolmail.com [127.0.0.1]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id AWL69108; Wed, 14 Apr 2004 13:57:41 -0400 (EDT) From: Message-Id: <200404141757.AWL69108@ms8.netsolmail.com> Received: from 65.104.102.243 by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with HTTP/1.1; Wed, 14 Apr 2004 13:57:41 -0400 Date: Wed, 14 Apr 2004 13:57:41 -0400 Subject: used obsolete MD ioctl... To: linux-xfs@oss.sgi.com X-Mailer: Webmail Mirapoint Direct 3.2.2-GA MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2807 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: brian@krusic.com Precedence: bulk X-list: linux-xfs Content-Length: 207 Lines: 14 Hi, I've rpm'd kernal v 2.4.20-20.9.XFS1.3.1 and all associated tools, I get; used obsolete MD ioctl, upgrade your software to use new ioctls when doing sw raid. Any hints on what I need to do? Bri- From owner-linux-xfs@oss.sgi.com Wed Apr 14 11:04:20 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 14 Apr 2004 11:04:23 -0700 (PDT) Received: from batleth.sapienti-sat.org (batleth.sapienti-sat.org [80.190.100.240]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3EI4JKO006033 for ; Wed, 14 Apr 2004 11:04:19 -0700 Received: from localhost (localhost [127.0.0.1]) by batleth.sapienti-sat.org (Postfix) with SMTP id C022B10277D for ; Wed, 14 Apr 2004 20:04:17 +0200 (CEST) Received: from koschikode.com (pD95D1B6B.dip.t-dialin.net [217.93.27.107]) by batleth.sapienti-sat.org (Postfix) with ESMTP id 6843C102779 for ; Wed, 14 Apr 2004 20:04:17 +0200 (CEST) Message-ID: <407D7D1D.1040301@koschikode.com> Date: Wed, 14 Apr 2004 20:04:13 +0200 From: Juri Haberland User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en, de-DE MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: used obsolete MD ioctl... References: <200404141757.AWL69108@ms8.netsolmail.com> In-Reply-To: <200404141757.AWL69108@ms8.netsolmail.com> Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2808 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: juri@koschikode.com Precedence: bulk X-list: linux-xfs Content-Length: 298 Lines: 18 brian@krusic.com wrote: > Hi, > > I've rpm'd kernal v 2.4.20-20.9.XFS1.3.1 and all associated > tools, I get; > > used obsolete MD ioctl, upgrade your software to use new > ioctls > > when doing sw raid. > > Any hints on what I need to do? Update your raidtools or use mdadm. Cheers, Juri From owner-linux-xfs@oss.sgi.com Wed Apr 14 12:03:37 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 14 Apr 2004 12:03:38 -0700 (PDT) Received: from omr1.netsolmail.com (omr1.netsolmail.com [216.168.230.162]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3EJ3aKO007539 for ; Wed, 14 Apr 2004 12:03:36 -0700 Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr1.netsolmail.com (8.12.10/8.12.10) with ESMTP id i3EIvxMa007544 for ; Wed, 14 Apr 2004 14:58:00 -0400 (EDT) Received: from ms8.netsolmail.com (localhost.netsolmail.com [127.0.0.1]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id AWL88766; Wed, 14 Apr 2004 15:03:35 -0400 (EDT) From: Message-Id: <200404141903.AWL88766@ms8.netsolmail.com> Received: from 65.104.102.243 by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with HTTP/1.1; Wed, 14 Apr 2004 15:03:35 -0400 Date: Wed, 14 Apr 2004 15:03:35 -0400 Subject: Re: used obsolete MD ioctl... To: linux-xfs@oss.sgi.com X-Mailer: Webmail Mirapoint Direct 3.2.2-GA MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2809 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: brian@krusic.com Precedence: bulk X-list: linux-xfs Content-Length: 391 Lines: 16 Hi, First, thanks for the rapid reply. Second, I am using the latest raidtools v 1.003-2. Instead of using raidtab, I used mdadm as you suggested and got the same results. I can mount the file system and use it however I'm not sure how production worthy it will be considering the error message. Could this error be bogus? Bri- Krusic Consulting Inc. Network Consulting Services. From owner-linux-xfs@oss.sgi.com Wed Apr 14 13:41:54 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 14 Apr 2004 13:41:58 -0700 (PDT) Received: from batleth.sapienti-sat.org (batleth.sapienti-sat.org [80.190.100.240]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3EKfhKO013199 for ; Wed, 14 Apr 2004 13:41:44 -0700 Received: from localhost (localhost [127.0.0.1]) by batleth.sapienti-sat.org (Postfix) with SMTP id 5630310277D for ; Wed, 14 Apr 2004 21:59:43 +0200 (CEST) Received: from koschikode.com (pD95D1B6B.dip.t-dialin.net [217.93.27.107]) by batleth.sapienti-sat.org (Postfix) with ESMTP id EBBEC102779 for ; Wed, 14 Apr 2004 21:59:42 +0200 (CEST) Message-ID: <407D982D.80002@koschikode.com> Date: Wed, 14 Apr 2004 21:59:41 +0200 From: Juri Haberland User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en, de-DE MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: used obsolete MD ioctl... References: <200404141903.AWL88766@ms8.netsolmail.com> In-Reply-To: <200404141903.AWL88766@ms8.netsolmail.com> Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2810 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: juri@koschikode.com Precedence: bulk X-list: linux-xfs Content-Length: 649 Lines: 22 brian@krusic.com wrote: > Hi, > > First, thanks for the rapid reply. Second, I am using the > latest raidtools v 1.003-2. Instead of using raidtab, I used > mdadm as you suggested and got the same results. > > I can mount the file system and use it however I'm not sure > how production worthy it will be considering the error > message. > > Could this error be bogus? As far as I understand it, it's just a notice, not an error, telling you that some software uses an old (and obselete) ioctl instead of a new one. What action actually triggers this message? I think the message also reports the process name and the PID. Cheers, Juri From owner-linux-xfs@oss.sgi.com Wed Apr 14 15:55:51 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 14 Apr 2004 15:55:55 -0700 (PDT) Received: from omx1.americas.sgi.com (cfcafw.sgi.com [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3EMtpKO024621 for ; Wed, 14 Apr 2004 15:55:51 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with SMTP id i3EMtg1J025312 for ; Wed, 14 Apr 2004 17:55:44 -0500 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA19388; Thu, 15 Apr 2004 08:55:12 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i3EMt67X232528; Thu, 15 Apr 2004 08:55:08 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i3EMsxbn232545; Thu, 15 Apr 2004 08:54:59 +1000 (EST) Date: Thu, 15 Apr 2004 08:54:58 +1000 From: Nathan Scott To: brian@krusic.com Cc: linux-xfs@oss.sgi.com Subject: Re: used obsolete MD ioctl... Message-ID: <20040415085458.A232631@wobbly.melbourne.sgi.com> References: <200404141903.AWL88766@ms8.netsolmail.com> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200404141903.AWL88766@ms8.netsolmail.com>; from brian@krusic.com on Wed, Apr 14, 2004 at 03:03:35PM -0400 Content-Transfer-Encoding: 8bit X-archive-position: 2811 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 544 Lines: 22 On Wed, Apr 14, 2004 at 03:03:35PM -0400, brian@krusic.com wrote: > Hi, > > First, thanks for the rapid reply. Second, I am using the > latest raidtools v 1.003-2. Instead of using raidtab, I used > mdadm as you suggested and got the same results. > > I can mount the file system and use it however I'm not sure > how production worthy it will be considering the error > message. > > Could this error be bogus? > Its a missing ioctl handler in the MD driver. Its fixed in later 2.4 revisions, and is harmless. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Apr 15 05:22:52 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 15 Apr 2004 05:22:56 -0700 (PDT) Received: from omx2.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3FCMgKO011340 for ; Thu, 15 Apr 2004 05:22:42 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i3FESWPC005639 for ; Thu, 15 Apr 2004 07:28:42 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i3EFKdKe37031759; Wed, 14 Apr 2004 10:20:39 -0500 (CDT) Received: from naboo.americas.sgi.com (naboo.americas.sgi.com [128.162.233.73]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i3EFKLXa4028696; Wed, 14 Apr 2004 10:20:39 -0500 (CDT) Subject: Re: Linux XFS Errors From: Russell Cattelan To: "Mark Williams (MWP)" Cc: Chris Wedgwood , linux-xfs@oss.sgi.com In-Reply-To: <20040412040240.GA3525@linux.comp> References: <20040411162203.GA21229@linux.comp> <40797E51.3060402@linux-sxs.org> <16505.59149.38045.717130@jdc.local> <20040412030024.GA29697@dingdong.cryptoapps.com> <20040412040240.GA3525@linux.comp> Content-type: text/plain Message-Id: <1081956020.12630.35.camel@naboo.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5-4mdk Date: Wed, 14 Apr 2004 10:20:21 -0500 Content-Transfer-Encoding: 8bit X-archive-position: 2812 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 1201 Lines: 43 Did you happen to save the repair output? We are trying to collect info on corrupted fs's, since we have been seen a few more reports than normal on 2.6 systems. Please attach to http://oss.sgi.com/bugzilla/show_bug.cgi?id=323 if you have it. On Sun, 2004-04-11 a 23:02, Mark Williams (MWP) wrote: > Thanks guys. > > xfs_repair appears to have fixed the problems. > > > On Mon, Apr 12, 2004 at 10:47:09AM +1000, Jason White wrote: > > > > > Another useful tool is xfs_check which just scans the filesystem for > > > errors and inconsistencies. > > > > be aware xfs_check misses things... sometimes it will give a clean > > bill of health when xfs_repair will later find problems > > > > to the original posted, the -990 error code is EDSCORRUPTED which is > > used internally by XFS but not exported beyond that (so perror and > > friends don't recognize it). > > > > > -- Attached file included as plaintext by Ecartis -- -- File: signature.asc -- Desc: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBAfVa0NRmM+OaGhBgRAp5NAJ0Vb63wz44HB6wZ4BJ7SA7MVOwDFwCfSNnw AQaDpeI6cWQJ8z7DPswCOCI= =hsyD -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Thu Apr 15 09:12:24 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 15 Apr 2004 09:12:28 -0700 (PDT) Received: from mailhub2.midco.net (mailhub2.midco.net [24.220.0.34]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3FGCNKO001526 for ; Thu, 15 Apr 2004 09:12:24 -0700 Received: (qmail 14144 invoked by uid 0); 15 Apr 2004 17:12:25 -0000 Received: from aaron.mmi.net ([24.220.8.250]) (envelope-sender ) by lvs-pop.midco.net (qmail-ldap-1.03) with SMTP for ; 15 Apr 2004 17:12:25 -0000 From: Aaron Thoreson To: linux-xfs@oss.sgi.com Subject: older release sets Date: Thu, 15 Apr 2004 10:12:22 -0600 User-Agent: KMail/1.6.1 MIME-Version: 1.0 Content-Disposition: inline Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Message-Id: <200404151112.22347.aaront@midco.net> X-archive-position: 2813 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: aaront@midco.net Precedence: bulk X-list: linux-xfs Content-Length: 260 Lines: 14 Are the non-development patch releases going to be available through http soon? Currently, the page only shows the development sets for 2.4.22 and later. I would like 2.4.19. Thank you! -- Aaron Thoreson Server Technician aaront@midco.net 605-357-5724 From owner-linux-xfs@oss.sgi.com Thu Apr 15 15:40:12 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 15 Apr 2004 15:40:14 -0700 (PDT) Received: from mail.ocs.com.au (pr-117-210.ains.net.au [202.147.117.210] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3FMe9KO017914 for ; Thu, 15 Apr 2004 15:40:11 -0700 Received: from ocs3.ocs.com.au (ocs3.ocs.com.au [192.168.255.3]) by mail.ocs.com.au (Postfix) with ESMTP id 79F3E1800A4; Fri, 16 Apr 2004 08:39:54 +1000 (EST) Received: by ocs3.ocs.com.au (Postfix, from userid 16331) id E6846C00AC; Fri, 16 Apr 2004 08:39:53 +1000 (EST) Received: from ocs3.ocs.com.au (localhost [127.0.0.1]) by ocs3.ocs.com.au (Postfix) with ESMTP id E419A140086; Fri, 16 Apr 2004 08:39:53 +1000 (EST) X-Mailer: exmh version 2.6.3_20040314 03/14/2004 with nmh-1.0.4 From: Keith Owens To: Aaron Thoreson Cc: linux-xfs@oss.sgi.com Subject: Re: older release sets In-reply-to: Your message of "Thu, 15 Apr 2004 10:12:22 CST." <200404151112.22347.aaront@midco.net> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Date: Fri, 16 Apr 2004 08:39:52 +1000 Message-ID: <7810.1082068792@ocs3.ocs.com.au> Content-Transfer-Encoding: 8bit X-archive-position: 2814 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 436 Lines: 12 On Thu, 15 Apr 2004 10:12:22 -0600, Aaron Thoreson wrote: >Are the non-development patch releases going to be available through http >soon? > >Currently, the page only shows the development sets for 2.4.22 and later. I >would like 2.4.19. The earlier releases had to be removed because SCO claimed that they contained code that belonged to SCO. They will not be returning. http://oss.sgi.com/letter_100103.txt From owner-linux-xfs@oss.sgi.com Fri Apr 16 01:12:06 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 16 Apr 2004 01:12:07 -0700 (PDT) Received: from alsvidh.mathematik.uni-muenchen.de (alsvidh.mathematik.uni-muenchen.de [129.187.111.42]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3G8BsKO014298 for ; Fri, 16 Apr 2004 01:11:55 -0700 Received: by alsvidh.mathematik.uni-muenchen.de (Postfix, from userid 666) id EA4933D551; Thu, 15 Apr 2004 13:35:45 +0200 (CEST) To: linux-xfs@oss.sgi.com Subject: slow file creation with xfs on software raid5 - solved & thanks Organization: Lehrstuhl fuer vergleichende Astrozoologie X-Mahlzeit: Das ist per Saldo Gemuetlichkeit References: Reply-To: Jens Schmalzing From: Jens Schmalzing Date: 15 Apr 2004 13:35:45 +0200 Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i3G8C6KO014301 X-archive-position: 2815 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: j.s@lmu.de Precedence: bulk X-list: linux-xfs Content-Length: 448 Lines: 17 Hi, Matt Stegman writes: > Make your RAID5 chunk size larger than 4kB. I'd suggest you start > with 32kB chunks; I chose 256kB for my RAID5 over four Serial ATA > disks. It just occurred to me that I never replied to this. Thanks a lot for the hint, it worked very well. After extensive tests, we also ended up with 256kB chunks. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je pézqbpbe je djuz tqtaj! From owner-linux-xfs@oss.sgi.com Fri Apr 16 08:57:49 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 16 Apr 2004 08:57:50 -0700 (PDT) Received: from omx2.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3GFvkKO000506 for ; Fri, 16 Apr 2004 08:57:48 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i3GI3lMB015171 for ; Fri, 16 Apr 2004 11:03:57 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i3GFvAKe37181939 for ; Fri, 16 Apr 2004 10:57:11 -0500 (CDT) Received: from naboo.americas.sgi.com (naboo.americas.sgi.com [128.162.233.73]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i3GFvAXa4189575; Fri, 16 Apr 2004 10:57:10 -0500 (CDT) Received: by naboo.americas.sgi.com (Postfix, from userid 29039) id DE1DD8815A9; Fri, 16 Apr 2004 10:57:09 -0500 (CDT) Subject: PARTIAL TAKE 913128 - libxfs fix for the dir2 rebalance bug Message-Id: <20040416155709.DE1DD8815A9@naboo.americas.sgi.com> Date: Fri, 16 Apr 2004 10:57:09 -0500 (CDT) From: cattelan@sgi.com (Russell Cattelan) To: undisclosed-recipients:;;;;@sgi.com;;; X-archive-position: 2817 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1298 Lines: 29 Date: Fri Apr 16 08:56:34 PDT 2004 Workarea: naboo.americas.sgi.com:/go/space/XFS/xfs-cmds Inspected by: overby@sgi.com,sandeen@sgi.com,nathans@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:170226a xfsprogs/libxfs/xfs_dir2_node.c - 1.17 - So this was a fun one to track down. This bug has existed since version 1.1 of the dir2 code. xfs_dir2_leafn_rebalance splits a directory tree block into 2 balanced blocks and then calculates the new index in either the old block or the new block relying on the hash value. This doesn't work in the case of a new to be inserted elements hash value being the same as an already existing elements hash value. This resulted in a negative index being returned and then passed to xfs_dir2_leafn_add, which it then used as a starting address in the elements array. The address (which is now pointing to somebody else's memory) was then passed to memmove to move the tail of the array down 8 bytes. Depending on the size of the array this would move all sorts of possibly important info belong to somebody else 8 bytes down. As part of the fix add a sanity check to xfs_dir2_leafn_add to make nobody else is passing in a negative index. From owner-linux-xfs@oss.sgi.com Fri Apr 16 08:55:52 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 16 Apr 2004 08:56:02 -0700 (PDT) Received: from omx2.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3GFtpKO000410 for ; Fri, 16 Apr 2004 08:55:52 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i3GI1qHK014652 for ; Fri, 16 Apr 2004 11:02:02 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i3GFtFKe37131460 for ; Fri, 16 Apr 2004 10:55:15 -0500 (CDT) Received: from naboo.americas.sgi.com (naboo.americas.sgi.com [128.162.233.73]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i3GFtEXa4109758; Fri, 16 Apr 2004 10:55:14 -0500 (CDT) Received: by naboo.americas.sgi.com (Postfix, from userid 29039) id 3056E8815A9; Fri, 16 Apr 2004 10:55:14 -0500 (CDT) Subject: PARTIAL TAKE 913128 - Fix for the xfs dir2 rebalance bug. Message-Id: <20040416155514.3056E8815A9@naboo.americas.sgi.com> Date: Fri, 16 Apr 2004 10:55:14 -0500 (CDT) From: cattelan@sgi.com (Russell Cattelan) To: undisclosed-recipients:;;;;@sgi.com;;; X-archive-position: 2816 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1294 Lines: 28 Date: Fri Apr 16 08:54:36 PDT 2004 Workarea: naboo.americas.sgi.com:/go/space/XFS/xfs-linux-new Inspected by: overby@sgi.com,sandeen@sgi.com,nathans@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:170221a xfs_dir2_node.c - 1.40 - So this was a fun one to track down. This bug has existed since version 1.1 of the dir2 code. xfs_dir2_leafn_rebalance splits a directory tree block into 2 balanced blocks and then calculates the new index in either the old block or the new block relying on the hash value. This doesn't work in the case of a new to be inserted elements hash value being the same as an already existing elements hash value. This resulted in a negative index being returned and then passed to xfs_dir2_leafn_add, which it then used as a starting address in the elements array. The address (which is now pointing to somebody else's memory) was then passed to memmove to move the tail of the array down 8 bytes. Depending on the size of the array this would move all sorts of possibly important info belong to somebody else 8 bytes down. As part of the fix add a sanity check to xfs_dir2_leafn_add to make nobody else is passing in a negative index. From owner-linux-xfs@oss.sgi.com Fri Apr 16 10:09:21 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 16 Apr 2004 10:09:23 -0700 (PDT) Received: from omx2.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3GH9KKO002910 for ; Fri, 16 Apr 2004 10:09:21 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i3GJFMhq008779 for ; Fri, 16 Apr 2004 12:15:32 -0700 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i3GH8jKe37193562 for ; Fri, 16 Apr 2004 12:08:45 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i3GH8i7V516551 for ; Fri, 16 Apr 2004 12:08:44 -0500 (CDT) Subject: Announce: xfs 1.3.3 beta 1 From: Eric Sandeen To: linux-xfs@oss.sgi.com Content-type: text/plain Organization: Eric Conspiracy Secret Labs Message-Id: <1082135324.25946.17.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 16 Apr 2004 12:08:44 -0500 Content-Transfer-Encoding: 8bit X-archive-position: 2818 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1667 Lines: 42 Watch out.... just when you least expect it, someone will go off and release a new version of XFS! This one is a little different... for a few reasons. Now that XFS is in both 2.4 and 2.6, the notion of a "point release" of XFS loses some meaning. On the other hand, people are often asking for XFS code that has had some soak time, i.e. a release branch. Inside SGI we obviously release products that use XFS on Linux, and the releases are qa'd and managed as you might expect. So, even though XFS is now in the kernel.org trees, we felt that we may as well put out the XFS codebase that is shipping with our products as a more formal release. This is the result of that plan. ftp://oss.sgi.com/projects/xfs/testing/release-1.3.3-pre1 The XFS code in the above dirs reflects the state of the tree from roughly January, with bugfixes merged in along the way. It is the same XFS codebase as is being finalized for commercial SGI linux products. We were a bit late in getting this to oss, so those SGI products are in their final phase of QA, so really only showstopper bugs can be addressed at this point. Still, we hope you find this release to be useful. Released are RH9- and RHEL- based kernels for x86 architectures, as well as a tarball that contains fs/xfs/* which should be able to overlay any kernel.org kernel >= 2.4.21 (although the RPMs have had the most testing). Also, userspace rpms & tarballs. Please see the README in the above dir for more information, and fire away with questions on the list. Thanks, -Eric -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Fri Apr 16 11:01:03 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 16 Apr 2004 11:01:05 -0700 (PDT) Received: from office.labsysgrp.com (wsip-68-14-253-125.ph.ph.cox.net [68.14.253.125]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3GI13KO004393 for ; Fri, 16 Apr 2004 11:01:03 -0700 Received: from [127.0.0.1] (helo=localhost) by office.labsysgrp.com with esmtp (Exim 4.24) id 1BEXe5-0000BZ-Ni for linux-xfs@oss.sgi.com; Fri, 16 Apr 2004 11:00:57 -0700 Received: from office.labsysgrp.com ([127.0.0.1]) by localhost (office.lsg.internal [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00474-06 for ; Fri, 16 Apr 2004 11:00:57 -0700 (MST) Received: from jeeves.kpf.internal ([192.168.170.1]) by office.labsysgrp.com with esmtp (Exim 4.24) id 1BEXe5-0000BT-2E for linux-xfs@oss.sgi.com; Fri, 16 Apr 2004 11:00:57 -0700 Received: from [192.168.172.107] (helo=backtobasicsmgmt.com) by jeeves.kpf.internal with esmtp (Exim 4.05) id 1BEXe4-0007s2-00 for linux-xfs@oss.sgi.com; Fri, 16 Apr 2004 11:00:56 -0700 Message-ID: <40801F5A.7050502@backtobasicsmgmt.com> Date: Fri, 16 Apr 2004 11:00:58 -0700 From: "Kevin P. Fleming" Organization: Back To Basics Network Management User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: Announce: xfs 1.3.3 beta 1 References: <1082135324.25946.17.camel@stout.americas.sgi.com> In-Reply-To: <1082135324.25946.17.camel@stout.americas.sgi.com> Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at labsysgrp.com X-archive-position: 2819 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kpfleming@backtobasicsmgmt.com Precedence: bulk X-list: linux-xfs Content-Length: 444 Lines: 10 Eric Sandeen wrote: > The XFS code in the above dirs reflects the state of the tree from > roughly January, with bugfixes merged in along the way. It is the same > XFS codebase as is being finalized for commercial SGI linux products. So this implies that the XFS codebase that's in the current 2.4/2.6 kernels is newer? Meaning that if we roll our own kernels we can assume we've got the latest XFS code pretty much all the time, right? From owner-linux-xfs@oss.sgi.com Fri Apr 16 12:02:13 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 16 Apr 2004 12:02:15 -0700 (PDT) Received: from zok.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3GJ2DKO010044 for ; Fri, 16 Apr 2004 12:02:13 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i3GJ27hv026614 for ; Fri, 16 Apr 2004 12:02:08 -0700 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i3GJ27Ke37176632; Fri, 16 Apr 2004 14:02:07 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i3GJ277V526214; Fri, 16 Apr 2004 14:02:07 -0500 (CDT) Subject: Re: Announce: xfs 1.3.3 beta 1 From: Eric Sandeen To: "Kevin P. Fleming" Cc: linux-xfs@oss.sgi.com In-Reply-To: <40801F5A.7050502@backtobasicsmgmt.com> References: <1082135324.25946.17.camel@stout.americas.sgi.com> <40801F5A.7050502@backtobasicsmgmt.com> Content-type: text/plain Organization: Eric Conspiracy Secret Labs Message-Id: <1082142126.25946.25.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 16 Apr 2004 14:02:06 -0500 Content-Transfer-Encoding: 8bit X-archive-position: 2820 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 870 Lines: 26 On Fri, 2004-04-16 at 13:00, Kevin P. Fleming wrote: > Eric Sandeen wrote: > > > The XFS code in the above dirs reflects the state of the tree from > > roughly January, with bugfixes merged in along the way. It is the same > > XFS codebase as is being finalized for commercial SGI linux products. > > So this implies that the XFS codebase that's in the current 2.4/2.6 > kernels is newer? Meaning that if we roll our own kernels we can assume > we've got the latest XFS code pretty much all the time, right? Yes. CVS is newest (well, within an hour) kernel.org is (usually) not too far behind Things like this release have been through a month(s)-long release process, and are older, but should be well-tested and stabilized. -Eric -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Fri Apr 16 12:04:34 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 16 Apr 2004 12:04:36 -0700 (PDT) Received: from zok.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3GJ4YKO010363 for ; Fri, 16 Apr 2004 12:04:34 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i3GJ4Shv009776 for ; Fri, 16 Apr 2004 12:04:29 -0700 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i3GJ4SKe37132818 for ; Fri, 16 Apr 2004 14:04:28 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i3GJ4S7V525656 for ; Fri, 16 Apr 2004 14:04:28 -0500 (CDT) Subject: Re: Announce: xfs 1.3.3 beta 1 From: Eric Sandeen To: linux-xfs@oss.sgi.com In-Reply-To: <1082135324.25946.17.camel@stout.americas.sgi.com> References: <1082135324.25946.17.camel@stout.americas.sgi.com> Content-type: text/plain Organization: Eric Conspiracy Secret Labs Message-Id: <1082142267.25946.29.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 16 Apr 2004 14:04:28 -0500 Content-Transfer-Encoding: 8bit X-archive-position: 2821 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 305 Lines: 10 Just to reiterate, in this release the xfs module itself is packaged in the xfs-modules rpm - you'll need both the kernel and the xfs-modules rpms to mount xfs filesystems. -Eric -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Fri Apr 16 15:27:46 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 16 Apr 2004 15:27:55 -0700 (PDT) Received: from mailgw1.fnal.gov (mailgw1.fnal.gov [131.225.111.11]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3GMRgKO023771 for ; Fri, 16 Apr 2004 15:27:46 -0700 Received: from conversion-daemon.mailgw1.fnal.gov by mailgw1.fnal.gov (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) id <0HWA00901AW6LM@mailgw1.fnal.gov> (original mail from greenc@fnal.gov) for linux-xfs@oss.sgi.com; Fri, 16 Apr 2004 17:21:53 -0500 (CDT) Received: from maxwell.fnal.gov (maxwell.fnal.gov [131.225.54.225]) by mailgw1.fnal.gov (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPS id <0HWA008FBBGGLP@mailgw1.fnal.gov> for linux-xfs@oss.sgi.com; Fri, 16 Apr 2004 17:21:52 -0500 (CDT) Date: Fri, 16 Apr 2004 17:21:52 -0500 (CDT) From: Chris Green Subject: xfs 1.3.3 beta 1 stock kernel source configure problems In-reply-to: <1082142267.25946.29.camel@stout.americas.sgi.com> To: linux-xfs@oss.sgi.com Message-id: MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit X-archive-position: 2822 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: greenc@fnal.gov Precedence: bulk X-list: linux-xfs Content-Length: 1895 Lines: 49 Hi, So, I just downloaded the RPMS from the indicated place for RHEL, and installed: # rpm -Uvh --freshen acl-2.2.23-1.i386.rpm attr-2.4.15-1.i386.rpm dmapi-2.1.0-1.i386.rpm dmapi-devel-2.1.0-1.i386.rpm libacl-2.2.23-1.i386.rpm libacl-devel-2.2.23-1.i386.rpm libattr-2.4.15-1.i386.rpm libattr-devel-2.4.15-1.i386.rpm xfsdump-2.2.17-1.i386.rpm xfsprogs-2.6.4-1.i386.rpm xfsprogs-devel-2.6.4-1.i386.rpm # rpm -ivh kernel-2.4.21-9.0.1.EL.sgi1.i686.rpm kernel-unsupported-2.4.21-9.0.1.EL.sgi1.i686.rpm kernel-smp-2.4.21-9.0.1.EL.sgi1.i686.rpm kernel-smp-unsupported-2.4.21-9.0.1.EL.sgi1.i686.rpm xfs-modules-1.3.3-2.4.21_9.0.1.EL.sgi1_sgi1.i686.rpm xfs-modules-smp-1.3.3-2.4.21_9.0.1.EL.sgi1_sgi1.i686.rpm # rpm -Uvh --freshen kernel-doc-2.4.21-9.0.1.EL.sgi1.i386.rpm kernel-source-2.4.21-9.0.1.EL.sgi1.i386.rpm # rpm -Uvh xfs-modules-BOOT-source-1.3.3-2.4.21_9.0.1.EL.sgi1_sgi1.i386.rpm I attempted to configure the kernel so I could build my favorite modules: # cd /usr/src/linux-2.4 # make mrproper >/dev/null 2>&1 # perl -wap -i.bak -e \ 'BEGIN { $is_smp='"$is_smp"'; $smp=$is_smp?"smp":""; } s|^(EXTRAVERSION\s*=\s*.*)custom$|$1$smp|' Makefile >/dev/null 2>&1 # cp configs/kernel-*-`uname -m`-smp.config ./.config # make oldconfig # make dep Everything went swimmingly, until: make[2]: Leaving directory `/usr/src/linux-2.4.21-9.0.1.EL.sgi1/crypto' make -C kdb fastdep make: Entering an unknown directory make: *** kdb: No such file or directory. Stop. make: Leaving an unknown directory make[1]: *** [_sfdep_kdb] Error 2 make[1]: Leaving directory `/usr/src/linux-2.4.21-9.0.1.EL.sgi1' make: *** [dep-files] Error 2 Oops. Indeed, the kdb directory is not as specified, but is in the arch/i386 directory. A problem with the RPM files list, perhaps? Help! Thanks, Chris. -- Chris Green, MiniBooNE / LANL. Email greenc@fnal.gov Tel: (630) 840-2167. Fax: (630) 840-3867 From owner-linux-xfs@oss.sgi.com Fri Apr 16 15:57:31 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 16 Apr 2004 15:57:34 -0700 (PDT) Received: from heretic.physik.fu-berlin.de (root@heretic.physik.fu-berlin.de [160.45.32.227]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3GMvTKO025113 for ; Fri, 16 Apr 2004 15:57:30 -0700 Received: by heretic.physik.fu-berlin.de (8.12.10/8.12.10) with ESMTP id i3GMvKR6023554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 17 Apr 2004 00:57:21 +0200 Received: (from thimm@localhost) by neu.nirvana (8.12.10/8.12.10/Submit) id i3GMvJRn012945; Sat, 17 Apr 2004 00:57:19 +0200 Date: Sat, 17 Apr 2004 00:57:19 +0200 From: Axel Thimm To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: Announce: xfs 1.3.3 beta 1 Message-ID: <20040416225719.GF6179@neu.nirvana> References: <1082135324.25946.17.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-type: text/plain Content-Disposition: inline In-Reply-To: <1082135324.25946.17.camel@stout.americas.sgi.com> User-Agent: Mutt/1.4.2i Content-Transfer-Encoding: 8bit X-archive-position: 2823 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Axel.Thimm@ATrpms.net Precedence: bulk X-list: linux-xfs Content-Length: 1852 Lines: 55 On Fri, Apr 16, 2004 at 12:08:44PM -0500, Eric Sandeen wrote: > ftp://oss.sgi.com/projects/xfs/testing/release-1.3.3-pre1 > > Released are RH9- and RHEL- based kernels for x86 architectures, Putting the kernel version into the rpm release tag is A Bad Thing for many reasons, most prominently the upgrade paths are broken/mangled. Please consider using something like kernel-2.4.20-30.9.1.sgi.i686.rpm xfs-kmdl-2.4.20-30.9.1.sgi-1.3.3-1.rh9.sgi.i686.rpm (or any scheme that puts the kernel version/release to the rpm name technically. The above scheme is the one used by ATrpms). Also put the repotag ("sgi") always last to avoid it to get involved in rpm comparision algorithms (well, at least to make it the least significant comparison operator). And as a last note: some of the current filenames may be too long for anaconda to deal with, if you or someone else (hello Stefan ;) build new installer mediums based on anaconda it should be considered. > as well as a tarball that contains fs/xfs/* which should be able to > overlay any kernel.org kernel >= 2.4.21 (although the RPMs have had > the most testing). Also, userspace rpms & tarballs. Does that mean that kernels >= 2.4.21 could be entirely built out of the tree with XFS 1.3.3 (e.g. the RHEL3/FC1 kernel)? Probably not, because there is a patched kernel for RHEL3, or am I missing something? Thanks for the release, it is certainly valuable to have QA'd XFS snapshots. > Please see the README in the above dir for more information, and fire > away with questions on the list. > > Thanks, > > -Eric > -- Axel.Thimm at ATrpms.net -- Attached file included as plaintext by Ecartis -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAgGTOQBVS1GOamfERAkilAJ4ldjCZXVjExWJ28Zn0YD6gtRPnLwCffKzg 31zCT0jhrmtvnlAnizesR4U= =13s2 -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Fri Apr 16 21:05:26 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 16 Apr 2004 21:05:36 -0700 (PDT) Received: from zok.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3H45PKO003932 for ; Fri, 16 Apr 2004 21:05:26 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i3H45Fhv006557 for ; Fri, 16 Apr 2004 21:05:17 -0700 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i3H45EKe37153529; Fri, 16 Apr 2004 23:05:14 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i3H45D7W569387; Fri, 16 Apr 2004 23:05:14 -0500 (CDT) Date: Fri, 16 Apr 2004 23:05:13 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Axel Thimm cc: linux-xfs@oss.sgi.com Subject: Re: Announce: xfs 1.3.3 beta 1 In-Reply-To: <20040416225719.GF6179@neu.nirvana> Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit X-archive-position: 2824 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 856 Lines: 22 On Sat, 17 Apr 2004, Axel Thimm wrote: > > as well as a tarball that contains fs/xfs/* which should be able to > > overlay any kernel.org kernel >= 2.4.21 (although the RPMs have had > > the most testing). Also, userspace rpms & tarballs. > > Does that mean that kernels >= 2.4.21 could be entirely built out of > the tree with XFS 1.3.3 (e.g. the RHEL3/FC1 kernel)? Probably not, > because there is a patched kernel for RHEL3, or am I missing > something? Argh, what was I thinking.... no, it won't work for 2.4.21, it would need to be laid over a kernel.org kernel that already has xfs in it, of course. Sorry, too many things in my brain lately. I'll get the README updated. thanks for the hints on the packaging, too, I'll look into that (hopefully can still follow an upgrade path to your suggested naming...) but not for this release. -Eric From owner-linux-xfs@oss.sgi.com Fri Apr 16 21:25:29 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 16 Apr 2004 21:25:46 -0700 (PDT) Received: from zok.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3H4PTKO004637 for ; Fri, 16 Apr 2004 21:25:29 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i3H4PNhv008352 for ; Fri, 16 Apr 2004 21:25:24 -0700 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i3H4PNKe37166447; Fri, 16 Apr 2004 23:25:23 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i3H4PM7W568029; Fri, 16 Apr 2004 23:25:22 -0500 (CDT) Date: Fri, 16 Apr 2004 23:25:22 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Chris Green cc: linux-xfs@oss.sgi.com Subject: Re: xfs 1.3.3 beta 1 stock kernel source configure problems In-Reply-To: Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit X-archive-position: 2825 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2438 Lines: 74 Well, that's why it's a test release. :) Need to add: /usr/src/linux-%{KVERREL}/kdb to the %files source section of the specfile; if you're anxious you could install the src.rpm, fix up the specfile, and rebuild the i386 target to get a proper kernel-source rpm (or just rpmbuild -bp it, and copy over kdb/) looks like the RH9 kernels are ok in this respect. thanks for finding that! -Eric On Fri, 16 Apr 2004, Chris Green wrote: > Hi, > > So, I just downloaded the RPMS from the indicated place for RHEL, and > installed: > > # rpm -Uvh --freshen acl-2.2.23-1.i386.rpm attr-2.4.15-1.i386.rpm dmapi-2.1.0-1.i386.rpm dmapi-devel-2.1.0-1.i386.rpm libacl-2.2.23-1.i386.rpm libacl-devel-2.2.23-1.i386.rpm libattr-2.4.15-1.i386.rpm libattr-devel-2.4.15-1.i386.rpm xfsdump-2.2.17-1.i386.rpm xfsprogs-2.6.4-1.i386.rpm xfsprogs-devel-2.6.4-1.i386.rpm > # rpm -ivh kernel-2.4.21-9.0.1.EL.sgi1.i686.rpm kernel-unsupported-2.4.21-9.0.1.EL.sgi1.i686.rpm kernel-smp-2.4.21-9.0.1.EL.sgi1.i686.rpm kernel-smp-unsupported-2.4.21-9.0.1.EL.sgi1.i686.rpm xfs-modules-1.3.3-2.4.21_9.0.1.EL.sgi1_sgi1.i686.rpm xfs-modules-smp-1.3.3-2.4.21_9.0.1.EL.sgi1_sgi1.i686.rpm > # rpm -Uvh --freshen kernel-doc-2.4.21-9.0.1.EL.sgi1.i386.rpm kernel-source-2.4.21-9.0.1.EL.sgi1.i386.rpm > # rpm -Uvh xfs-modules-BOOT-source-1.3.3-2.4.21_9.0.1.EL.sgi1_sgi1.i386.rpm > > I attempted to configure the kernel so I could build my favorite > modules: > > # cd /usr/src/linux-2.4 > # make mrproper >/dev/null 2>&1 > # perl -wap -i.bak -e \ > 'BEGIN { $is_smp='"$is_smp"'; $smp=$is_smp?"smp":""; } > s|^(EXTRAVERSION\s*=\s*.*)custom$|$1$smp|' Makefile >/dev/null 2>&1 > # cp configs/kernel-*-`uname -m`-smp.config ./.config > # make oldconfig > # make dep > > Everything went swimmingly, until: > > > make[2]: Leaving directory `/usr/src/linux-2.4.21-9.0.1.EL.sgi1/crypto' > make -C kdb fastdep > make: Entering an unknown directory > make: *** kdb: No such file or directory. Stop. > make: Leaving an unknown directory > make[1]: *** [_sfdep_kdb] Error 2 > make[1]: Leaving directory `/usr/src/linux-2.4.21-9.0.1.EL.sgi1' > make: *** [dep-files] Error 2 > > Oops. > > Indeed, the kdb directory is not as specified, but is in the arch/i386 > directory. A problem with the RPM files list, perhaps? > > Help! > > Thanks, > Chris. > > -- > Chris Green, MiniBooNE / LANL. Email greenc@fnal.gov > Tel: (630) 840-2167. Fax: (630) 840-3867 > > > From owner-linux-xfs@oss.sgi.com Sat Apr 17 00:26:30 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 17 Apr 2004 00:26:35 -0700 (PDT) Received: from heretic.physik.fu-berlin.de (root@heretic.physik.fu-berlin.de [160.45.32.227]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3H7QTKO010974 for ; Sat, 17 Apr 2004 00:26:29 -0700 Received: by heretic.physik.fu-berlin.de (8.12.10/8.12.10) with ESMTP id i3H7QLR6031446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 17 Apr 2004 09:26:23 +0200 Received: (from thimm@localhost) by neu.nirvana (8.12.10/8.12.10/Submit) id i3H7QKvK020863; Sat, 17 Apr 2004 09:26:20 +0200 Date: Sat, 17 Apr 2004 09:26:19 +0200 From: Axel Thimm To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: Announce: xfs 1.3.3 beta 1 Message-ID: <20040417072619.GB19634@neu.nirvana> Reply-To: linux-xfs@oss.sgi.com References: <20040416225719.GF6179@neu.nirvana> Mime-Version: 1.0 Content-type: text/plain Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2i Content-Transfer-Encoding: 8bit X-archive-position: 2826 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Axel.Thimm@ATrpms.net Precedence: bulk X-list: linux-xfs Content-Length: 1692 Lines: 44 On Fri, Apr 16, 2004 at 11:05:13PM -0500, Eric Sandeen wrote: > On Sat, 17 Apr 2004, Axel Thimm wrote: > > > > as well as a tarball that contains fs/xfs/* which should be able to > > > overlay any kernel.org kernel >= 2.4.21 (although the RPMs have had > > > the most testing). Also, userspace rpms & tarballs. > > > > Does that mean that kernels >= 2.4.21 could be entirely built out of > > the tree with XFS 1.3.3 (e.g. the RHEL3/FC1 kernel)? Probably not, > > because there is a patched kernel for RHEL3, or am I missing > > something? > > Argh, what was I thinking.... no, it won't work for 2.4.21, it > would need to be laid over a kernel.org kernel that already > has xfs in it, of course. Sorry, too many things in my brain > lately. I'll get the README updated. How big is the glue patch needed for kernels w/o xfs? I'd like to have my kernel series with this glue patch, so I can offer more frequent XFS updates with external builds. > thanks for the hints on the packaging, too, I'll look into that > (hopefully can still follow an upgrade path to your suggested > naming...) but not for this release. If you change names (in rpm terms) upgrade paths can easily be set up with "Obsoletes: oldname <= oldversion". (Don't skip the versioned part as it has happened too often that half a year later you decide to reuse this name, and w/o a version the old package will obsolete all future ones, too.) -- Axel.Thimm at ATrpms.net -- Attached file included as plaintext by Ecartis -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAgNwbQBVS1GOamfERAi0sAJ9BVWMc18/lOBfRCUJ8lshnyGcIZQCaAlRM 81QwdkjmEFJtsxzBkpJuK8g= =Nzjx -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Sat Apr 17 01:44:13 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 17 Apr 2004 01:44:16 -0700 (PDT) Received: from K-7.stesmi.com (1-2-2-1a.has.sth.bostream.se [82.182.130.86]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3H8iCKO012394 for ; Sat, 17 Apr 2004 01:44:13 -0700 Received: from stesmi.com (deltaflyer.stesmi.com [192.168.1.14]) by K-7.stesmi.com (8.12.8/8.12.5) with ESMTP id i3H8i7Id009709; Sat, 17 Apr 2004 10:44:07 +0200 Message-ID: <4080EE3F.9020409@stesmi.com> Date: Sat, 17 Apr 2004 10:43:43 +0200 From: Stefan Smietanowski User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Axel Thimm CC: Eric Sandeen , linux-xfs@oss.sgi.com Subject: Re: Announce: xfs 1.3.3 beta 1 References: <1082135324.25946.17.camel@stout.americas.sgi.com> <20040416225719.GF6179@neu.nirvana> In-Reply-To: <20040416225719.GF6179@neu.nirvana> Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2827 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stesmi@stesmi.com Precedence: bulk X-list: linux-xfs Content-Length: 1061 Lines: 26 Hi Axel. > And as a last note: some of the current filenames may be too long for > anaconda to deal with, if you or someone else (hello Stefan ;) build > new installer mediums based on anaconda it should be considered. There are two limitations in play. 1) Some people might stick them on a DVD (*whistles*) and they would most likely make it ISO9660/UDF (that's what I do). The filename length (max) of UDF is 64 characters but there is a switch for mkisofs that makes it accept longer and I believe the limit is 109 or something. But it's totally against the standard. 2) One part of the installer has a max filelength of 80 characters but that limit can be increased to somewhere around 100 characters. I haven't gotten adverse effects with it increased to that but I haven't looked through all the places it might be used so I'd be real careful about breaking that limit as well. So basically I think that making things max 64 chars long is the way to go. No problems with anaconda and no problems with the most popular CD/DVD filesystems. // Stefan From owner-linux-xfs@oss.sgi.com Sat Apr 17 12:30:57 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 17 Apr 2004 12:30:59 -0700 (PDT) Received: from mailgw1.fnal.gov (mailgw1.fnal.gov [131.225.111.11]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3HJUuKO002168 for ; Sat, 17 Apr 2004 12:30:57 -0700 Received: from conversion-daemon.mailgw1.fnal.gov by mailgw1.fnal.gov (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) id <0HWB00901XY41N@mailgw1.fnal.gov> (original mail from greenc@fnal.gov) for linux-xfs@oss.sgi.com; Sat, 17 Apr 2004 14:30:56 -0500 (CDT) Received: from maxwell.fnal.gov (maxwell.fnal.gov [131.225.54.225]) by mailgw1.fnal.gov (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPS id <0HWB00FMJY7JQU@mailgw1.fnal.gov>; Sat, 17 Apr 2004 14:30:56 -0500 (CDT) Date: Sat, 17 Apr 2004 14:30:55 -0500 (CDT) From: Chris Green Subject: Re: xfs 1.3.3 beta 1 stock kernel source configure problems In-reply-to: To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Message-id: MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit X-archive-position: 2828 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: greenc@fnal.gov Precedence: bulk X-list: linux-xfs Content-Length: 2518 Lines: 77 > (or just rpmbuild -bp it, and copy over kdb/) I did this, and it looks like we're cookin'. Thanks for the prompt reply and quick solution. Cheers, Chris. > > looks like the RH9 kernels are ok in this respect. > > thanks for finding that! > > -Eric > > On Fri, 16 Apr 2004, Chris Green wrote: > > > Hi, > > > > So, I just downloaded the RPMS from the indicated place for RHEL, and > > installed: > > > > # rpm -Uvh --freshen acl-2.2.23-1.i386.rpm attr-2.4.15-1.i386.rpm dmapi-2.1.0-1.i386.rpm dmapi-devel-2.1.0-1.i386.rpm libacl-2.2.23-1.i386.rpm libacl-devel-2.2.23-1.i386.rpm libattr-2.4.15-1.i386.rpm libattr-devel-2.4.15-1.i386.rpm xfsdump-2.2.17-1.i386.rpm xfsprogs-2.6.4-1.i386.rpm xfsprogs-devel-2.6.4-1.i386.rpm > > # rpm -ivh kernel-2.4.21-9.0.1.EL.sgi1.i686.rpm kernel-unsupported-2.4.21-9.0.1.EL.sgi1.i686.rpm kernel-smp-2.4.21-9.0.1.EL.sgi1.i686.rpm kernel-smp-unsupported-2.4.21-9.0.1.EL.sgi1.i686.rpm xfs-modules-1.3.3-2.4.21_9.0.1.EL.sgi1_sgi1.i686.rpm xfs-modules-smp-1.3.3-2.4.21_9.0.1.EL.sgi1_sgi1.i686.rpm > > # rpm -Uvh --freshen kernel-doc-2.4.21-9.0.1.EL.sgi1.i386.rpm kernel-source-2.4.21-9.0.1.EL.sgi1.i386.rpm > > # rpm -Uvh xfs-modules-BOOT-source-1.3.3-2.4.21_9.0.1.EL.sgi1_sgi1.i386.rpm > > > > I attempted to configure the kernel so I could build my favorite > > modules: > > > > # cd /usr/src/linux-2.4 > > # make mrproper >/dev/null 2>&1 > > # perl -wap -i.bak -e \ > > 'BEGIN { $is_smp='"$is_smp"'; $smp=$is_smp?"smp":""; } > > s|^(EXTRAVERSION\s*=\s*.*)custom$|$1$smp|' Makefile >/dev/null 2>&1 > > # cp configs/kernel-*-`uname -m`-smp.config ./.config > > # make oldconfig > > # make dep > > > > Everything went swimmingly, until: > > > > > > make[2]: Leaving directory `/usr/src/linux-2.4.21-9.0.1.EL.sgi1/crypto' > > make -C kdb fastdep > > make: Entering an unknown directory > > make: *** kdb: No such file or directory. Stop. > > make: Leaving an unknown directory > > make[1]: *** [_sfdep_kdb] Error 2 > > make[1]: Leaving directory `/usr/src/linux-2.4.21-9.0.1.EL.sgi1' > > make: *** [dep-files] Error 2 > > > > Oops. > > > > Indeed, the kdb directory is not as specified, but is in the arch/i386 > > directory. A problem with the RPM files list, perhaps? > > > > Help! > > > > Thanks, > > Chris. > > > > -- > > Chris Green, MiniBooNE / LANL. Email greenc@fnal.gov > > Tel: (630) 840-2167. Fax: (630) 840-3867 > > > > > > > > > -- Chris Green, MiniBooNE / LANL. Email greenc@fnal.gov Tel: (630) 840-2167. Fax: (630) 840-3867 From owner-linux-xfs@oss.sgi.com Mon Apr 19 03:28:08 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 19 Apr 2004 03:28:12 -0700 (PDT) Received: from lucius.provo.novell.com (lucius.provo.novell.com [137.65.81.172]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3JAS7KO008371 for ; Mon, 19 Apr 2004 03:28:08 -0700 Received: from INET-PRV1-MTA by lucius.provo.novell.com with Novell_GroupWise; Mon, 19 Apr 2004 04:28:02 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta Date: Mon, 19 Apr 2004 04:27:43 -0600 From: "Pandurang Kale" To: , Subject: Hi, Mime-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Disposition: inline X-archive-position: 2841 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: pkale@novell.com Precedence: bulk X-list: linux-xfs Content-Length: 1170 Lines: 33 Hi, I am using the SPEC SFS3.0 tool to evaluate the performance of NFS server on Netware machine using Linux client. I am able to compile the tool for the linux client , but when i run ( option 7 in advance mode ) i get the following error : ------------------------------------------------------------------------------------------------------------------ >>>>> STARTED SFS RUNS ON 04/19/04 AT 03:44:10 <<<<< Mon Apr 19 03:44:10 IST 2004 Executing run 1 of 10 ... sfs_mgr: sfs_prime returned an error, exiting SFS TEST TERMINATED WITH ERRORS Check error messages in the /home/spec/spec-sfs3.0/benchspec/162.nfsv2/r esult/sfs*.log files To Continue Please Press The key: ------------------------------------------------------------------------------------------------------------------ can you help me in clarifying what would have gone wrong or am i missing any configuration , as i have followed each and every step of configuration as mentioned in the README section of SFS3.0 document, as i am struggling to get the tool working. Please do reply at the earliest. Thanks and regards, Pandurang Kale. From owner-linux-xfs@oss.sgi.com Mon Apr 19 03:41:06 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 19 Apr 2004 03:41:19 -0700 (PDT) Received: from zok.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3JAf6KO008930 for ; Mon, 19 Apr 2004 03:41:06 -0700 Received: from omx2.sgi.com ([198.149.32.25]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i3JAZ1hv006195 for ; Mon, 19 Apr 2004 03:35:01 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with SMTP id i3JCVFHO007697 for ; Mon, 19 Apr 2004 05:31:28 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.54.232]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA11710 for ; Mon, 19 Apr 2004 20:24:13 +1000 Received: from sherman.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by sherman.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id i3JAOCmX007262 for ; Mon, 19 Apr 2004 20:24:13 +1000 Received: (from nathans@localhost) by sherman.melbourne.sgi.com (8.12.8/8.12.8/Submit) id i3JAOB23007260 for linux-xfs@oss.sgi.com; Mon, 19 Apr 2004 20:24:11 +1000 Date: Mon, 19 Apr 2004 20:24:11 +1000 From: Nathan Scott Message-Id: <200404191024.i3JAOB23007260@sherman.melbourne.sgi.com> Subject: TAKE 907752 - Merge up to 2.4.26 Apparently-To: X-archive-position: 2842 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sherman.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 20504 Lines: 652 Move a couple of config options about for easier merging. Date: Mon Apr 19 00:19:25 PDT 2004 Workarea: sherman.melbourne.sgi.com:/build/nathans/2.4.x-xfs Inspected by: nathans@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: 2.4.x-xfs:linux:170283a fs/Config.in - 1.5 Merge up to 2.4.26. Date: Mon Apr 19 03:11:07 PDT 2004 Workarea: sherman.melbourne.sgi.com:/build/nathans/2.4.x-xfs Inspected by: marcelo.tosatti@cyclades.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: 2.4.x-xfs:linux:170287a drivers/usb/gadget/config.c - 1.1 drivers/net/wireless/atmel_cs.c - 1.1 drivers/net/wireless/atmel.c - 1.1 drivers/usb/gadget/gadget_chips.h - 1.1 include/asm-ppc/cpm2.h - 1.1 include/asm-ppc/immap_cpm2.h - 1.1 net/sched/sch_delay.c - 1.1 Documentation/networking/packet_mmap.txt - 1.1 drivers/net/forcedeth.c - 1.1 drivers/ide/raid/medley.c - 1.1 drivers/ide/pci/atiixp.c - 1.1 crypto/scatterwalk.h - 1.1 crypto/scatterwalk.c - 1.1 crypto/arc4.c - 1.1 arch/x86_64/kernel/swiotlb.c - 1.1 net/sctp/chunk.c - 1.1 arch/ppc/platforms/rpx8260.h - 1.1 arch/ppc/platforms/redwood6.h - 1.1 arch/ppc/platforms/redwood6.c - 1.1 arch/ppc/platforms/redwood5.h - 1.1 arch/ppc/platforms/redwood5.c - 1.1 arch/ppc/platforms/pq2ads.h - 1.1 arch/ppc/platforms/ibmstbx25.h - 1.1 arch/ppc/platforms/ibmstbx25.c - 1.1 arch/ppc/platforms/ibmstb4.h - 1.1 arch/ppc/platforms/ibmstb4.c - 1.1 arch/ppc/platforms/ep405.h - 1.1 arch/ppc/platforms/ep405.c - 1.1 arch/ppc/kernel/ppc4xx_stbdma.c - 1.1 arch/ppc/kernel/ibm44x_common.h - 1.1 arch/ppc/kernel/ibm440gx_common.h - 1.1 arch/ppc/kernel/ibm440gx_common.c - 1.1 arch/ppc/kernel/cpm2_pic.h - 1.1 arch/ppc/kernel/cpm2_pic.c - 1.1 arch/ppc/cpm2_io/uart.c - 1.1 arch/ppc/cpm2_io/fcc_enet.c - 1.1 arch/ppc/cpm2_io/enet.c - 1.1 arch/ppc/cpm2_io/commproc.c - 1.1 arch/ppc/cpm2_io/Makefile - 1.1 arch/ppc/cpm2_io/Config.in - 1.1 arch/ppc/configs/rpx8260_defconfig - 1.1 arch/ppc/configs/redwood6_defconfig - 1.1 arch/ppc/configs/redwood5_defconfig - 1.1 arch/ppc/configs/ep405_defconfig - 1.1 arch/ppc/configs/ads8272_defconfig - 1.1 CREDITS - 1.5 Documentation/Configure.help - 1.12 Documentation/crypto/api-intro.txt - 1.3 Documentation/kernel-parameters.txt - 1.2 Documentation/networking/bonding.txt - 1.2 Documentation/networking/ifenslave.c - 1.2 Documentation/networking/ip-sysctl.txt - 1.2 MAINTAINERS - 1.7 Makefile - 1.12 arch/alpha/lib/ev6-stxncpy.S - 1.2 arch/alpha/lib/stxncpy.S - 1.2 arch/i386/defconfig - 1.3 arch/i386/kernel/acpi.c - 1.2 arch/i386/kernel/dmi_scan.c - 1.2 arch/i386/kernel/i386_ksyms.c - 1.2 arch/i386/kernel/io_apic.c - 1.3 arch/i386/kernel/microcode.c - 1.3 arch/i386/kernel/mpparse.c - 1.2 arch/i386/kernel/pci-irq.c - 1.2 arch/i386/kernel/setup.c - 1.3 arch/i386/kernel/smpboot.c - 1.4 arch/i386/mm/init.c - 1.2 arch/ia64/ia32/ia32_signal.c - 1.2 arch/ia64/kernel/Makefile - 1.2 arch/ia64/kernel/acpi.c - 1.3 arch/ia64/kernel/ia64_ksyms.c - 1.3 arch/ia64/kernel/mca.c - 1.3 arch/ia64/kernel/pci.c - 1.3 arch/ia64/kernel/ptrace.c - 1.2 arch/ia64/kernel/salinfo.c - 1.3 arch/ia64/kernel/signal.c - 1.2 arch/ia64/kernel/smpboot.c - 1.2 arch/ia64/kernel/unwind.c - 1.2 arch/ia64/kernel/unwind_i.h - 1.2 arch/ia64/sn/kernel/mca.c - 1.2 arch/ia64/tools/Makefile - 1.2 arch/m68k/mac/baboon.c - 1.2 arch/m68k/mac/config.c - 1.2 arch/ppc/8260_io/Config.in - 1.2 arch/ppc/8260_io/Makefile - 1.2 arch/ppc/8260_io/commproc.c - 1.2 arch/ppc/8260_io/enet.c - 1.2 arch/ppc/8260_io/fcc_enet.c - 1.2 arch/ppc/8260_io/uart.c - 1.2 arch/ppc/Makefile - 1.2 arch/ppc/boot/common/misc-simple.c - 1.4 arch/ppc/boot/simple/embed_config.c - 1.3 arch/ppc/boot/simple/m8260_tty.c - 1.2 arch/ppc/config.in - 1.6 arch/ppc/configs/est8260_defconfig - 1.5 arch/ppc/kernel/Makefile - 1.4 arch/ppc/kernel/cputable.c - 1.2 arch/ppc/kernel/entry.S - 1.2 arch/ppc/kernel/head.S - 1.2 arch/ppc/kernel/head_44x.S - 1.2 arch/ppc/kernel/ibm440gp_common.c - 1.2 arch/ppc/kernel/ibm440gp_common.h - 1.2 arch/ppc/kernel/m8260_setup.c - 1.2 arch/ppc/kernel/misc.S - 1.2 arch/ppc/kernel/ocp.c - 1.2 arch/ppc/kernel/ppc8260_pic.c - 1.2 arch/ppc/kernel/ppc8260_pic.h - 1.2 arch/ppc/kernel/ppc_ksyms.c - 1.4 arch/ppc/kernel/setup.c - 1.4 arch/ppc/kernel/traps.c - 1.2 arch/ppc/lib/string.S - 1.2 arch/ppc/platforms/Makefile - 1.5 arch/ppc/platforms/ebony.c - 1.4 arch/ppc/platforms/est8260.h - 1.2 arch/ppc/platforms/ocotea.c - 1.4 arch/ppc/platforms/ocotea.h - 1.4 arch/sparc/defconfig - 1.3 arch/sparc/kernel/sys_sunos.c - 1.2 arch/sparc64/defconfig - 1.5 arch/sparc64/kernel/sys_sparc32.c - 1.3 arch/sparc64/kernel/sys_sunos32.c - 1.2 arch/sparc64/mm/modutil.c - 1.2 arch/x86_64/Makefile - 1.2 arch/x86_64/boot/setup.S - 1.2 arch/x86_64/config.in - 1.3 arch/x86_64/defconfig - 1.3 arch/x86_64/ia32/ia32_ioctl.c - 1.3 arch/x86_64/ia32/ptrace32.c - 1.4 arch/x86_64/ia32/sys_ia32.c - 1.3 arch/x86_64/kernel/Makefile - 1.2 arch/x86_64/kernel/acpi.c - 1.2 arch/x86_64/kernel/aperture.c - 1.2 arch/x86_64/kernel/e820.c - 1.3 arch/x86_64/kernel/head.S - 1.2 arch/x86_64/kernel/io_apic.c - 1.2 arch/x86_64/kernel/mpparse.c - 1.2 arch/x86_64/kernel/mtrr.c - 1.3 arch/x86_64/kernel/nmi.c - 1.2 arch/x86_64/kernel/pci-gart.c - 1.3 arch/x86_64/kernel/pci-pc.c - 1.2 arch/x86_64/kernel/process.c - 1.3 arch/x86_64/kernel/setup.c - 1.2 arch/x86_64/kernel/setup64.c - 1.2 arch/x86_64/kernel/smpboot.c - 1.2 arch/x86_64/kernel/traps.c - 1.2 arch/x86_64/kernel/x8664_ksyms.c - 1.2 arch/x86_64/lib/copy_page.S - 1.2 arch/x86_64/lib/copy_user.S - 1.2 arch/x86_64/lib/csum-copy.S - 1.2 arch/x86_64/lib/csum-partial.c - 1.2 arch/x86_64/lib/usercopy.c - 1.2 arch/x86_64/mm/fault.c - 1.2 arch/x86_64/mm/k8topology.c - 1.3 arch/x86_64/mm/pageattr.c - 1.2 crypto/Config.in - 1.3 crypto/Makefile - 1.3 crypto/cipher.c - 1.3 crypto/internal.h - 1.2 crypto/tcrypt.c - 1.3 crypto/tcrypt.h - 1.3 drivers/acpi/Config.in - 1.2 drivers/acpi/bus.c - 1.2 drivers/acpi/dispatcher/dsmethod.c - 1.3 drivers/acpi/dispatcher/dsmthdat.c - 1.4 drivers/acpi/dispatcher/dsobject.c - 1.3 drivers/acpi/dispatcher/dsopcode.c - 1.3 drivers/acpi/dispatcher/dsutils.c - 1.3 drivers/acpi/dispatcher/dswstate.c - 1.3 drivers/acpi/ec.c - 1.3 drivers/acpi/events/evgpe.c - 1.3 drivers/acpi/events/evgpeblk.c - 1.3 drivers/acpi/events/evmisc.c - 1.3 drivers/acpi/events/evxfevnt.c - 1.3 drivers/acpi/executer/exconvrt.c - 1.3 drivers/acpi/executer/excreate.c - 1.3 drivers/acpi/executer/exdump.c - 1.3 drivers/acpi/executer/exfldio.c - 1.3 drivers/acpi/executer/exmisc.c - 1.3 drivers/acpi/executer/exmutex.c - 1.3 drivers/acpi/executer/exoparg2.c - 1.3 drivers/acpi/executer/exprep.c - 1.3 drivers/acpi/executer/exresnte.c - 1.3 drivers/acpi/executer/exresolv.c - 1.3 drivers/acpi/executer/exresop.c - 1.3 drivers/acpi/executer/exstore.c - 1.3 drivers/acpi/executer/exstoren.c - 1.3 drivers/acpi/hardware/hwgpe.c - 1.3 drivers/acpi/hardware/hwregs.c - 1.3 drivers/acpi/hardware/hwsleep.c - 1.3 drivers/acpi/namespace/nsaccess.c - 1.3 drivers/acpi/namespace/nsalloc.c - 1.3 drivers/acpi/namespace/nsdump.c - 1.3 drivers/acpi/namespace/nseval.c - 1.3 drivers/acpi/namespace/nssearch.c - 1.3 drivers/acpi/namespace/nsutils.c - 1.3 drivers/acpi/namespace/nsxfeval.c - 1.3 drivers/acpi/namespace/nsxfname.c - 1.3 drivers/acpi/osl.c - 1.3 drivers/acpi/parser/psargs.c - 1.3 drivers/acpi/parser/psparse.c - 1.3 drivers/acpi/parser/psscope.c - 1.3 drivers/acpi/pci_irq.c - 1.3 drivers/acpi/pci_link.c - 1.2 drivers/acpi/processor.c - 1.3 drivers/acpi/resources/rsaddr.c - 1.3 drivers/acpi/resources/rsxface.c - 1.3 drivers/acpi/system.c - 1.2 drivers/acpi/toshiba_acpi.c - 1.4 drivers/acpi/utilities/uteval.c - 1.3 drivers/acpi/utilities/utglobal.c - 1.3 drivers/acpi/utilities/utmisc.c - 1.3 drivers/atm/nicstar.c - 1.3 drivers/block/cciss.c - 1.4 drivers/block/cciss_scsi.c - 1.2 drivers/block/ll_rw_blk.c - 1.2 drivers/bluetooth/hci_usb.c - 1.2 drivers/bluetooth/hci_usb.h - 1.2 drivers/char/agp/agpgart_be.c - 1.4 drivers/char/drm-4.0/r128_state.c - 1.2 drivers/char/drm/r128_state.c - 1.3 drivers/char/q40_keyb.c - 1.2 drivers/char/sonypi.c - 1.2 drivers/char/sonypi.h - 1.2 drivers/char/tty_io.c - 1.3 drivers/i2c/Config.in - 1.5 drivers/ide/Config.in - 1.4 drivers/ide/Makefile - 1.2 drivers/ide/ide-probe.c - 1.2 drivers/ide/ide-proc.c - 1.3 drivers/ide/pci/Makefile - 1.2 drivers/ide/pci/amd74xx.c - 1.2 drivers/ide/pci/amd74xx.h - 1.2 drivers/ide/pci/generic.h - 1.2 drivers/ide/pci/hpt366.c - 1.2 drivers/ide/pci/piix.c - 1.2 drivers/ide/pci/piix.h - 1.2 drivers/ide/pci/siimage.c - 1.2 drivers/ide/raid/Makefile - 1.2 drivers/ieee1394/dma.c - 1.2 drivers/ieee1394/video1394.c - 1.2 drivers/input/input.c - 1.2 drivers/isdn/avmb1/capidrv.c - 1.2 drivers/isdn/avmb1/kcapi.c - 1.2 drivers/isdn/hisax/isurf.c - 1.2 drivers/md/lvm-snap.c - 1.4 drivers/md/raid1.c - 1.2 drivers/media/video/Config.in - 1.2 drivers/media/video/meye.c - 1.2 drivers/media/video/meye.h - 1.2 drivers/net/8139too.c - 1.2 drivers/net/Config.in - 1.2 drivers/net/Makefile - 1.2 drivers/net/bonding/bond_3ad.c - 1.2 drivers/net/bonding/bond_3ad.h - 1.2 drivers/net/bonding/bond_alb.c - 1.2 drivers/net/bonding/bond_alb.h - 1.2 drivers/net/bonding/bond_main.c - 1.2 drivers/net/bonding/bonding.h - 1.2 drivers/net/e1000/e1000.h - 1.2 drivers/net/e1000/e1000_ethtool.c - 1.2 drivers/net/e1000/e1000_hw.c - 1.2 drivers/net/e1000/e1000_hw.h - 1.2 drivers/net/e1000/e1000_main.c - 1.2 drivers/net/e1000/e1000_osdep.h - 1.2 drivers/net/e1000/e1000_param.c - 1.2 drivers/net/ibm_emac/ibm_emac.h - 1.2 drivers/net/ibm_emac/ibm_ocp_enet.c - 1.2 drivers/net/ibm_emac/ibm_ocp_mal.c - 1.2 drivers/net/natsemi.c - 1.2 drivers/net/ne2k-pci.c - 1.2 drivers/net/pcnet32.c - 1.2 drivers/net/r8169.c - 1.2 drivers/net/sis900.c - 1.2 drivers/net/sk98lin/h/lm80.h - 1.2 drivers/net/sk98lin/h/skaddr.h - 1.2 drivers/net/sk98lin/h/skcsum.h - 1.2 drivers/net/sk98lin/h/skdebug.h - 1.2 drivers/net/sk98lin/h/skdrv1st.h - 1.2 drivers/net/sk98lin/h/skdrv2nd.h - 1.2 drivers/net/sk98lin/h/skerror.h - 1.2 drivers/net/sk98lin/h/skgedrv.h - 1.2 drivers/net/sk98lin/h/skgehw.h - 1.2 drivers/net/sk98lin/h/skgehwt.h - 1.2 drivers/net/sk98lin/h/skgei2c.h - 1.2 drivers/net/sk98lin/h/skgeinit.h - 1.2 drivers/net/sk98lin/h/skgepnm2.h - 1.2 drivers/net/sk98lin/h/skgepnmi.h - 1.2 drivers/net/sk98lin/h/skgesirq.h - 1.2 drivers/net/sk98lin/h/ski2c.h - 1.2 drivers/net/sk98lin/h/skqueue.h - 1.2 drivers/net/sk98lin/h/skrlmt.h - 1.2 drivers/net/sk98lin/h/sktimer.h - 1.2 drivers/net/sk98lin/h/sktypes.h - 1.2 drivers/net/sk98lin/h/skversion.h - 1.3 drivers/net/sk98lin/h/skvpd.h - 1.2 drivers/net/sk98lin/h/xmac_ii.h - 1.2 drivers/net/sk98lin/skaddr.c - 1.2 drivers/net/sk98lin/skcsum.c - 1.2 drivers/net/sk98lin/skdim.c - 1.2 drivers/net/sk98lin/skge.c - 1.3 drivers/net/sk98lin/skgehwt.c - 1.2 drivers/net/sk98lin/skgeinit.c - 1.2 drivers/net/sk98lin/skgemib.c - 1.2 drivers/net/sk98lin/skgepnmi.c - 1.2 drivers/net/sk98lin/skgesirq.c - 1.2 drivers/net/sk98lin/ski2c.c - 1.2 drivers/net/sk98lin/sklm80.c - 1.2 drivers/net/sk98lin/skproc.c - 1.2 drivers/net/sk98lin/skqueue.c - 1.2 drivers/net/sk98lin/skrlmt.c - 1.2 drivers/net/sk98lin/sktimer.c - 1.2 drivers/net/sk98lin/skvpd.c - 1.2 drivers/net/sk98lin/skxmac2.c - 1.2 drivers/net/sk_mca.c - 1.2 drivers/net/sungem.c - 1.2 drivers/net/tg3.c - 1.4 drivers/net/tg3.h - 1.2 drivers/net/tulip/tulip_core.c - 1.2 drivers/net/typhoon-firmware.h - 1.2 drivers/net/typhoon.c - 1.2 drivers/net/typhoon.h - 1.2 drivers/net/wireless/Config.in - 1.2 drivers/net/wireless/Makefile - 1.2 drivers/net/wireless/airo.c - 1.2 drivers/pcmcia/yenta.c - 1.3 drivers/scsi/advansys.c - 1.2 drivers/scsi/eata_dma.c - 1.2 drivers/scsi/qlogicfc.c - 1.2 drivers/scsi/qlogicpti.c - 1.2 drivers/scsi/scsi_error.c - 1.2 drivers/scsi/scsi_lib.c - 1.2 drivers/scsi/scsi_scan.c - 1.2 drivers/scsi/scsi_syms.c - 1.2 drivers/scsi/sym53c8xx.c - 1.2 drivers/scsi/sym53c8xx_2/sym_hipd.c - 1.2 drivers/sound/i810_audio.c - 1.2 drivers/sound/sb_audio.c - 1.2 drivers/usb/audio.c - 1.2 drivers/usb/gadget/Config.in - 1.3 drivers/usb/gadget/Makefile - 1.3 drivers/usb/gadget/ether.c - 1.3 drivers/usb/gadget/net2280.c - 1.3 drivers/usb/gadget/usbstring.c - 1.2 drivers/usb/gadget/zero.c - 1.3 drivers/usb/hcd.c - 1.2 drivers/usb/hid-core.c - 1.4 drivers/usb/hid-input.c - 1.2 drivers/usb/hiddev.c - 1.2 drivers/usb/host/ehci-dbg.c - 1.3 drivers/usb/host/ehci-hub.c - 1.2 drivers/usb/host/ehci-sched.c - 1.3 drivers/usb/host/usb-ohci.c - 1.3 drivers/usb/host/usb-ohci.h - 1.3 drivers/usb/pegasus.h - 1.2 drivers/usb/printer.c - 1.2 drivers/usb/serial/ftdi_sio.c - 1.2 drivers/usb/serial/ftdi_sio.h - 1.2 drivers/usb/serial/io_edgeport.c - 1.2 drivers/usb/serial/pl2303.c - 1.2 drivers/usb/serial/visor.c - 1.3 drivers/usb/serial/visor.h - 1.3 drivers/usb/storage/datafab.c - 1.2 drivers/usb/storage/scsiglue.c - 1.2 drivers/usb/storage/unusual_devs.h - 1.3 drivers/usb/usbnet.c - 1.2 drivers/usb/w9968cf.c - 1.3 drivers/video/amifb.c - 1.2 drivers/video/pm3fb.c - 1.2 drivers/video/radeonfb.c - 1.2 drivers/video/sis/300vtbl.h - 1.3 drivers/video/sis/310vtbl.h - 1.3 drivers/video/sis/init.c - 1.3 drivers/video/sis/init.h - 1.3 drivers/video/sis/init301.c - 1.3 drivers/video/sis/init301.h - 1.3 drivers/video/sis/initdef.h - 1.3 drivers/video/sis/oem300.h - 1.3 drivers/video/sis/oem310.h - 1.3 drivers/video/sis/osdef.h - 1.3 drivers/video/sis/sis_accel.c - 1.3 drivers/video/sis/sis_accel.h - 1.3 drivers/video/sis/sis_main.c - 1.3 drivers/video/sis/sis_main.h - 1.3 drivers/video/sis/vgatypes.h - 1.3 drivers/video/sis/vstruct.h - 1.3 fs/binfmt_elf.c - 1.3 fs/devfs/base.c - 1.2 fs/fat/inode.c - 1.3 fs/hfsplus/wrapper.c - 1.2 fs/inode.c - 1.4 fs/isofs/rock.c - 1.2 fs/jbd/journal.c - 1.3 fs/jfs/jfs_dmap.c - 1.2 fs/jfs/jfs_dmap.h - 1.2 fs/jfs/jfs_dtree.c - 1.2 fs/jfs/jfs_dtree.h - 1.2 fs/jfs/jfs_extent.c - 1.2 fs/jfs/jfs_imap.c - 1.2 fs/jfs/jfs_logmgr.c - 1.4 fs/jfs/jfs_logmgr.h - 1.2 fs/jfs/jfs_metapage.c - 1.2 fs/jfs/jfs_txnmgr.c - 1.3 fs/jfs/jfs_unicode.c - 1.2 fs/jfs/jfs_xtree.c - 1.2 fs/jfs/jfs_xtree.h - 1.2 fs/jfs/namei.c - 1.3 fs/jfs/super.c - 1.2 fs/lockd/svc4proc.c - 1.2 fs/lockd/svclock.c - 1.2 fs/lockd/svcproc.c - 1.2 fs/lockd/xdr.c - 1.2 fs/lockd/xdr4.c - 1.2 fs/locks.c - 1.2 fs/nfs/dir.c - 1.2 fs/nfs/file.c - 1.2 fs/nfs/inode.c - 1.2 fs/nfs/pagelist.c - 1.2 fs/nfs/read.c - 1.2 fs/nfs/write.c - 1.2 fs/smbfs/proc.c - 1.3 include/acpi/acconfig.h - 1.3 include/acpi/acglobal.h - 1.3 include/acpi/achware.h - 1.3 include/acpi/aclocal.h - 1.3 include/acpi/acmacros.h - 1.3 include/acpi/acobject.h - 1.3 include/acpi/acpi_bus.h - 1.2 include/acpi/actypes.h - 1.3 include/acpi/acutils.h - 1.3 include/acpi/amlcode.h - 1.3 include/asm-i386/acpi.h - 1.2 include/asm-i386/highmem.h - 1.2 include/asm-i386/mpspec.h - 1.2 include/asm-i386/system.h - 1.2 include/asm-ia64/a.out.h - 1.2 include/asm-ia64/acpi.h - 1.2 include/asm-ia64/bugs.h - 1.2 include/asm-ia64/byteorder.h - 1.2 include/asm-ia64/checksum.h - 1.2 include/asm-ia64/current.h - 1.2 include/asm-ia64/errno.h - 1.2 include/asm-ia64/fcntl.h - 1.2 include/asm-ia64/ioctl.h - 1.2 include/asm-ia64/ioctls.h - 1.2 include/asm-ia64/mca.h - 1.3 include/asm-ia64/mman.h - 1.2 include/asm-ia64/namei.h - 1.2 include/asm-ia64/page.h - 1.3 include/asm-ia64/param.h - 1.2 include/asm-ia64/poll.h - 1.2 include/asm-ia64/posix_types.h - 1.2 include/asm-ia64/processor.h - 1.3 include/asm-ia64/resource.h - 1.2 include/asm-ia64/scatterlist.h - 1.2 include/asm-ia64/siginfo.h - 1.2 include/asm-ia64/signal.h - 1.2 include/asm-ia64/socket.h - 1.2 include/asm-ia64/sockios.h - 1.2 include/asm-ia64/stat.h - 1.2 include/asm-ia64/statfs.h - 1.2 include/asm-ia64/termbits.h - 1.2 include/asm-ia64/termios.h - 1.2 include/asm-ia64/types.h - 1.2 include/asm-ia64/uaccess.h - 1.2 include/asm-ia64/unaligned.h - 1.2 include/asm-ia64/unwind.h - 1.2 include/asm-ia64/user.h - 1.2 include/asm-m68k/keyboard.h - 1.2 include/asm-ppc/cpm_8260.h - 1.2 include/asm-ppc/ibm44x.h - 1.2 include/asm-ppc/ibm4xx.h - 1.3 include/asm-ppc/immap_8260.h - 1.2 include/asm-ppc/mpc8260.h - 1.2 include/asm-ppc/ocp.h - 1.2 include/asm-ppc/ocp_ids.h - 1.2 include/asm-ppc/ppc_asm.h - 1.2 include/asm-ppc/ppcboot.h - 1.2 include/asm-ppc/processor.h - 1.2 include/asm-x86_64/acpi.h - 1.2 include/asm-x86_64/cpufeature.h - 1.2 include/asm-x86_64/mpspec.h - 1.2 include/asm-x86_64/pci-direct.h - 1.2 include/asm-x86_64/pci.h - 1.2 include/asm-x86_64/pgtable.h - 1.2 include/asm-x86_64/processor.h - 1.2 include/asm-x86_64/proto.h - 1.2 include/asm-x86_64/scatterlist.h - 1.2 include/asm-x86_64/smp.h - 1.2 include/asm-x86_64/uaccess.h - 1.3 include/linux/compiler.h - 1.2 include/linux/hiddev.h - 1.2 include/linux/ide.h - 1.2 include/linux/if_bonding.h - 1.2 include/linux/if_vlan.h - 1.2 include/linux/inetdevice.h - 1.3 include/linux/init.h - 1.2 include/linux/jhash.h - 1.2 include/linux/lockd/debug.h - 1.2 include/linux/lockd/lockd.h - 1.2 include/linux/lockd/xdr.h - 1.2 include/linux/module.h - 1.3 include/linux/netfilter_ipv4/ip_conntrack.h - 1.3 include/linux/netfilter_ipv4/ip_nat.h - 1.2 include/linux/netfilter_ipv4/listhelp.h - 1.2 include/linux/nfs_fs.h - 1.2 include/linux/nfs_page.h - 1.2 include/linux/pci.h - 1.2 include/linux/pci_ids.h - 1.3 include/linux/pkt_sched.h - 1.3 include/linux/sctp.h - 1.2 include/linux/sisfb.h - 1.3 include/linux/skbuff.h - 1.2 include/linux/sysctl.h - 1.5 include/linux/usb_gadget.h - 1.3 include/net/arp.h - 1.2 include/net/bluetooth/hci.h - 1.2 include/net/bluetooth/hci_core.h - 1.3 include/net/ip_vs.h - 1.2 include/net/ipv6.h - 1.2 include/net/sctp/command.h - 1.2 include/net/sctp/compat.h - 1.2 include/net/sctp/constants.h - 1.2 include/net/sctp/sctp.h - 1.2 include/net/sctp/sm.h - 1.2 include/net/sctp/structs.h - 1.2 include/net/sctp/tsnmap.h - 1.2 include/net/sctp/ulpevent.h - 1.2 include/net/sctp/user.h - 1.2 include/net/sock.h - 1.2 include/net/tcp.h - 1.2 kernel/fork.c - 1.2 lib/Makefile - 1.2 lib/crc32.c - 1.2 mm/filemap.c - 1.4 mm/mremap.c - 1.4 mm/vmalloc.c - 1.2 net/8021q/vlan_dev.c - 1.2 net/Makefile - 1.2 net/atm/lec.c - 1.2 net/atm/mpoa_proc.c - 1.2 net/bluetooth/af_bluetooth.c - 1.2 net/bluetooth/bnep/sock.c - 1.2 net/bluetooth/cmtp/sock.c - 1.2 net/bluetooth/hci_conn.c - 1.3 net/bluetooth/hci_core.c - 1.3 net/bluetooth/l2cap.c - 1.2 net/bluetooth/rfcomm/core.c - 1.2 net/bluetooth/rfcomm/tty.c - 1.2 net/core/dev.c - 1.4 net/core/sock.c - 1.2 net/ipv4/arp.c - 1.2 net/ipv4/devinet.c - 1.4 net/ipv4/icmp.c - 1.3 net/ipv4/igmp.c - 1.5 net/ipv4/ip_sockglue.c - 1.2 net/ipv4/ipvs/Config.in - 1.2 net/ipv4/ipvs/ip_vs_app.c - 1.2 net/ipv4/ipvs/ip_vs_conn.c - 1.2 net/ipv4/ipvs/ip_vs_ctl.c - 1.2 net/ipv4/ipvs/ip_vs_dh.c - 1.2 net/ipv4/ipvs/ip_vs_ftp.c - 1.2 net/ipv4/ipvs/ip_vs_lblc.c - 1.2 net/ipv4/ipvs/ip_vs_lblcr.c - 1.2 net/ipv4/ipvs/ip_vs_lc.c - 1.2 net/ipv4/ipvs/ip_vs_nq.c - 1.2 net/ipv4/ipvs/ip_vs_rr.c - 1.2 net/ipv4/ipvs/ip_vs_sched.c - 1.2 net/ipv4/ipvs/ip_vs_sed.c - 1.2 net/ipv4/ipvs/ip_vs_sh.c - 1.2 net/ipv4/ipvs/ip_vs_sync.c - 1.2 net/ipv4/ipvs/ip_vs_wlc.c - 1.2 net/ipv4/ipvs/ip_vs_wrr.c - 1.2 net/ipv4/netfilter/ip_nat_standalone.c - 1.3 net/ipv4/netfilter/ipt_ECN.c - 1.2 net/ipv4/netfilter/ipt_MASQUERADE.c - 1.2 net/ipv4/sysctl_net_ipv4.c - 1.2 net/ipv4/tcp_input.c - 1.2 net/ipv4/tcp_ipv4.c - 1.2 net/ipv4/udp.c - 1.2 net/ipv6/exthdrs.c - 1.2 net/ipv6/icmp.c - 1.2 net/ipv6/ipv6_sockglue.c - 1.2 net/ipv6/ipv6_syms.c - 1.2 net/ipv6/mcast.c - 1.4 net/ipv6/ndisc.c - 1.2 net/ipv6/netfilter/ip6_tables.c - 1.3 net/ipv6/sysctl_net_ipv6.c - 1.2 net/ipv6/tcp_ipv6.c - 1.2 net/ipv6/udp.c - 1.2 net/netsyms.c - 1.2 net/packet/af_packet.c - 1.2 net/sched/Config.in - 1.3 net/sched/Makefile - 1.2 net/sched/sch_fifo.c - 1.2 net/sched/sch_gred.c - 1.2 net/sched/sch_htb.c - 1.4 net/sched/sch_red.c - 1.2 net/sched/sch_tbf.c - 1.4 net/sctp/Config.in - 1.2 net/sctp/Makefile - 1.2 net/sctp/associola.c - 1.2 net/sctp/bind_addr.c - 1.2 net/sctp/debug.c - 1.2 net/sctp/endpointola.c - 1.2 net/sctp/input.c - 1.2 net/sctp/inqueue.c - 1.2 net/sctp/ipv6.c - 1.2 net/sctp/objcnt.c - 1.2 net/sctp/output.c - 1.2 net/sctp/outqueue.c - 1.2 net/sctp/primitive.c - 1.2 net/sctp/proc.c - 1.2 net/sctp/protocol.c - 1.2 net/sctp/sm_make_chunk.c - 1.2 net/sctp/sm_sideeffect.c - 1.2 net/sctp/sm_statefuns.c - 1.2 net/sctp/sm_statetable.c - 1.2 net/sctp/socket.c - 1.2 net/sctp/ssnmap.c - 1.2 net/sctp/sysctl.c - 1.2 net/sctp/transport.c - 1.2 net/sctp/tsnmap.c - 1.2 net/sctp/ulpevent.c - 1.2 net/sctp/ulpqueue.c - 1.2 arch/ppc64/kernel/lparcfg.c - 1.2 net/sched/sch_hfsc.c - 1.2 From owner-linux-xfs@oss.sgi.com Mon Apr 19 04:14:43 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 19 Apr 2004 04:14:52 -0700 (PDT) Received: from omx1.americas.sgi.com (cfcafw.sgi.com [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3JBEMKO010545 for ; Mon, 19 Apr 2004 04:14:42 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with SMTP id i3JBCcGj007667 for ; Mon, 19 Apr 2004 06:12:40 -0500 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.54.232]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA12537 for ; Mon, 19 Apr 2004 21:12:37 +1000 Received: from sherman.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by sherman.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id i3JBCamX008390 for ; Mon, 19 Apr 2004 21:12:36 +1000 Received: (from nathans@localhost) by sherman.melbourne.sgi.com (8.12.8/8.12.8/Submit) id i3JBCZa5008388 for linux-xfs@oss.sgi.com; Mon, 19 Apr 2004 21:12:35 +1000 Date: Mon, 19 Apr 2004 21:12:35 +1000 From: Nathan Scott Message-Id: <200404191112.i3JBCZa5008388@sherman.melbourne.sgi.com> Subject: TAKE 904196 - split patches Apparently-To: X-archive-position: 2843 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sherman.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2482 Lines: 77 Reinstate the split patches, these are now generated auto-magically as a side-effect of using quilt to manage tree merges. cheers. Date: Mon Apr 19 04:06:40 PDT 2004 Workarea: sherman.melbourne.sgi.com:/build/nathans/2.4.x-xfs Inspected by: nathans@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: 2.4.x-xfs:linux:170288a split-patches/xfs-modules - 1.1 split-patches/series - 1.1 split-patches/rwsem-backport - 1.1 split-patches/kdb-i386 - 1.1 split-patches/kdb-common - 1.1 split-patches/docs-update - 1.1 split-patches/dmapi-enable - 1.1 split-patches/acl-backport - 1.1 - XFS development tree split patches for 2.4.26 drivers/cdrom/aztcd.h - 1.2 drivers/isdn/divert/divert_init.c - 1.2 drivers/parport/ieee1284.c - 1.2 drivers/scsi/README.aic7xxx - 1.2 drivers/usb/storage/shuttle_usbat.h - 1.2 drivers/usb/gadget/config.c - 1.2 drivers/net/wireless/atmel_cs.c - 1.2 drivers/net/wireless/atmel.c - 1.2 drivers/usb/gadget/gadget_chips.h - 1.2 include/asm-ppc/cpm2.h - 1.2 include/asm-ppc/immap_cpm2.h - 1.2 net/sched/sch_delay.c - 1.2 Documentation/networking/packet_mmap.txt - 1.2 drivers/net/forcedeth.c - 1.2 drivers/ide/raid/medley.c - 1.2 drivers/ide/pci/atiixp.c - 1.2 crypto/scatterwalk.h - 1.2 crypto/scatterwalk.c - 1.2 crypto/arc4.c - 1.2 arch/x86_64/kernel/swiotlb.c - 1.2 net/sctp/chunk.c - 1.2 arch/ppc/platforms/rpx8260.h - 1.2 arch/ppc/platforms/redwood6.h - 1.2 arch/ppc/platforms/redwood6.c - 1.2 arch/ppc/platforms/redwood5.h - 1.2 arch/ppc/platforms/redwood5.c - 1.2 arch/ppc/platforms/pq2ads.h - 1.2 arch/ppc/platforms/ibmstbx25.h - 1.2 arch/ppc/platforms/ibmstbx25.c - 1.2 arch/ppc/platforms/ibmstb4.h - 1.2 arch/ppc/platforms/ibmstb4.c - 1.2 arch/ppc/platforms/ep405.h - 1.2 arch/ppc/platforms/ep405.c - 1.2 arch/ppc/kernel/ppc4xx_stbdma.c - 1.2 arch/ppc/kernel/ibm44x_common.h - 1.2 arch/ppc/kernel/ibm440gx_common.h - 1.2 arch/ppc/kernel/ibm440gx_common.c - 1.2 arch/ppc/kernel/cpm2_pic.h - 1.2 arch/ppc/kernel/cpm2_pic.c - 1.2 arch/ppc/cpm2_io/uart.c - 1.2 arch/ppc/cpm2_io/fcc_enet.c - 1.2 arch/ppc/cpm2_io/enet.c - 1.2 arch/ppc/cpm2_io/commproc.c - 1.2 arch/ppc/cpm2_io/Makefile - 1.2 arch/ppc/cpm2_io/Config.in - 1.2 arch/ppc/configs/rpx8260_defconfig - 1.2 arch/ppc/configs/redwood6_defconfig - 1.2 arch/ppc/configs/redwood5_defconfig - 1.2 arch/ppc/configs/ep405_defconfig - 1.2 arch/ppc/configs/ads8272_defconfig - 1.2 - an over-eager script seems to have patched some files twice.. From owner-linux-xfs@oss.sgi.com Mon Apr 19 04:35:17 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 19 Apr 2004 04:35:22 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i3JBZHKO014615 for ; Mon, 19 Apr 2004 04:35:17 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i3JBZH0o014614 for linux-xfs@oss.sgi.com; Mon, 19 Apr 2004 04:35:17 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i3JBZFKQ014600 for ; Mon, 19 Apr 2004 04:35:15 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i3JAqZvc009597; Mon, 19 Apr 2004 03:52:35 -0700 Date: Mon, 19 Apr 2004 03:52:35 -0700 Message-Id: <200404191052.i3JAqZvc009597@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 310] Zeroed files on / partition after clean unmount X-Bugzilla-Reason: AssignedTo X-archive-position: 2844 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 685 Lines: 23 http://oss.sgi.com/bugzilla/show_bug.cgi?id=310 ja@mail.upjs.sk changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From ja@mail.upjs.sk 2004-19-04 03:52 PDT ------- I tested kernel 2.6.5 from SGI's CVS: SGI-XFS CVS-2004-04-18_05:00_UTC with ACLs, realtime, no debug enabled. I'm unable to reproduce the bug with this kernel. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Apr 19 07:00:50 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 19 Apr 2004 07:00:54 -0700 (PDT) Received: from camelot.virtualavalon.net (rrcs-se-24-73-202-230.biz.rr.com [24.73.202.230]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3JE0mKO006097 for ; Mon, 19 Apr 2004 07:00:49 -0700 Received: from arthur.virtualavalon.net (arthur.virtualavalon.net [172.20.1.10]) by camelot.virtualavalon.net (8.12.0/8.12.0) with ESMTP id i3JF53qu002223 for ; Mon, 19 Apr 2004 11:05:03 -0400 Received: from tampabay.rr.com (merlin.virtualavalon.net [172.20.1.11]) by arthur.virtualavalon.net (8.12.10/8.12.0) with ESMTP id i3JDxBF5012684 for ; Mon, 19 Apr 2004 09:59:11 -0400 (EDT) Message-ID: <4083DB82.5010804@tampabay.rr.com> Date: Mon, 19 Apr 2004 10:00:34 -0400 From: "Jesse W. Asher" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en, ja MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Trying to get XFS compiled into 2.4.21. Content-type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-archive-position: 2846 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jasher1@tampabay.rr.com Precedence: bulk X-list: linux-xfs Content-Length: 1591 Lines: 39 Hello everyone!! I'm trying to get XFS complied into a stock 2.4.21 kernel and I'm having some difficulties. I downloaded the stock kernel from kernel.org and applied the linux-2.4.21-core-xfs-1.3.1.patch from the OSS ftp site. I ran "make menuconfig" and configed all the stuff I wanted. When I go to do a "make dep", however, it barfs. Here's the error I get: make[4]: Entering directory `/usr/src/linux-2.4.21/fs/vfat' /usr/src/linux-2.4.21/scripts/mkdep -D__KERNEL__ -I/usr/src/linux-2.4.21/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -nostdinc -iwithprefix include -- namei.c vfatfs_syms.c > .depend make[4]: Leaving directory `/usr/src/linux-2.4.21/fs/vfat' make -C xfs fastdep make: Entering an unknown directory make: *** xfs: No such file or directory. Stop. make: Leaving an unknown directory make[3]: *** [_sfdep_xfs] Error 2 make[3]: Leaving directory `/usr/src/linux-2.4.21/fs' make[2]: *** [fastdep] Error 2 make[2]: Leaving directory `/usr/src/linux-2.4.21/fs' make[1]: *** [_sfdep_fs] Error 2 make[1]: Leaving directory `/usr/src/linux-2.4.21' make: *** [dep-files] Error 2 I did a "find" in the top level kernel source directory and couldn't find ANY files or directories with "xfs" anywhere in the name. This leads me to believe that XFS isn't in this kernel. I know the kernel patched successfully because I tried to patch it again and it asked me if I wanted to reverse the patch. Anyone know what's going on here? Many thanks!! From owner-linux-xfs@oss.sgi.com Mon Apr 19 07:03:44 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 19 Apr 2004 07:03:49 -0700 (PDT) Received: from phoenix.infradead.org (phoenix.infradead.org [213.86.99.234]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3JE3hKO006741 for ; Mon, 19 Apr 2004 07:03:44 -0700 Received: from hch by phoenix.infradead.org with local (Exim 4.30 #5 (Red Hat Linux)) id 1BFZN6-00038m-Ps; Mon, 19 Apr 2004 15:03:40 +0100 Date: Mon, 19 Apr 2004 15:03:40 +0100 From: Christoph Hellwig To: "Jesse W. Asher" Cc: linux-xfs@oss.sgi.com Subject: Re: Trying to get XFS compiled into 2.4.21. Message-ID: <20040419150340.A12037@infradead.org> References: <4083DB82.5010804@tampabay.rr.com> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <4083DB82.5010804@tampabay.rr.com>; from jasher1@tampabay.rr.com on Mon, Apr 19, 2004 at 10:00:34AM -0400 Content-Transfer-Encoding: 8bit X-archive-position: 2847 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 693 Lines: 16 On Mon, Apr 19, 2004 at 10:00:34AM -0400, Jesse W. Asher wrote: > > Hello everyone!! > > I'm trying to get XFS complied into a stock 2.4.21 kernel and I'm having > some difficulties. I downloaded the stock kernel from kernel.org and > applied the linux-2.4.21-core-xfs-1.3.1.patch from the OSS ftp site. I > ran "make menuconfig" and configed all the stuff I wanted. When I go to > do a "make dep", however, it barfs. Here's the error I get: There *-core-* patch is just the kernel changes to support XFS. You need the other patch from the same directory to actually add the XFS code. That beeing said I'd suggest you simply use kernel 2.4.25/26 which have XFS already included. From owner-linux-xfs@oss.sgi.com Mon Apr 19 07:05:56 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 19 Apr 2004 07:06:01 -0700 (PDT) Received: from rrzd1.rz.uni-regensburg.de (rrzd1.rz.uni-regensburg.de [132.199.1.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3JE5mKO007183 for ; Mon, 19 Apr 2004 07:05:49 -0700 Received: from rrzd1 (rrzd1 [127.0.0.1]) by rrzd1.rz.uni-regensburg.de (8.12.3/8.12.3/Debian -4) with ESMTP id i3JE5kWL017555; Mon, 19 Apr 2004 16:05:46 +0200 Received: from rx3227.cip.uni-regensburg.de ([132.199.237.32]) by rrzd1 (MailMonitor for SMTP v1.2.2 ) ; Mon, 19 Apr 2004 16:05:41 +0200 (CEST) Subject: Re: Trying to get XFS compiled into 2.4.21. From: Christian Guggenberger Reply-To: christian.guggenberger@physik.uni-regensburg.de To: "Jesse W. Asher" Cc: linux-xfs@oss.sgi.com In-Reply-To: <4083DB82.5010804@tampabay.rr.com> References: <4083DB82.5010804@tampabay.rr.com> Content-type: text/plain Message-Id: <1082383540.1923.1.camel@bonnie79> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 19 Apr 2004 16:05:41 +0200 Content-Transfer-Encoding: 8bit X-archive-position: 2848 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: christian.guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs Content-Length: 602 Lines: 18 On Mon, 2004-04-19 at 16:00, Jesse W. Asher wrote: > Hello everyone!! > > I'm trying to get XFS complied into a stock 2.4.21 kernel and I'm having > some difficulties. I downloaded the stock kernel from kernel.org and > applied the linux-2.4.21-core-xfs-1.3.1.patch from the OSS ftp site. I > ran "make menuconfig" and configed all the stuff I wanted. When I go to > do a "make dep", however, it barfs. Here's the error I get: > you'll need the xfs bits, too. These are in separate patch: ftp://oss.sgi.com/projects/xfs/Release-1.3.1/kernel_patches/linux-xfs-1.3.1.patch.gz - Christian From owner-linux-xfs@oss.sgi.com Mon Apr 19 17:57:12 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 19 Apr 2004 17:57:16 -0700 (PDT) Received: from omx2.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3K0vCKO008908 for ; Mon, 19 Apr 2004 17:57:12 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i3K33hNW017042 for ; Mon, 19 Apr 2004 20:03:53 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by nodin.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i3K0uZpl3131953 for ; Mon, 19 Apr 2004 17:56:36 -0700 (PDT) Received: (from nathans@localhost) by chook.melbourne.sgi.com (8.11.6/8.11.6) id i3K0ttS25580 for linux-xfs@oss.sgi.com; Tue, 20 Apr 2004 10:55:55 +1000 Date: Tue, 20 Apr 2004 10:55:55 +1000 From: Nathan Scott Message-Id: <200404200055.i3K0ttS25580@chook.melbourne.sgi.com> Subject: TAKE 907752 - kdb X-archive-position: 2849 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@chook.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 353 Lines: 14 Merge in Keiths latest 2.6 kdb changes. Date: Mon Apr 19 17:54:58 PDT 2004 Workarea: chook.melbourne.sgi.com:/build/nathans/2.6.x-xfs Inspected by: nathans@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: 2.6.x-xfs:linux:170329a arch/i386/kernel/io_apic.c - 1.10 arch/i386/kdb/ChangeLog - 1.5 From owner-linux-xfs@oss.sgi.com Mon Apr 19 20:21:02 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 19 Apr 2004 20:21:05 -0700 (PDT) Received: from omx2.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3K3L2KO016078 for ; Mon, 19 Apr 2004 20:21:02 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i3K5RXnp024062 for ; Mon, 19 Apr 2004 22:27:43 -0700 Received: (from nathans@localhost) by chook.melbourne.sgi.com (8.11.6/8.11.6) id i3K3KPg30229 for linux-xfs@oss.sgi.com; Tue, 20 Apr 2004 13:20:25 +1000 Date: Tue, 20 Apr 2004 13:20:25 +1000 From: Nathan Scott Message-Id: <200404200320.i3K3KPg30229@chook.melbourne.sgi.com> Subject: TAKE 904196 - Split patches for 2.6 kernels. X-archive-position: 2850 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@chook.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 481 Lines: 17 Date: Mon Apr 19 18:39:33 PDT 2004 Workarea: chook.melbourne.sgi.com:/build/nathans/2.6.x-xfs Inspected by: Split patches for the 2.6 XFS tree. The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: 2.6.x-xfs:linux:170336a split-patches/dmapi-enable - 1.1 split-patches/doc-update - 1.1 split-patches/kdb-common - 1.1 split-patches/kdb-i386 - 1.1 split-patches/series - 1.1 split-patches/xfs-debug - 1.1 split-patches/xfs-modules - 1.1 From owner-linux-xfs@oss.sgi.com Tue Apr 20 00:34:28 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 20 Apr 2004 00:34:38 -0700 (PDT) Received: from omx2.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3K7YNKO028143 for ; Tue, 20 Apr 2004 00:34:23 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i3K9etMl010470 for ; Tue, 20 Apr 2004 02:41:06 -0700 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i3K7XXAL46941993; Tue, 20 Apr 2004 17:33:34 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i3K7XTwB47985375; Tue, 20 Apr 2004 17:33:29 +1000 (EST) Date: Tue, 20 Apr 2004 17:33:29 +1000 (EST) From: Nathan Scott Message-Id: <200404200733.i3K7XTwB47985375@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 913258 - clear s_dirt in sync_super X-archive-position: 2851 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 376 Lines: 13 Clear the superblock dirty flag after flushing the log in sync_super. Date: Tue Apr 20 00:32:28 PDT 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/ultra-clean-xfs-linux Inspected by: hch@lst.de,felixb@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:170342a linux-2.4/xfs_super.c - 1.285 From owner-linux-xfs@oss.sgi.com Tue Apr 20 01:12:26 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 20 Apr 2004 01:12:34 -0700 (PDT) Received: from zok.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3K8CQKO029237 for ; Tue, 20 Apr 2004 01:12:26 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i3K885hv030480 for ; Tue, 20 Apr 2004 01:08:06 -0700 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i3K87WAL47984213; Tue, 20 Apr 2004 18:07:35 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i3K87N6248422060; Tue, 20 Apr 2004 18:07:23 +1000 (EST) Date: Tue, 20 Apr 2004 18:07:23 +1000 (EST) From: Nathan Scott Message-Id: <200404200807.i3K87N6248422060@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 912155 - fix truncate X-archive-position: 2852 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 420 Lines: 15 Fix vmtruncate abuse in the XFS setattr ATTR_SIZE operation. Date: Tue Apr 20 01:04:37 PDT 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/ultra-clean-xfs-linux Inspected by: hch@lst.de,felixb@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:170344a xfs_vnodeops.c - 1.622 linux-2.6/xfs_linux.h - 1.121 linux-2.4/xfs_linux.h - 1.131 From owner-linux-xfs@oss.sgi.com Tue Apr 20 15:35:24 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 20 Apr 2004 15:35:28 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i3KMZOKO003166 for ; Tue, 20 Apr 2004 15:35:24 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i3KMZODI003165 for linux-xfs@oss.sgi.com; Tue, 20 Apr 2004 15:35:24 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i3KMZMKQ003149 for ; Tue, 20 Apr 2004 15:35:22 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i3KLvVBx002303; Tue, 20 Apr 2004 14:57:31 -0700 Date: Tue, 20 Apr 2004 14:57:31 -0700 Message-Id: <200404202157.i3KLvVBx002303@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 324] New: oops with xfs_fsr on 2.6.5-1.326 X-Bugzilla-Reason: AssignedTo X-archive-position: 2856 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2742 Lines: 63 http://oss.sgi.com/bugzilla/show_bug.cgi?id=324 Summary: oops with xfs_fsr on 2.6.5-1.326 Product: Linux XFS Version: 1.3.x Platform: IA32 OS/Version: Linux Status: NEW Severity: critical Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: matteo@sif.it xfs_fsr leads to the following oops on 2.6.5-1.326 x86 (fedora core2 development), gcc-3.3.3: Apr 20 23:09:49 stout kernel: Unable to handle kernel paging request at virtual address feffdd74 Apr 20 23:09:49 stout kernel: printing eip: Apr 20 23:09:49 stout kernel: 19911456 Apr 20 23:09:49 stout kernel: *pde = 00000000 Apr 20 23:09:49 stout kernel: Oops: 0002 [#1] Apr 20 23:09:49 stout kernel: CPU: 0 Apr 20 23:09:49 stout kernel: EIP: 0060:[<19911456>] Not tainted Apr 20 23:09:49 stout kernel: EFLAGS: 00210246 (2.6.5-1.326custom) Apr 20 23:09:49 stout kernel: EIP is at xfs_bulkstat_one+0x162/0x4a4 [xfs] Apr 20 23:09:49 stout kernel: eax: 00002200 ebx: 00000000 ecx: feffdd20 edx: 00000000 Apr 20 23:09:49 stout kernel: esi: 00000080 edi: 00000000 ebp: 183a2000 esp: 14301d74 Apr 20 23:09:49 stout kernel: ds: 007b es: 007b ss: 0068 Apr 20 23:09:49 stout kernel: Process xfs_fsr (pid: 1593, threadinfo=14301000 task=06b45360) Apr 20 23:09:49 stout kernel: Stack: 00000000 00000040 00000000 1843f480 00000000 00000040 00000000 00000000 Apr 20 23:09:49 stout kernel: 00000000 199122da 00000080 00000000 feffdd20 00001b00 00000000 00000040 Apr 20 23:09:49 stout kernel: 00000000 14301e50 183a2000 14301e54 00000001 00000000 00000001 00000000 Apr 20 23:09:49 stout kernel: Call Trace: Apr 20 23:09:49 stout kernel: [<199122da>] xfs_bulkstat+0xb42/0xd25 [xfs] Apr 20 23:09:49 stout kernel: [<19931cda>] xfs_ioc_bulkstat+0x107/0x15c [xfs] Apr 20 23:09:49 stout kernel: [<199112f4>] xfs_bulkstat_one+0x0/0x4a4 [xfs] Apr 20 23:09:49 stout kernel: [<19931802>] xfs_ioctl+0x2f7/0x63e [xfs] Apr 20 23:09:49 stout kernel: [<021b6c66>] inode_doinit_with_dentry+0x44/0x611 Apr 20 23:09:49 stout kernel: [<02177a1e>] d_splice_alias+0x236/0x23f Apr 20 23:09:49 stout kernel: [<199326b1>] linvfs_lookup+0x64/0x69 [xfs] Apr 20 23:09:49 stout kernel: [<0216cd44>] __lookup_hash+0x70/0x89 Apr 20 23:09:49 stout kernel: [<19930a22>] linvfs_ioctl+0x1c/0xfa [xfs] Apr 20 23:09:49 stout kernel: [<02170712>] sys_ioctl+0x29a/0x33c Apr 20 23:09:49 stout kernel: Apr 20 23:09:49 stout kernel: Code: 66 c7 41 54 00 00 c1 e2 08 c1 e8 08 09 c2 66 89 51 0a eb 2d Reproduced multiple times. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Tue Apr 20 19:50:26 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 20 Apr 2004 19:50:32 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i3L2oQKO013057 for ; Tue, 20 Apr 2004 19:50:26 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i3L2oQPc013056 for linux-xfs@oss.sgi.com; Tue, 20 Apr 2004 19:50:26 -0700 Received: from dingdong.cryptoapps.com (uslink-66.173.43-129.uslink.net [66.173.43.129] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3L2oLKO013040; Tue, 20 Apr 2004 19:50:21 -0700 Received: by dingdong.cryptoapps.com (Postfix, from userid 1001) id CE020FB951; Tue, 20 Apr 2004 21:50:05 -0500 (CDT) Date: Tue, 20 Apr 2004 19:50:05 -0700 From: Chris Wedgwood To: bugzilla-daemon@oss.sgi.com Cc: xfs-master@oss.sgi.com, matteo@sif.it Subject: Re: [Bug 324] New: oops with xfs_fsr on 2.6.5-1.326 Message-ID: <20040421025005.GB11146@dingdong.cryptoapps.com> References: <200404202157.i3KLvVBx002303@oss.sgi.com> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200404202157.i3KLvVBx002303@oss.sgi.com> Content-Transfer-Encoding: 8bit X-archive-position: 2857 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 325 Lines: 10 On Tue, Apr 20, 2004 at 02:57:31PM -0700, bugzilla-daemon@oss.sgi.com wrote: > Summary: oops with xfs_fsr on 2.6.5-1.326 Apparently fc2 uses CONFIG_4KSTACKS which will cause problems with XFS right now (if there is /proc/config.gz you can check there). Please see recompile without CONFIG_4KSTACKS and retry. From owner-linux-xfs@oss.sgi.com Wed Apr 21 02:08:09 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 21 Apr 2004 02:08:12 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i3L989KO028356 for ; Wed, 21 Apr 2004 02:08:09 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i3L989EE028353 for linux-xfs@oss.sgi.com; Wed, 21 Apr 2004 02:08:09 -0700 Received: from quasar.sif.it (IDENT:root@quasar.sif.it [131.154.110.3]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3L985KO028341; Wed, 21 Apr 2004 02:08:06 -0700 Received: from astra.sif.it (IDENT:matteo@astra.sif.it [131.154.110.1]) by quasar.sif.it (8.12.9/SQL-8.12.9-5/8.12.9) with ESMTP id i3L981aY019983; Wed, 21 Apr 2004 11:08:01 +0200 Date: Wed, 21 Apr 2004 11:08:01 +0200 (CEST) From: Matteo Centonza To: Chris Wedgwood cc: bugzilla-daemon@oss.sgi.com, Subject: Re: [Bug 324] New: oops with xfs_fsr on 2.6.5-1.326 In-Reply-To: <20040421025005.GB11146@dingdong.cryptoapps.com> Message-ID: MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit X-archive-position: 2859 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: matteo@sif.it Precedence: bulk X-list: linux-xfs Content-Length: 417 Lines: 17 On Tue, 20 Apr 2004, Chris Wedgwood wrote: > > Summary: oops with xfs_fsr on 2.6.5-1.326 > > Apparently fc2 uses CONFIG_4KSTACKS which will cause problems with XFS > right now (if there is /proc/config.gz you can check there). > > Please see recompile without CONFIG_4KSTACKS and retry. i haven't my laptop handy but seems not the case since RH backed it out starting from 2.6.5-1.309. Thanks, -m From owner-linux-xfs@oss.sgi.com Wed Apr 21 08:22:47 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 21 Apr 2004 08:22:51 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i3LFMlKO013586 for ; Wed, 21 Apr 2004 08:22:47 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i3LFMlKo013583 for linux-xfs@oss.sgi.com; Wed, 21 Apr 2004 08:22:47 -0700 Received: from zok.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3LFMjKO013571; Wed, 21 Apr 2004 08:22:45 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i3LFMdhv022752; Wed, 21 Apr 2004 08:22:40 -0700 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i3LFMdKe37360128; Wed, 21 Apr 2004 10:22:39 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i3LFMcHO271894; Wed, 21 Apr 2004 10:22:39 -0500 (CDT) Subject: Re: [Bug 324] New: oops with xfs_fsr on 2.6.5-1.326 From: Eric Sandeen To: Matteo Centonza Cc: Chris Wedgwood , bugzilla-daemon@oss.sgi.com, xfs-master@oss.sgi.com In-Reply-To: References: Content-type: text/plain Organization: Eric Conspiracy Secret Labs Message-Id: <1082560958.15446.1.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 21 Apr 2004 10:22:38 -0500 Content-Transfer-Encoding: 8bit X-archive-position: 2860 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 345 Lines: 17 On Wed, 2004-04-21 at 04:08, Matteo Centonza wrote: > i haven't my laptop handy but seems not the case since RH backed it out > starting from 2.6.5-1.309. > > Thanks, > > -m it seems to be in as of 1.332.... -Eric -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Wed Apr 21 08:43:56 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 21 Apr 2004 08:44:02 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i3LFhuKO014754 for ; Wed, 21 Apr 2004 08:43:56 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i3LFhuDB014753 for linux-xfs@oss.sgi.com; Wed, 21 Apr 2004 08:43:56 -0700 Received: from relay03.roc.ny.frontiernet.net (relay03.roc.ny.frontiernet.net [66.133.131.36]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3LFhpKO014737 for ; Wed, 21 Apr 2004 08:43:52 -0700 Received: (qmail 23191 invoked from network); 21 Apr 2004 15:43:50 -0000 Received: from 208-186-10-249.nrp1.brv.mn.frontiernet.net (HELO xfs.org) ([208.186.10.249]) (envelope-sender ) by relay03.roc.ny.frontiernet.net (FrontierMTA 2.3.18) with SMTP for ; 21 Apr 2004 15:43:50 -0000 Message-ID: <408696B9.7050209@xfs.org> Date: Wed, 21 Apr 2004 10:43:53 -0500 From: Steve Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Sandeen CC: Matteo Centonza , Chris Wedgwood , bugzilla-daemon@oss.sgi.com, xfs-master@oss.sgi.com Subject: Re: [Bug 324] New: oops with xfs_fsr on 2.6.5-1.326 References: <1082560958.15446.1.camel@stout.americas.sgi.com> In-Reply-To: <1082560958.15446.1.camel@stout.americas.sgi.com> Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2861 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 790 Lines: 29 Eric Sandeen wrote: > On Wed, 2004-04-21 at 04:08, Matteo Centonza wrote: > > >>i haven't my laptop handy but seems not the case since RH backed it out >>starting from 2.6.5-1.309. >> >>Thanks, >> >>-m > > > it seems to be in as of 1.332.... > > -Eric > The problem here is that we are not just talking about xfs stack usage, we are talking about the complete I/O stack in some cases. So if you are using a combination of XFS, LVM, and some driver which is stack hungry, then all bets are off without lots of work - and not just in XFS. I have actually been running Linus's tree with 4K stacks on my XFS only laptop for a week or so without problems. I build kernels, I use bitkeeper etc. Probably the fact that I am just using a simple ide drive is the saving grace here. Steve From owner-linux-xfs@oss.sgi.com Wed Apr 21 11:54:51 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 21 Apr 2004 11:54:57 -0700 (PDT) Received: from hptimail01.HPTI.COM ([208.20.6.201]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3LIsoKO022366 for ; Wed, 21 Apr 2004 11:54:51 -0700 Received: from hpti9.fsl.noaa.gov ([137.75.132.229]) by hptimail01.HPTI.COM with Microsoft SMTPSVC(6.0.3790.0); Wed, 21 Apr 2004 14:54:49 -0400 Subject: Problem with writing data to xfs+nfs server under heavy load From: Craig Tierney To: linux-xfs@oss.sgi.com Content-type: text/plain Message-Id: <1082573639.2374.23.camel@hpti9.fsl.noaa.gov> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Wed, 21 Apr 2004 12:53:59 -0600 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 21 Apr 2004 18:54:50.0018 (UTC) FILETIME=[1F9C7820:01C427D2] X-archive-position: 2862 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ctierney@HPTI.com Precedence: bulk X-list: linux-xfs Content-Length: 3282 Lines: 75 I had posted this problem with data corruption with nfs+xfs couple of months ago. I thought we have solved the problem, blaming the gigE driver. However, it appears that this is not the case. The code we are running had enough bugs in it that it was difficult to isolate the problem (plus one other unrelated hardware problem). Problem: Files are corrupted when they are written under load. Load is defined as 20+ clients writing to the same filesystem, but different files, simultaneously. However, with the testcase we are using now, we can see corruption with as few as 4 clients writing, but it is more difficult to generate errors this way. The IO of the test code is relatively simple. It reads in some data over NFS. Each case reads the exact same file(s). It then massages the data and writes out a temporary file. Each file has about 20 different records, and each record is written as 1 big unformatted write in fortran. Each run creates 17 files. The temporary files are written to the NFS filesystem. Each file is then read back in, 1 record chuck at a time, massaged, then written back out in the same manner as before, but to a different file. Configuration: Clients: Fedora Core 1 + Updates, e100 network driver Server: Fedora Core 1 + Updates, kernel updated to 2.4.26, - Broadcom (bcm5700, tg3) and Acenic gigE tested, both fail - Filesystems are mounted over FC, qla2200 v6.01.10 driver used - Filesystem is striped using LVM using multiple targets to increase performance. In the past other kernels for the clients and servers have been tested and show the same problem. Tests attempted had the server exporting the xfs filesystem over nfs. Although other servers were not tried (to test for bad hardware) this was done previously and the same results occurred. Tests were run conducted with the clients mounting the Filesystems over UDP and TCP. Both cases failed. Tests run over an nfs filesystem exporting an ext2 filesystem (LVM striped, FC disks, qla2200 driver) do not exhibit this problem. Tests configured to write the temporary file and final output file to local disc never show corruption. However, there isn't much load on each system in this case. The only heavy load is on the read of the initial data, but I never get any file corruption due to these reads. I looked at all of the bits just after reads and just before writes. >From this I can conclude that corruption only occurs during writes, and not reads. I checked the source code and I could not find anywhere that HAVE_REFCACHE was enabled. So functions like xfs_refcache_purge_some should be no-ops. When there is corruption of the final output files, it appears that all corruption happens on 4KB boundaries. The first byte that differs is always at POS%4096 = 0. The last byte corrupt is always at (POS+1)%4096 = 0, or just at the end of the page. The range of the corruption usually ranges multiple pages, but it always starts and stops on page boundaries. The corrupted data are non-zero, or at least not all zero. They appear to be more or less random. I will try any suggestions people might have. I will try and reduce the size of the test, but running 16 cases of the test requires over 200 GB. Thanks, Craig From owner-linux-xfs@oss.sgi.com Wed Apr 21 13:56:33 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 21 Apr 2004 13:56:37 -0700 (PDT) Received: from ishtar.tlinx.org (ishtar.tlinx.org [64.81.58.33]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3LKuVKO029582 for ; Wed, 21 Apr 2004 13:56:33 -0700 Received: from tlinx.org (shiva [192.168.3.20]) by ishtar.tlinx.org (8.12.10/8.12.2/SuSE Linux 0.6) with ESMTP id i3LKuPwR008056 for ; Wed, 21 Apr 2004 13:56:26 -0700 Message-ID: <4086DFF9.9080807@tlinx.org> Date: Wed, 21 Apr 2004 13:56:25 -0700 From: lawalsh User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: mount problem 2.6.5 kernel Content-type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-archive-position: 2864 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: xfs@tlinx.org Precedence: bulk X-list: linux-xfs Content-Length: 1648 Lines: 38 I recently bought large disk (250Gb, previous largest was 150, all 1 xfs partition mk'ed with default params). mk'd this one with -i size=2048 and -b size=8192, got output: # mkfs.xfs -b size=8192 -i size=2048 -L Backups /dev/hdg1 meta-data=/dev/hdg1 isize=2048 agcount=59, agsize=524288 blks = sectsz=512 data = bsize=8192 blocks=30638963, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=8192 log =internal log bsize=8192 blocks=14960, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 --- but tried to mount: ishtar:var/log# mount /dev/hdg1 /mnt mount: Function not implemented ishtar:var/log# mount -t xfs /dev/hdg1 /mnt mount: Function not implemented --- if size=250 billion, then #blocks ~= 509 million (max). Not even close to value of unsigned or signed 32-bit block value, so that shouldn't be a factor; oops....seems to be xfs specific bug. I just remade partition with default params...oh, Hmmm....I thought linux page size was 8K (?). Shouldn't 8K block size also work? If that is the problem, any idea when xfs will be able to use block sizes > page size? If that isn't the problem, is this an edge case that isn't being checked correctly? Sorry for the bother....should have just stuck w/defaults, but seemed so wasteful since my average file size on my backup disk is 3.6 megabytes .... A 64K block size would likely be more efficient on such a disk...sigh. -l From owner-linux-xfs@oss.sgi.com Wed Apr 21 14:14:17 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 21 Apr 2004 14:14:22 -0700 (PDT) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3LLEHKO030553 for ; Wed, 21 Apr 2004 14:14:17 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id i3LLEAhv000521 for ; Wed, 21 Apr 2004 14:14:11 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA21100; Thu, 22 Apr 2004 07:14:06 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i3LLE57X445662; Thu, 22 Apr 2004 07:14:05 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i3LLE4Pi446897; Thu, 22 Apr 2004 07:14:04 +1000 (EST) Date: Thu, 22 Apr 2004 07:14:03 +1000 From: Nathan Scott To: lawalsh Cc: linux-xfs@oss.sgi.com Subject: Re: mount problem 2.6.5 kernel Message-ID: <20040422071403.C436928@wobbly.melbourne.sgi.com> References: <4086DFF9.9080807@tlinx.org> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4086DFF9.9080807@tlinx.org>; from xfs@tlinx.org on Wed, Apr 21, 2004 at 01:56:25PM -0700 Content-Transfer-Encoding: 8bit X-archive-position: 2865 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 867 Lines: 28 On Wed, Apr 21, 2004 at 01:56:25PM -0700, lawalsh wrote: > I recently bought large disk (250Gb, previous largest was 150, all > 1 xfs partition mk'ed with default params). mk'd this one with > -i size=2048 and -b size=8192, got output: > ... > a factor; oops....seems to be xfs specific bug. Blocksize cannot be larger than pagesize - the kernel is right to fail this mount request. > Hmmm....I thought linux page size was 8K (?). Shouldn't 8K block size also > work? Page size depends on your architecture - for i386, its 4k. > If that is the problem, any idea when xfs will be able to use block > sizes > page size? Not any time soon. AFAIK no Linux filesystems have implemented this -- there are assumptions scattered throughout the generic Linux file IO / page cache code that the blocksize will not be larger than the page size. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Apr 21 21:33:32 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 21 Apr 2004 21:33:36 -0700 (PDT) Received: from omx2.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3M4XVKO016687 for ; Wed, 21 Apr 2004 21:33:32 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with SMTP id i3M6eL0i027313 for ; Wed, 21 Apr 2004 23:40:31 -0700 Received: from bruce.melbourne.sgi.com (bruce.melbourne.sgi.com [134.14.54.176]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA29762 for ; Thu, 22 Apr 2004 14:32:54 +1000 Received: from bruce.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by bruce.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id i3M4UtAa012759 for ; Thu, 22 Apr 2004 14:31:13 +1000 Received: (from fsgqa@localhost) by bruce.melbourne.sgi.com (8.12.8/8.12.8/Submit) id i3M36d8W028006 for linux-xfs@oss.sgi.com; Thu, 22 Apr 2004 13:06:39 +1000 Date: Thu, 22 Apr 2004 13:06:39 +1000 From: FSG QA Message-Id: <200404220306.i3M36d8W028006@bruce.melbourne.sgi.com> Subject: TAKE 907752 - xfstests Apparently-To: X-archive-position: 2866 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: fsgqa@bruce.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 435 Lines: 17 QA test attempting to reproduce multiple directory entries problem. Date: Wed Apr 21 20:06:52 PDT 2004 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/xfs-cmds Inspected by: nathans@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:170477a xfstests/089 - 1.1 xfstests/089.out - 1.1 xfstests/src/t_mtab.c - 1.1 xfstests/group - 1.56 xfstests/src/Makefile - 1.24 From owner-linux-xfs@oss.sgi.com Wed Apr 21 21:44:23 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 21 Apr 2004 21:44:28 -0700 (PDT) Received: from omx1.americas.sgi.com (cfcafw.sgi.com [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3M4iNKO017252 for ; Wed, 21 Apr 2004 21:44:23 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i3M4ThGj004882 for ; Wed, 21 Apr 2004 23:29:44 -0500 Received: (from nathans@localhost) by chook.melbourne.sgi.com (8.11.6/8.11.6) id i3M3enS05968 for linux-xfs@oss.sgi.com; Thu, 22 Apr 2004 13:40:49 +1000 Date: Thu, 22 Apr 2004 13:40:49 +1000 From: Nathan Scott Message-Id: <200404220340.i3M3enS05968@chook.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 904196 - dmapi split patch X-archive-position: 2867 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@chook.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 337 Lines: 13 Recreate DMAPI split patch for 2.6 after Deans update. Date: Wed Apr 21 20:40:20 PDT 2004 Workarea: chook.melbourne.sgi.com:/build/nathans/2.6.x-xfs Inspected by: nathans@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: 2.6.x-xfs:linux:170479a split-patches/dmapi-enable - 1.2 From owner-linux-xfs@oss.sgi.com Thu Apr 22 01:54:50 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 22 Apr 2004 01:55:09 -0700 (PDT) Received: from alf.uib.no (npljm@alf.uib.no [129.177.30.3]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3M8r7KO028156 for linux-xfs@oss.sgi.com; Thu, 22 Apr 2004 01:53:39 -0700 Message-Id: <200404220853.i3M8r7KO028156@oss.sgi.com> Date: Thu, 22 Apr 2004 00:19:09 +0200 From: Jan-Frode Myklebust To: linux-xfs@oss.sgi.com Cc: tech@ii.uib.no Subject: Re: [RHSA-2004:166-01] Updated kernel packages resolve security X-archive-position: 2868 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: janfrode@parallab.uib.no Precedence: bulk X-list: linux-xfs Content-Length: 1388 Lines: 32 vulnerabilities Message-ID: <20040421221909.GA24076@ii.uib.no> References: <200404211516.i3LFG1l11857@lacrosse.corp.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200404211516.i3LFG1l11857@lacrosse.corp.redhat.com> Status: RO > - --------------------------------------------------------------------- > Red Hat Security Advisory > > Synopsis: Updated kernel packages resolve security vulnerabilities > Advisory ID: RHSA-2004:166-01 > Issue date: 2004-04-21 > Updated on: 2004-04-21 > Product: Red Hat Linux > Keywords: > Cross references: > Obsoletes: RHSA-2004:065 > CVE Names: CAN-2004-0003 CAN-2004-0109 CAN-2004-0177 > - --------------------------------------------------------------------- XFS-versions should shortly be available from: ftp://ftp.ii.uib.no/pub/janfrode/XFS/rh9 Will do the RedHat 7.x and 8.0 tomorrow.. -jf From owner-linux-xfs@oss.sgi.com Thu Apr 22 02:49:53 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 22 Apr 2004 02:50:04 -0700 (PDT) Received: from kraid.nerim.net (smtp-104-thursday.nerim.net [62.4.16.104]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3M9ngKO031657 for ; Thu, 22 Apr 2004 02:49:43 -0700 Received: from atc5.vermine.org (aym.net1.nerim.net [213.41.148.182]) by kraid.nerim.net (Postfix) with ESMTP id CCEF041B90 for ; Thu, 22 Apr 2004 11:40:32 +0200 (CEST) Received: from aym by atc5.vermine.org with local (Exim 3.36 #1 (Debian)) id 1BGah2-0000h6-00 for ; Thu, 22 Apr 2004 11:40:28 +0200 Date: Thu, 22 Apr 2004 11:40:27 +0200 From: Andre Majorel To: linux-xfs@oss.sgi.com Subject: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0) Message-ID: <20040422094027.GA1208@teaser.fr> Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.5.4i Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i3M9nrKO031659 X-archive-position: 2869 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: amajorel@teaser.fr Precedence: bulk X-list: linux-xfs Content-Length: 1088 Lines: 36 I have a PC running 2.4.26 and a 120GB XFS filesystem. When writing to the filesystem, I sometimes get __alloc_pages: 0-order allocation failed (gfp=0x1d2/0) # cat /proc/meminfo total: used: free: shared: buffers: cached: Mem: 63201280 61521920 1679360 0 126976 16670720 Swap: 148045824 7221248 140824576 MemTotal: 61720 kB MemFree: 1640 kB MemShared: 0 kB Buffers: 124 kB Cached: 15576 kB SwapCached: 704 kB Active: 1040 kB Inactive: 16220 kB HighTotal: 0 kB HighFree: 0 kB LowTotal: 61720 kB LowFree: 1640 kB SwapTotal: 144576 kB SwapFree: 137524 kB The kernel message does not seem to be related to a particular application; it happens with both tar over SSH and rsync. And, in the case of tar over SSH, the virtual size of both processes is quite reasonable (< 1MB). Note that this might not be an XFS issue; I've seen similar reports with other filesystems. -- André Majorel http://www.teaser.fr/~amajorel/ From owner-linux-xfs@oss.sgi.com Thu Apr 22 04:04:52 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 22 Apr 2004 04:04:59 -0700 (PDT) Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3MB4pKO001021 for ; Thu, 22 Apr 2004 04:04:52 -0700 Received: (qmail 15979 invoked by uid 65534); 22 Apr 2004 11:04:44 -0000 Received: from dialin-212-144-172-008.arcor-ip.net (EHLO server1.hasw.net) (212.144.172.8) by mail.gmx.net (mp004) with SMTP; 22 Apr 2004 13:04:44 +0200 X-Authenticated: #555161 Received: from hasw.net (hasw.hasw.net [192.168.0.10]) by server1.hasw.net (Postfix) with ESMTP id 113B03FAFF for ; Thu, 22 Apr 2004 15:00:47 +0200 (CEST) Message-ID: <4087A605.7090204@hasw.net> Date: Thu, 22 Apr 2004 13:01:25 +0200 From: Sebastian Witt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Problems with deleting directories Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2870 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: se.witt@gmx.net Precedence: bulk X-list: linux-xfs Content-Length: 231 Lines: 12 Hello, I'm running XFS with a 2.6.5 kernel. While trying to delete several directories with rm -rf I get "Directory not empty", but ls -la doesn't show a file. Also xfs_check doesn't help. What can this be? Regards, Sebastian From owner-linux-xfs@oss.sgi.com Thu Apr 22 04:27:21 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 22 Apr 2004 04:27:28 -0700 (PDT) Received: from smtp-out7.xs4all.nl (smtp-out7.xs4all.nl [194.109.24.8]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3MBRKKO005275 for ; Thu, 22 Apr 2004 04:27:21 -0700 Received: from auto-nb1.xs4all.nl (host-2.coltex.demon.nl [212.238.252.66]) (authenticated bits=0) by smtp-out7.xs4all.nl (8.12.10/8.12.10) with ESMTP id i3MBRIVc077473; Thu, 22 Apr 2004 13:27:19 +0200 (CEST) Message-Id: <4.3.2.7.2.20040422132656.02dc6880@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 22 Apr 2004 13:27:18 +0200 To: Andre Majorel , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0) In-Reply-To: <20040422094027.GA1208@teaser.fr> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2872 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: seth.mos@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 308 Lines: 11 At 11:40 22-4-2004 +0200, Andre Majorel wrote: >I have a PC running 2.4.26 and a 120GB XFS filesystem. When >writing to the filesystem, I sometimes get > > __alloc_pages: 0-order allocation failed (gfp=0x1d2/0) This is not a XFS problem. -- Seth I don't make sense, I don't pretend to either. Questions? From owner-linux-xfs@oss.sgi.com Thu Apr 22 04:41:25 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 22 Apr 2004 04:41:29 -0700 (PDT) Received: from phoenix.infradead.org (phoenix.infradead.org [213.86.99.234]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3MBfNKO006139 for ; Thu, 22 Apr 2004 04:41:24 -0700 Received: from hch by phoenix.infradead.org with local (Exim 4.30 #5 (Red Hat Linux)) id 1BGca1-0005HZ-TJ; Thu, 22 Apr 2004 12:41:21 +0100 Date: Thu, 22 Apr 2004 12:41:21 +0100 From: Christoph Hellwig To: Seth Mos Cc: Andre Majorel , linux-xfs@oss.sgi.com Subject: Re: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0) Message-ID: <20040422124121.A20239@infradead.org> References: <20040422094027.GA1208@teaser.fr> <4.3.2.7.2.20040422132656.02dc6880@pop.xs4all.nl> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <4.3.2.7.2.20040422132656.02dc6880@pop.xs4all.nl>; from seth.mos@xs4all.nl on Thu, Apr 22, 2004 at 01:27:18PM +0200 Content-Transfer-Encoding: 8bit X-archive-position: 2873 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 413 Lines: 12 On Thu, Apr 22, 2004 at 01:27:18PM +0200, Seth Mos wrote: > At 11:40 22-4-2004 +0200, Andre Majorel wrote: > >I have a PC running 2.4.26 and a 120GB XFS filesystem. When > >writing to the filesystem, I sometimes get > > > > __alloc_pages: 0-order allocation failed (gfp=0x1d2/0) > > This is not a XFS problem. It's not even a problem. It just means your out of memory and the page allocator returned NULL. From owner-linux-xfs@oss.sgi.com Thu Apr 22 05:43:18 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 22 Apr 2004 05:43:22 -0700 (PDT) Received: from mail.syd.swiftdsl.com.au (mail.syd.swiftdsl.com.au [202.154.83.58]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3MChHKO007562 for ; Thu, 22 Apr 2004 05:43:17 -0700 Received: (qmail 28168 invoked from network); 22 Apr 2004 12:43:18 -0000 Received: from unknown (HELO sithmachine.myempire) (218.214.21.72) by mail.syd.swiftdsl.com.au with SMTP; 22 Apr 2004 12:43:18 -0000 From: MichaelM To: linux-xfs@oss.sgi.com Subject: Re: Problems with deleting directories Date: Fri, 23 Apr 2004 08:43:28 +1000 User-Agent: KMail/1.6 References: <4087A605.7090204@hasw.net> In-Reply-To: <4087A605.7090204@hasw.net> MIME-Version: 1.0 Content-Disposition: inline Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-Id: <200404230843.28227.lordvader@swifdsl.com.au> X-archive-position: 2874 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lordvader@swifdsl.com.au.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 651 Lines: 18 I once had a similar problem. It wasn't due to the filesystem, but rather a filename got currupted, and ended up with a "/" in the name. "/" is an illegal character in filenames, so the file couldn't be deleted, renamed, nothing. I had to format the drive to remove the file. An "ls -la" did show the file however, but the other symptoms seem similar ...... On Thu, 22 Apr 2004 09:01 pm, you wrote: > Hello, > > I'm running XFS with a 2.6.5 kernel. While trying to delete > several directories with rm -rf I get "Directory not empty", but > ls -la doesn't show a file. > > Also xfs_check doesn't help. What can this be? > > Regards, > Sebastian From owner-linux-xfs@oss.sgi.com Thu Apr 22 07:17:14 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 22 Apr 2004 07:17:23 -0700 (PDT) Received: from atl-ms1.megatrends.com (mail2.megatrends.com [155.229.80.16]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3MEHEKO014704 for ; Thu, 22 Apr 2004 07:17:14 -0700 Received: by atl-ms1.megatrends.com with Internet Mail Service (5.5.2657.72) id <2LCC35QH>; Thu, 22 Apr 2004 10:17:34 -0400 Message-ID: <8CCBDD5583C50E4196F012E79439B45C04C9A3BB@atl-ms1.megatrends.com> From: Vinesh Christopher To: "'Sebastian Witt'" , linux-xfs@oss.sgi.com Subject: RE: Problems with deleting directories Date: Thu, 22 Apr 2004 10:17:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-Transfer-Encoding: 8bit X-archive-position: 2876 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: vineshc@ami.com Precedence: bulk X-list: linux-xfs Content-Length: 600 Lines: 24 What platform are you running on? I had the exact problem on Xscale platform. And the mailing list has a list of postings on this. Search for "Directory not empty" on the archives -----Original Message----- From: Sebastian Witt [mailto:se.witt@gmx.net] Sent: Thursday, April 22, 2004 7:01 AM To: linux-xfs@oss.sgi.com Subject: Problems with deleting directories Hello, I'm running XFS with a 2.6.5 kernel. While trying to delete several directories with rm -rf I get "Directory not empty", but ls -la doesn't show a file. Also xfs_check doesn't help. What can this be? Regards, Sebastian From owner-linux-xfs@oss.sgi.com Thu Apr 22 08:13:12 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 22 Apr 2004 08:13:16 -0700 (PDT) Received: from localhost.localdomain ([63.81.117.28]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3MFDBKO017252 for ; Thu, 22 Apr 2004 08:13:11 -0700 Received: from xfs.org (jen [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id i3MF5knS004758; Thu, 22 Apr 2004 10:05:47 -0500 Message-ID: <4087DF4A.1080007@xfs.org> Date: Thu, 22 Apr 2004 10:05:46 -0500 From: Steve Lord User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vinesh Christopher CC: "'Sebastian Witt'" , linux-xfs@oss.sgi.com Subject: Re: Problems with deleting directories References: <8CCBDD5583C50E4196F012E79439B45C04C9A3BB@atl-ms1.megatrends.com> In-Reply-To: <8CCBDD5583C50E4196F012E79439B45C04C9A3BB@atl-ms1.megatrends.com> Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2877 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 516 Lines: 18 Vinesh Christopher wrote: > What platform are you running on? > I had the exact problem on Xscale platform. > And the mailing list has a list of postings > on this. > Search for "Directory not empty" on the archives > Vinesh, The xscale issue seemed to be compiler related, I suggested alternate code, but I never heard back. Do you know if there was a resolution which did not make it onto the list? The code change proposed by the xscale folks was not correct even though it made the issue go away. Steve From owner-linux-xfs@oss.sgi.com Thu Apr 22 08:51:49 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 22 Apr 2004 08:51:52 -0700 (PDT) Received: from localhost.localdomain ([63.81.117.28]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3MFpmKO022436 for ; Thu, 22 Apr 2004 08:51:48 -0700 Received: from xfs.org (jen [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id i3MFjtnS005176; Thu, 22 Apr 2004 10:45:56 -0500 Message-ID: <4087E8B3.1070507@xfs.org> Date: Thu, 22 Apr 2004 10:45:55 -0500 From: Steve Lord User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vinesh Christopher CC: "'Sebastian Witt'" , linux-xfs@oss.sgi.com Subject: Re: Problems with deleting directories References: <8CCBDD5583C50E4196F012E79439B45C04C9A3BC@atl-ms1.megatrends.com> In-Reply-To: <8CCBDD5583C50E4196F012E79439B45C04C9A3BC@atl-ms1.megatrends.com> Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2878 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 1420 Lines: 51 Vinesh Christopher wrote: > Which alternate code? > > I am currently using the "xscale folks" code which > Works fine for me. There was a patch floating around, you sent me a copy, I do not have it handy. I responded on 3/11/04 with some suggestions about changing the old code to be more compiler friendly. I stress, the code in the tree is correct. I think the patch originated with Greg Ungerer from what I can see via google. If you are using the patch Nathan sent out here: http://oss.sgi.com/archives/linux-xfs/2004-03/msg00193.html Then it should be OK. I have no idea what the current "xscale folks" code does. Steve > > -----Original Message----- > From: Steve Lord [mailto:lord@xfs.org] > Sent: Thursday, April 22, 2004 11:06 AM > To: Vinesh Christopher > Cc: 'Sebastian Witt'; linux-xfs@oss.sgi.com > Subject: Re: Problems with deleting directories > > Vinesh Christopher wrote: > >>What platform are you running on? >>I had the exact problem on Xscale platform. >>And the mailing list has a list of postings >>on this. >>Search for "Directory not empty" on the archives >> > > > Vinesh, > > The xscale issue seemed to be compiler related, I suggested > alternate code, but I never heard back. Do you know if > there was a resolution which did not make it onto the > list? The code change proposed by the xscale folks was > not correct even though it made the issue go away. > > Steve > From owner-linux-xfs@oss.sgi.com Thu Apr 22 09:36:05 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 22 Apr 2004 09:36:10 -0700 (PDT) Received: from mwinf0904.wanadoo.fr (smtp9.wanadoo.fr [193.252.22.22]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3MGZsKO024288 for ; Thu, 22 Apr 2004 09:35:54 -0700 Received: from wwinf0902 (wwinf0902 [172.22.140.29]) by mwinf0904.wanadoo.fr (SMTP Server) with ESMTP id 3C43318003FF for ; Thu, 22 Apr 2004 18:03:55 +0200 (CEST) Message-ID: <15677929.1082649835233.JavaMail.www@wwinf0902> From: Messagerie temporaire Delmas Reply-To: delmas.temp@wanadoo.fr To: linux-xfs@oss.sgi.com Subject: CVS XFS version vs kernel.org's kernel source one Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Thu, 22 Apr 2004 18:03:55 +0200 (CEST) X-archive-position: 2879 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: delmas.temp@wanadoo.fr Precedence: bulk X-list: linux-xfs Content-Length: 1252 Lines: 26 Hello, At our company we've got a problem with XFS and NFS on the fileserver. The problem seems to be like one describe in bug report 309 (http://oss.sgi.com/bugzilla/show_bug.cgi?id=309) and which seems to be resolved by a temporary fix in the patch 108 (http://oss.sgi.com/bugzilla/attachment.cgi?id=108). First of all is there a more "official" patch which resolves this bug? My second question is that why XFS module in the kernel source found on kernel.org is part of the linux-2.6.x-OLD CVS tree? I saw that when I looked to the patch 108 and a file concerned by it (xfs_iget.c). The patch replace a line by another one (make_bad_inode(inode); is replaced by remove_inode_hash(inode);). This patch applies well on kernel.org kernel sources. But when I looked at this file (xfs_iget.c) in the CVS tree, I saw that it contains both lines. So my question is what is CVS tree version? the file xfs_iget.c wasn't modified recently but it isn't part of "official" kernel.org sources, why new linux-xfs (I notice that it's a new one resulting from linux 2.4 and linux 2.6 merging in january 2004) hasn't been merged into recent kernel sources? I hope you'll understand my message, my english is very poor. Thank you Cedric From owner-linux-xfs@oss.sgi.com Thu Apr 22 10:34:22 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 22 Apr 2004 10:34:28 -0700 (PDT) Received: from atl-ms1.megatrends.com (mail2.megatrends.com [155.229.80.16]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3MHYLKO025574 for ; Thu, 22 Apr 2004 10:34:21 -0700 Received: by atl-ms1.megatrends.com with Internet Mail Service (5.5.2657.72) id <2LCC39NT>; Thu, 22 Apr 2004 13:34:39 -0400 Message-ID: <8CCBDD5583C50E4196F012E79439B45C04C9A3BD@atl-ms1.megatrends.com> From: Vinesh Christopher To: "'Steve Lord'" Cc: "'Sebastian Witt'" , linux-xfs@oss.sgi.com Subject: RE: Problems with deleting directories Date: Thu, 22 Apr 2004 13:34:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-Transfer-Encoding: 8bit X-archive-position: 2880 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: vineshc@ami.com Precedence: bulk X-list: linux-xfs Content-Length: 1980 Lines: 72 The patch Nathan send did not work. It computed the same values as the original code Attached is the "xscale folks" code patch originated from Greg Ungreger which solves the problem. Sebastin, Can you try this patch -----Original Message----- From: Steve Lord [mailto:lord@xfs.org] Sent: Thursday, April 22, 2004 11:46 AM To: Vinesh Christopher Cc: 'Sebastian Witt'; linux-xfs@oss.sgi.com Subject: Re: Problems with deleting directories Vinesh Christopher wrote: > Which alternate code? > > I am currently using the "xscale folks" code which > Works fine for me. There was a patch floating around, you sent me a copy, I do not have it handy. I responded on 3/11/04 with some suggestions about changing the old code to be more compiler friendly. I stress, the code in the tree is correct. I think the patch originated with Greg Ungerer from what I can see via google. If you are using the patch Nathan sent out here: http://oss.sgi.com/archives/linux-xfs/2004-03/msg00193.html Then it should be OK. I have no idea what the current "xscale folks" code does. Steve > > -----Original Message----- > From: Steve Lord [mailto:lord@xfs.org] > Sent: Thursday, April 22, 2004 11:06 AM > To: Vinesh Christopher > Cc: 'Sebastian Witt'; linux-xfs@oss.sgi.com > Subject: Re: Problems with deleting directories > > Vinesh Christopher wrote: > >>What platform are you running on? >>I had the exact problem on Xscale platform. >>And the mailing list has a list of postings >>on this. >>Search for "Directory not empty" on the archives >> > > > Vinesh, > > The xscale issue seemed to be compiler related, I suggested > alternate code, but I never heard back. Do you know if > there was a resolution which did not make it onto the > list? The code change proposed by the xscale folks was > not correct even though it made the issue go away. > > Steve > -- Binary/unsupported file stripped by Ecartis -- -- Type: application/octet-stream -- File: xfs-20040217.patch From owner-linux-xfs@oss.sgi.com Thu Apr 22 11:38:48 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 22 Apr 2004 11:38:52 -0700 (PDT) Received: from zero.aec.at (Phela_Orm@zero.aec.at [193.170.194.10]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3MIckKO027222 for ; Thu, 22 Apr 2004 11:38:47 -0700 Received: from averell.firstfloor.org.muc.de (Henry_Ward_Beecher@localhost.localdomain [127.0.0.1]) by zero.aec.at (8.11.6/8.11.2) with ESMTP id i3MIcRD20950; Thu, 22 Apr 2004 20:38:28 +0200 To: Steve Lord cc: linux-xfs@oss.sgi.com, vineshc@ami.com Subject: Re: Problems with deleting directories References: <8CCBDD5583C50E4196F012E79439B45C04C9A3BB@atl-ms1.megatrends.com> <4087DF4A.1080007@xfs.org> From: Andi Kleen Date: Thu, 22 Apr 2004 20:38:26 +0200 In-Reply-To: <4087DF4A.1080007@xfs.org> (Steve Lord's message of "Thu, 22 Apr 2004 10:05:46 -0500") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2881 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@muc.de Precedence: bulk X-list: linux-xfs Content-Length: 542 Lines: 15 Steve Lord writes: > > The xscale issue seemed to be compiler related, I suggested > alternate code, but I never heard back. Do you know if > there was a resolution which did not make it onto the > list? The code change proposed by the xscale folks was > not correct even though it made the issue go away. As a generic comment a good way to stop the compiler from miscompiling something is to move part of the problematic expression into a separate function declared "noinline" (or __attribute__((noinline)) in 2.4) -Andi From owner-linux-xfs@oss.sgi.com Thu Apr 22 12:07:07 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 22 Apr 2004 12:07:12 -0700 (PDT) Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3MJ74KO028252 for ; Thu, 22 Apr 2004 12:07:06 -0700 Received: (qmail 29006 invoked by uid 0); 22 Apr 2004 19:06:58 -0000 Received: from 213.54.141.102 by www5.gmx.net with HTTP; Thu, 22 Apr 2004 21:06:58 +0200 (MEST) Date: Thu, 22 Apr 2004 21:06:58 +0200 (MEST) From: "Sebastian Witt" To: Vinesh Christopher Cc: linux-xfs@oss.sgi.com MIME-Version: 1.0 References: <8CCBDD5583C50E4196F012E79439B45C04C9A3BB@atl-ms1.megatrends.com> Subject: RE: Problems with deleting directories X-Priority: 3 (Normal) X-Authenticated: #555161 Message-ID: <19628.1082660818@www5.gmx.net> X-Mailer: WWW-Mail 1.6 (Global Message Exchange) X-Flags: 0001 Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2882 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: se.witt@gmx.net Precedence: bulk X-list: linux-xfs Content-Length: 581 Lines: 20 > What platform are you running on? > I had the exact problem on Xscale platform. > And the mailing list has a list of postings > on this. > Search for "Directory not empty" on the archives i386 SMP. This is no file with a "/" char, it is a normal directory. I've recognized another issue: Most tar-Archives and other files >1MB on this partition are "corrupt"... but only if I use 2.6.5. If I switch back to 2.6.1 I can delete the directories and the files are read correctly. -- NEU : GMX Internet.FreeDSL Ab sofort DSL-Tarif ohne Grundgebühr: http://www.gmx.net/dsl From owner-linux-xfs@oss.sgi.com Thu Apr 22 13:36:24 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 22 Apr 2004 13:36:28 -0700 (PDT) Received: from ishtar.tlinx.org (dsl081-245-074.sfo1.dsl.speakeasy.net [64.81.245.74]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3MKaLKO001248 for ; Thu, 22 Apr 2004 13:36:24 -0700 Received: from tlinx.org (shiva [192.168.3.20]) by ishtar.tlinx.org (8.12.10/8.12.2/SuSE Linux 0.6) with ESMTP id i3MKaKwR026253 for ; Thu, 22 Apr 2004 13:36:21 -0700 Message-ID: <40882CC4.6050505@tlinx.org> Date: Thu, 22 Apr 2004 13:36:20 -0700 From: lawalsh User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: mount problem 2.6.5 kernel References: <4086DFF9.9080807@tlinx.org> <20040422071403.C436928@wobbly.melbourne.sgi.com> In-Reply-To: <20040422071403.C436928@wobbly.melbourne.sgi.com> Content-type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-archive-position: 2883 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: xfs@tlinx.org Precedence: bulk X-list: linux-xfs Content-Length: 1106 Lines: 37 Nathan Scott wrote: >On Wed, Apr 21, 2004 at 01:56:25PM -0700, lawalsh wrote: > > >>I recently bought large disk (250Gb, previous largest was 150, all >>1 xfs partition mk'ed with default params). mk'd this one with >>-i size=2048 and -b size=8192, got output: >>... >>a factor; oops....seems to be xfs specific bug. >> >> > >Blocksize cannot be larger than pagesize - the kernel is right >to fail this mount request. > > --- For those of us losing or gaining a bit in pagesize now and then, perhaps it would be good for mkfs.xfs to either deny create or warn on creating fs's on the system architecture it is being created on? How often does one create a fs under linux that they can't copy anything onto -- just mkfs it, then move the filesystem to another architecture where it is supported? I'd be tempted to add an "-ff" switch to mkfs to really force creating a file system that will be unusable on the system creating it. Besides there's always the slight chance one could see it mentioned on slashdot with the tagline "get your on...." :=) -l From owner-linux-xfs@oss.sgi.com Thu Apr 22 14:49:53 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 22 Apr 2004 14:49:57 -0700 (PDT) Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3MLnqKO004226 for ; Thu, 22 Apr 2004 14:49:52 -0700 Received: (qmail 32354 invoked by uid 65534); 22 Apr 2004 21:49:45 -0000 Received: from dialin-212-144-180-115.arcor-ip.net (EHLO server1.hasw.net) (212.144.180.115) by mail.gmx.net (mp005) with SMTP; 22 Apr 2004 23:49:45 +0200 X-Authenticated: #555161 Received: from hasw.net (hasw.hasw.net [192.168.0.10]) by server1.hasw.net (Postfix) with ESMTP id ADAB73EAFC for ; Fri, 23 Apr 2004 01:47:00 +0200 (CEST) Message-ID: <40883DA1.6070303@hasw.net> Date: Thu, 22 Apr 2004 23:48:17 +0200 From: Sebastian Witt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: Problems with deleting directories Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 2884 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: se.witt@gmx.net Precedence: bulk X-list: linux-xfs Content-Length: 3112 Lines: 107 Eric Sandeen wrote: > Ok, thanks. Any errors in the logs, or error output from tar? > have you tried xfs_repair on the disk (it checks differently than > xfs_check does...) No errors in the logs. Here a example what happens on 2.6.1, 2.6.2, 2.6.5 and 2.6.6-rc2: 2.6.1: ------- root@server3:/var/ftp/linux# tar -tzf lsof_4.69.tar.gz lsof_4.69/ lsof_4.69/lsof_4.69_src.tar lsof_4.69/README.lsof_4.69 lsof_4.69/lsof_4.69_src.tar.asc lsof_4.69/00.README.FIRST_4.69 lsof_4.69/RELEASE.SUMMARY_4.69 ------- Ok, now with 2.6.2, 2.6.5 or 2.6.6-rc2: ------- root@server3:/var/ftp/linux# tar -tzf lsof_4.69.tar.gz lsof_4.69/ lsof_4.69/lsof_4.69_src.tar tar: Skipping to next header gzip: stdin: invalid compressed data--crc error tar: Child returned status 1 tar: Error exit delayed from previous errors ------- Not working anymore. I can try this with different archives or files, but not all are "corrupt". I'm using a MD5-database to check the integrity of all files on this partition. There are no changed files when I test 2087 files, but when I ran this check on >2.6.1 it reports 981 have "changed". On 2.6.2, 2.6.5 and 2.6.6-rc2 it reports the same files as changed. Here is the xfs_repair (run with 2.6.1) log: ------- Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... zero_log: head block 13285 tail block 13285 - 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 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - 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) ... - clearing existing "lost+found" inode - deleting existing "lost+found" entry - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... done --------- Bye, Sebastian From owner-linux-xfs@oss.sgi.com Thu Apr 22 16:25:29 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 22 Apr 2004 16:25:33 -0700 (PDT) Received: from zok.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3MNPRKO008943 for ; Thu, 22 Apr 2004 16:25:27 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id i3MNMBhv003238 for ; Thu, 22 Apr 2004 16:22:12 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA21883; Fri, 23 Apr 2004 09:22:06 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i3MNM47X478884; Fri, 23 Apr 2004 09:22:04 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i3MNM1nC479145; Fri, 23 Apr 2004 09:22:01 +1000 (EST) Date: Fri, 23 Apr 2004 09:22:01 +1000 From: Nathan Scott To: lawalsh Cc: linux-xfs@oss.sgi.com Subject: Re: mount problem 2.6.5 kernel Message-ID: <20040423092201.A458023@wobbly.melbourne.sgi.com> References: <4086DFF9.9080807@tlinx.org> <20040422071403.C436928@wobbly.melbourne.sgi.com> <40882CC4.6050505@tlinx.org> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <40882CC4.6050505@tlinx.org>; from xfs@tlinx.org on Thu, Apr 22, 2004 at 01:36:20PM -0700 Content-Transfer-Encoding: 8bit X-archive-position: 2885 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1000 Lines: 27 On Thu, Apr 22, 2004 at 01:36:20PM -0700, lawalsh wrote: > > > >Blocksize cannot be larger than pagesize - the kernel is right > >to fail this mount request. > > > For those of us losing or gaining a bit in pagesize now and then, > perhaps it would be good for mkfs.xfs to either deny create or warn > on creating fs's on the system architecture it is being created on? > > How often does one create a fs under linux that they can't copy > anything onto -- just mkfs it, then move the filesystem to another > architecture where it is supported? > > I'd be tempted to add an "-ff" switch to mkfs to really force creating > a file system that will be unusable on the system creating it. well, thats tricky on ia64 right? (where pagesize is configurable). I guess people just need to know to read dmesg when mount fails; not much more we can really do from an xfs point of view. as long as we're putting a sensible message there that explains the issue, we should be ok. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Apr 22 19:07:17 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 22 Apr 2004 19:07:22 -0700 (PDT) Received: from zok.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3N27HKO011766 for ; Thu, 22 Apr 2004 19:07:17 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id i3N22Ahv001912 for ; Thu, 22 Apr 2004 19:02:10 -0700 Received: from bruce.melbourne.sgi.com (bruce.melbourne.sgi.com [134.14.54.176]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA25249 for ; Fri, 23 Apr 2004 12:02:08 +1000 Received: from bruce.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by bruce.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id i3N20QNi022549 for ; Fri, 23 Apr 2004 12:00:26 +1000 Received: (from fsgqa@localhost) by bruce.melbourne.sgi.com (8.12.8/8.12.8/Submit) id i3N20Qii022548 for linux-xfs@oss.sgi.com; Fri, 23 Apr 2004 12:00:26 +1000 Date: Fri, 23 Apr 2004 12:00:26 +1000 From: FSG QA Message-Id: <200404230200.i3N20Qii022548@bruce.melbourne.sgi.com> Subject: TAKE 907752 - xfstests Apparently-To: X-archive-position: 2886 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: fsgqa@bruce.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 421 Lines: 16 Exercise mtab renames on different directory layouts too, and increase #processes. Still no joy though, so far. Date: Thu Apr 22 19:00:52 PDT 2004 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/xfs-cmds Inspected by: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:170527a xfstests/089 - 1.2 xfstests/089.out - 1.2 xfstests/src/t_mtab.c - 1.2 From owner-linux-xfs@oss.sgi.com Thu Apr 22 20:13:28 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 22 Apr 2004 20:13:33 -0700 (PDT) Received: from zok.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3N3DSKO013448 for ; Thu, 22 Apr 2004 20:13:28 -0700 Received: from spindle.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i3N3BVhv031659 for ; Thu, 22 Apr 2004 20:11:31 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by spindle.corp.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id i3N3BTO314392963 for ; Thu, 22 Apr 2004 20:11:30 -0700 (PDT) Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i3MCo8Ke37382372; Thu, 22 Apr 2004 07:50:08 -0500 (CDT) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1BGdea-0005pQ-00; Thu, 22 Apr 2004 07:50:08 -0500 To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: TAKE 913176 - close external blockdevice after final flush Message-Id: From: Christoph Hellwig Date: Thu, 22 Apr 2004 07:50:08 -0500 X-archive-position: 2887 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1155 Lines: 46 Date: Thu Apr 22 05:49:48 PDT 2004 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-2.4.x Inspected by: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: xfs-linux:xfs-kern:170489a fs/xfs/xfs_vfsops.c - 1.449 - s/pagebuf_delwri_flush/xfs_flush_buftarg/g fs/xfs/xfs_mount.c - 1.342 - simplify xfs_unmountfs_close thanks to the changed xfs_free_buftarg fs/xfs/linux-2.6/xfs_linux.h - 1.122 - include blkdev.h fs/xfs/linux-2.6/xfs_super.h - 1.57 - move buftarg handling from here fs/xfs/linux-2.6/xfs_super.c - 1.301 - move buftarg handling from here fs/xfs/linux-2.4/xfs_linux.h - 1.132 - include blkdev.h fs/xfs/linux-2.4/xfs_super.h - 1.62 - move buftarg handling from here fs/xfs/linux-2.4/xfs_super.c - 1.286 - move buftarg handling from here fs/xfs/linux-2.6/xfs_buf.h - 1.97 - move buftarg handling here fs/xfs/linux-2.6/xfs_buf.c - 1.165 - move buftarg handling here, close blockevice after flush fs/xfs/linux-2.4/xfs_buf.h - 1.102 - move buftarg handling here fs/xfs/linux-2.4/xfs_buf.c - 1.185 - move buftarg handling here, close blockevice after flush From owner-linux-xfs@oss.sgi.com Thu Apr 22 20:25:27 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 22 Apr 2004 20:25:31 -0700 (PDT) Received: from zok.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3N3PQKO017139 for ; Thu, 22 Apr 2004 20:25:27 -0700 Received: from spindle.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i3N3BUhv031614 for ; Thu, 22 Apr 2004 20:11:30 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by spindle.corp.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id i3N3BTNx14392963 for ; Thu, 22 Apr 2004 20:11:29 -0700 (PDT) Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i3MJGUKe37532549; Thu, 22 Apr 2004 14:16:30 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i3MJGUHO383171; Thu, 22 Apr 2004 14:16:30 -0500 (CDT) Subject: RE: Problems with deleting directories From: Eric Sandeen To: Sebastian Witt Cc: linux-xfs@oss.sgi.com In-Reply-To: <19628.1082660818@www5.gmx.net> References: <8CCBDD5583C50E4196F012E79439B45C04C9A3BB@atl-ms1.megatrends.com> <19628.1082660818@www5.gmx.net> Content-Type: text/plain Organization: Eric Conspiracy Secret Labs Message-Id: <1082661389.21196.18.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 22 Apr 2004 14:16:30 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 2888 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 587 Lines: 20 On Thu, 2004-04-22 at 14:06, Sebastian Witt wrote: > i386 SMP. This is no file with a "/" char, it is a normal directory. > > I've recognized another issue: Most tar-Archives and other files >1MB on > this partition are "corrupt"... but only if I use 2.6.5. > > If I switch back to 2.6.1 I can delete the directories and the files are > read correctly. Hm, corrupt how? Can you find out where in between 2.6.1 and 2.6.5 this stopped working? Thanks, -Eric -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Fri Apr 23 00:13:21 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 23 Apr 2004 00:13:39 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i3N7DLKO021995 for ; Fri, 23 Apr 2004 00:13:21 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i3N7DLRM021992 for linux-xfs@oss.sgi.com; Fri, 23 Apr 2004 00:13:21 -0700 Received: from quasar.sif.it (IDENT:root@quasar.sif.it [131.154.110.3]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3N7DDKO021977; Fri, 23 Apr 2004 00:13:14 -0700 Received: from astra.sif.it (IDENT:matteo@astra.sif.it [131.154.110.1]) by quasar.sif.it (8.12.9/SQL-8.12.9-5/8.12.9) with ESMTP id i3N7D7aY003745; Fri, 23 Apr 2004 09:13:07 +0200 Date: Fri, 23 Apr 2004 09:13:06 +0200 (CEST) From: Matteo Centonza To: Eric Sandeen cc: Chris Wedgwood , , Subject: Re: [Bug 324] New: oops with xfs_fsr on 2.6.5-1.326 In-Reply-To: <1082560958.15446.1.camel@stout.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2889 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: matteo@sif.it Precedence: bulk X-list: linux-xfs Content-Length: 1455 Lines: 38 > > i haven't my laptop handy but seems not the case since RH backed it out > > starting from 2.6.5-1.309. > > it seems to be in as of 1.332.... right: apollinaire [11:29am] (1.10) /usr/src> grep -r 4KSTACKS linux-2.6. linux-2.6.3-2.1.253.2.1 linux-2.6.5-1.326 apollinaire [11:29am] (1.10) /usr/src> grep -r 4KSTACKS linux-2.6.* linux-2.6.3-2.1.253.2.1/arch/i386/Kconfig:config 4KSTACKS linux-2.6.3-2.1.253.2.1/arch/i386/kernel/irq.c:#ifdef CONFIG_4KSTACKS linux-2.6.3-2.1.253.2.1/arch/i386/kernel/irq.c:#ifdef CONFIG_4KSTACKS linux-2.6.3-2.1.253.2.1/configs/kernel-2.6.3-i586-smp.config:CONFIG_4KSTACKS=y linux-2.6.3-2.1.253.2.1/configs/kernel-2.6.3-i586.config:CONFIG_4KSTACKS=y linux-2.6.3-2.1.253.2.1/configs/kernel-2.6.3-i686-smp.config:CONFIG_4KSTACKS=y linux-2.6.3-2.1.253.2.1/configs/kernel-2.6.3-i686.config:CONFIG_4KSTACKS=y linux-2.6.3-2.1.253.2.1/include/asm-i386/thread_info.h:#ifdef CONFIG_4KSTACKS linux-2.6.3-2.1.253.2.1/include/asm-i386/irq.h:#ifdef CONFIG_4KSTACKS linux-2.6.3-2.1.253.2.1/include/asm-i386/module.h:#ifdef CONFIG_4KSTACKS linux-2.6.3-2.1.253.2.1/include/asm-i386/module.h:#define MODULE_STACKSIZE "4KST ACKS " linux-2.6.5-1.326/include/asm-i386/processor.h:#ifdef CONFIG_4KSTACKS linux-2.6.5-1.326/include/asm-i386/module.h:#define MODULE_STACKSIZE "4KSTACKS " RH stripped off the config option merging in the relative changes. I'll revert the linux-2.6.5-nostack.patch, recompile and let you know. -m From owner-linux-xfs@oss.sgi.com Fri Apr 23 03:35:37 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 23 Apr 2004 03:35:41 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i3NAZbKO032186 for ; Fri, 23 Apr 2004 03:35:37 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i3NAZbZv032185 for linux-xfs@oss.sgi.com; Fri, 23 Apr 2004 03:35:37 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i3NAZZKQ032169 for ; Fri, 23 Apr 2004 03:35:35 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i3N9j9Gg030815; Fri, 23 Apr 2004 02:45:09 -0700 Date: Fri, 23 Apr 2004 02:45:09 -0700 Message-Id: <200404230945.i3N9j9Gg030815@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 311] ioctl hang in 2.6.x kernels with quota support X-Bugzilla-Reason: AssignedTo X-archive-position: 2891 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1233 Lines: 34 http://oss.sgi.com/bugzilla/show_bug.cgi?id=311 robin.rosenberg@dewire.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |robin.rosenberg@dewire.com ------- Additional Comments From robin.rosenberg@dewire.com 2004-23-04 02:45 PDT ------- I'm running 2.6.3 (2.6.3-7mdk to be exact), I'm not "using" quotas (although they are enabled in the kernel) and got xfs_fsr to hang. KMail also hung, but not at the same time. They also (AFAICS) were working on different partitions. I then ran xfs_repair on / and it discovered errors which it repaired. None of the other partitions had any errors. Whether these errors were there before or is a result of xfs_fsr hanging I do not know. There was little load on the system at the time and I have run xfs_fsr many times with the same kernel and also under more load and the system had not crashed since the previous successful defragmentation attempt. Don't know if this helps, if not please ignore it. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Fri Apr 23 09:42:32 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 23 Apr 2004 09:42:35 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i3NGgWKO018559 for ; Fri, 23 Apr 2004 09:42:32 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i3NGgVxC018558 for linux-xfs@oss.sgi.com; Fri, 23 Apr 2004 09:42:31 -0700 Received: from io.goeci.com (IO.goeci.com [66.28.220.99]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3NGgIKO018538; Fri, 23 Apr 2004 09:42:18 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Bug 324] New: oops with xfs_fsr on 2.6.5-1.326 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Fri, 23 Apr 2004 12:32:24 -0400 Message-ID: <3554BFA5FAE4B14FB5459D36E4F4E36203D977@io.goeci.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Bug 324] New: oops with xfs_fsr on 2.6.5-1.326 thread-index: AcQnS7vCLrH9CYLAQeeGg0l9ODiA+wB7bB5QAAXEi/A= From: "Murthy Kambhampaty" To: "Chris Wedgwood" , Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i3NGgIKO018538 X-archive-position: 2892 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: murthy.kambhampaty@goeci.com Precedence: bulk X-list: linux-xfs Content-Length: 1233 Lines: 34 Sorry for the noise; I googled this issue some more and found a patch to arch/i386/Kconfig. Recompiling seems to have solved the problem. Thanks. Murthy > -----Original Message----- > From: Murthy Kambhampaty > Sent: Friday, April 23, 2004 10:11 AM > To: 'Chris Wedgwood'; 'bugzilla-daemon@oss.sgi.com' > Cc: 'xfs-master@oss.sgi.com' > Subject: RE: [Bug 324] New: oops with xfs_fsr on 2.6.5-1.326 > > > I should have mentioned that these systems all run RedHat 8.0 ... > > Chris Wedgwood writes: > > Please see recompile without CONFIG_4KSTACKS and retry. > > Is this just a matter of commenting out "CONFIG_4KSTACKS=y" > after running "make menuconfig", and then compiling and > installing the kernel and modules? > > I'd like to try this to see if it solves my kernel oopses: > I have been running 2.6.x series kernels successfully on a > 440BX SMP box with IDE only, no highmem. However, on highmem > SMP boxes with SCSI raid (sw and hw), I get kernel oopses > under heavy load. (Poking around the docs, I found the > default AS scheduler is not recommended for SCSI raid setups, > the deadline scheduler is. I'll try that separately, but > that seems unlikely to be the culprit?) > > Thanks, > Murthy > From owner-linux-xfs@oss.sgi.com Fri Apr 23 10:16:33 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 23 Apr 2004 10:16:37 -0700 (PDT) Received: from omx1.americas.sgi.com (cfcafw.sgi.com [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3NHGWKO019789 for ; Fri, 23 Apr 2004 10:16:33 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i3NH9SBN021107 for ; Fri, 23 Apr 2004 12:09:28 -0500 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i3NH9RKe37514042; Fri, 23 Apr 2004 12:09:27 -0500 (CDT) Received: from naboo.americas.sgi.com (naboo.americas.sgi.com [128.162.233.73]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i3NH9RXa4776594; Fri, 23 Apr 2004 12:09:27 -0500 (CDT) Received: by naboo.americas.sgi.com (Postfix, from userid 29039) id 59C498C8716; Fri, 23 Apr 2004 12:09:27 -0500 (CDT) To: sgi.bugs.xvm@engr.sgi.com, linux-xfs@engr.sgi.com, slinx-xfs@engr.sgi.com, linux-xfs@oss.sgi.com Subject: PARTIAL TAKE 913451 - Add wait to call_usermodehelper Message-Id: <20040423170927.59C498C8716@naboo.americas.sgi.com> Date: Fri, 23 Apr 2004 12:09:27 -0500 (CDT) From: cattelan@sgi.com (Russell Cattelan) X-archive-position: 2893 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 377 Lines: 15 Date: Fri Apr 23 10:08:21 PDT 2004 Workarea: naboo.americas.sgi.com:/go/space/XFS/2.4.x-xfs Inspected by: hch@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: 2.4.x-xfs:linux:170559a include/linux/kmod.h - 1.2 kernel/kmod.c - 1.2 - Add wait functionality to call_usermodehelp backport from 2.6 by Marcel Holtmann From owner-linux-xfs@oss.sgi.com Fri Apr 23 11:19:38 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 23 Apr 2004 11:19:41 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i3NIJcKO021998 for ; Fri, 23 Apr 2004 11:19:38 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i3NIJc9G021997 for linux-xfs@oss.sgi.com; Fri, 23 Apr 2004 11:19:38 -0700 Received: from dingdong.cryptoapps.com (uslink-66.173.43-129.uslink.net [66.173.43.129] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3NIJXKO021981; Fri, 23 Apr 2004 11:19:33 -0700 Received: by dingdong.cryptoapps.com (Postfix, from userid 1001) id D579FFB837; Fri, 23 Apr 2004 13:19:19 -0500 (CDT) Date: Fri, 23 Apr 2004 11:19:19 -0700 From: Chris Wedgwood To: Murthy Kambhampaty Cc: bugzilla-daemon@oss.sgi.com, xfs-master@oss.sgi.com Subject: Re: [Bug 324] New: oops with xfs_fsr on 2.6.5-1.326 Message-ID: <20040423181919.GC6470@dingdong.cryptoapps.com> References: <3554BFA5FAE4B14FB5459D36E4F4E36203D977@io.goeci.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3554BFA5FAE4B14FB5459D36E4F4E36203D977@io.goeci.com> X-archive-position: 2895 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 392 Lines: 13 On Fri, Apr 23, 2004 at 12:32:24PM -0400, Murthy Kambhampaty wrote: > Sorry for the noise; I googled this issue some more and found a > patch to arch/i386/Kconfig. Recompiling seems to have solved the > problem. Thanks. No patch required. make config, make menuconfig, etc. will all let you turn this option off. Or edit it out and do make oldconfig. Whatever works for you. --cw From owner-linux-xfs@oss.sgi.com Fri Apr 23 12:24:25 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 23 Apr 2004 12:24:32 -0700 (PDT) Received: from mail.mnsu.edu (Mail.MNSU.EDU [134.29.1.12]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3NJOPKO029754 for ; Fri, 23 Apr 2004 12:24:25 -0700 Received: from mnsu.edu (j3gum-3.ITS.MNSU.EDU [134.29.32.1]) by mail.mnsu.edu (8.12.10/8.12.10) with ESMTP id i3NJOJLP024833 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 23 Apr 2004 14:24:19 -0500 Message-ID: <40896D63.9030606@mnsu.edu> Date: Fri, 23 Apr 2004 14:24:19 -0500 From: "Jeffrey E. Hundstad" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: How to patch linux-2.6.5 with the current version of xfs Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2896 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jeffrey.hundstad@mnsu.edu Precedence: bulk X-list: linux-xfs Content-Length: 747 Lines: 21 Hello again, I've tried to follow the instructions on http://oss.sgi.com/projects/xfs/devtree.html "Installing the XFS Development Tree," without much luck. I'm trying to get a linux-2.6.5 kernel with the ACL support. - There is no current version in the patch sets. - After I cvsup as per directions I get a directory linux/fs/xfs. If I replace the linux-2.6.5/linux/fs/xfs with this directory I get a compile time error: "fs/xfs/linux-2.6/xfs_super.c:282: `BDEV_FS' undeclared (first use in this function)". - I can't seem to find the split patches for the ACL's like before. Since it's quite obvious that I'm missing a clue somewhere... how do I get ACL support into linux-2.6.5. -- jeffrey hundstad PS it it the webpages or me? From owner-linux-xfs@oss.sgi.com Fri Apr 23 13:22:25 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 23 Apr 2004 13:22:29 -0700 (PDT) Received: from office.labsysgrp.com (wsip-68-14-253-125.ph.ph.cox.net [68.14.253.125]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3NKMPKO030942 for ; Fri, 23 Apr 2004 13:22:25 -0700 Received: from [127.0.0.1] (helo=localhost) by office.labsysgrp.com with esmtp (Exim 4.24) id 1BH7Bj-0006km-TV for linux-xfs@oss.sgi.com; Fri, 23 Apr 2004 13:22:19 -0700 Received: from office.labsysgrp.com ([127.0.0.1]) by localhost (office.lsg.internal [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25883-02 for ; Fri, 23 Apr 2004 13:22:19 -0700 (MST) Received: from jeeves.kpf.internal ([192.168.170.1]) by office.labsysgrp.com with esmtp (Exim 4.24) id 1BH7Bj-0006kg-9j for linux-xfs@oss.sgi.com; Fri, 23 Apr 2004 13:22:19 -0700 Received: from [192.168.172.107] (helo=backtobasicsmgmt.com) by jeeves.kpf.internal with esmtp (Exim 4.05) id 1BH7Bi-0002fO-00 for linux-xfs@oss.sgi.com; Fri, 23 Apr 2004 13:22:18 -0700 Message-ID: <40897AFE.2040207@backtobasicsmgmt.com> Date: Fri, 23 Apr 2004 13:22:22 -0700 From: "Kevin P. Fleming" Organization: Back To Basics Network Management User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: How to patch linux-2.6.5 with the current version of xfs References: <40896D63.9030606@mnsu.edu> In-Reply-To: <40896D63.9030606@mnsu.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at labsysgrp.com X-archive-position: 2897 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kpfleming@backtobasicsmgmt.com Precedence: bulk X-list: linux-xfs Content-Length: 242 Lines: 8 Jeffrey E. Hundstad wrote: > Since it's quite obvious that I'm missing a clue somewhere... how do I > get ACL support into linux-2.6.5. It's already there, just turn it on in make config/menuconfig/xconfig/etc. No patches are necessary. From owner-linux-xfs@oss.sgi.com Fri Apr 23 13:39:40 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 23 Apr 2004 13:39:47 -0700 (PDT) Received: from mail.mnsu.edu (Mail.MNSU.EDU [134.29.1.12]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3NKdeKO031688 for ; Fri, 23 Apr 2004 13:39:40 -0700 Received: from mnsu.edu (j3gum-3.ITS.MNSU.EDU [134.29.32.1]) by mail.mnsu.edu (8.12.10/8.12.10) with ESMTP id i3NKdQLP032532 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 23 Apr 2004 15:39:26 -0500 Message-ID: <40897EFE.2060608@mnsu.edu> Date: Fri, 23 Apr 2004 15:39:26 -0500 From: "Jeffrey E. Hundstad" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kevin P. Fleming" CC: linux-xfs@oss.sgi.com Subject: Re: How to patch linux-2.6.5 with the current version of xfs References: <40896D63.9030606@mnsu.edu> <40897AFE.2040207@backtobasicsmgmt.com> In-Reply-To: <40897AFE.2040207@backtobasicsmgmt.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2898 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jeffrey.hundstad@mnsu.edu Precedence: bulk X-list: linux-xfs Content-Length: 416 Lines: 16 Yup, I guess that's true. Thanks. I'm still currious on how to get the current CVS snapshot wedged into the current kernel tree. Kevin P. Fleming wrote: > Jeffrey E. Hundstad wrote: > >> Since it's quite obvious that I'm missing a clue somewhere... how do >> I get ACL support into linux-2.6.5. > > > It's already there, just turn it on in make > config/menuconfig/xconfig/etc. No patches are necessary. > > From owner-linux-xfs@oss.sgi.com Fri Apr 23 15:07:21 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 23 Apr 2004 15:07:25 -0700 (PDT) Received: from dingdong.cryptoapps.com (uslink-66.173.43-129.uslink.net [66.173.43.129] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3NM7LKO002236 for ; Fri, 23 Apr 2004 15:07:21 -0700 Received: by dingdong.cryptoapps.com (Postfix, from userid 1001) id 7FEFBFB837; Fri, 23 Apr 2004 17:07:09 -0500 (CDT) Date: Fri, 23 Apr 2004 15:07:09 -0700 From: Chris Wedgwood To: "Jeffrey E. Hundstad" Cc: "Kevin P. Fleming" , linux-xfs@oss.sgi.com Subject: Re: How to patch linux-2.6.5 with the current version of xfs Message-ID: <20040423220709.GA8397@dingdong.cryptoapps.com> References: <40896D63.9030606@mnsu.edu> <40897AFE.2040207@backtobasicsmgmt.com> <40897EFE.2060608@mnsu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40897EFE.2060608@mnsu.edu> X-archive-position: 2899 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 343 Lines: 11 On Fri, Apr 23, 2004 at 03:39:26PM -0500, Jeffrey E. Hundstad wrote: > Yup, I guess that's true. Thanks. I'm still currious on how to get > the current CVS snapshot wedged into the current kernel tree. I have patches for this if you are desperate, but I'd just wait a couple more days and give the SGI people a chance to resync. --cw From owner-linux-xfs@oss.sgi.com Fri Apr 23 15:09:38 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 23 Apr 2004 15:09:41 -0700 (PDT) Received: from dingdong.cryptoapps.com (uslink-66.173.43-129.uslink.net [66.173.43.129] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3NM9bKO002649 for ; Fri, 23 Apr 2004 15:09:38 -0700 Received: by dingdong.cryptoapps.com (Postfix, from userid 1001) id 77390FB837; Fri, 23 Apr 2004 17:09:26 -0500 (CDT) Date: Fri, 23 Apr 2004 15:09:26 -0700 From: Chris Wedgwood To: MichaelM Cc: linux-xfs@oss.sgi.com Subject: Re: Problems with deleting directories Message-ID: <20040423220926.GB8397@dingdong.cryptoapps.com> References: <4087A605.7090204@hasw.net> <200404230843.28227.lordvader@swifdsl.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200404230843.28227.lordvader@swifdsl.com.au> X-archive-position: 2900 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 473 Lines: 12 On Fri, Apr 23, 2004 at 08:43:28AM +1000, MichaelM wrote: > I once had a similar problem. It wasn't due to the filesystem, but > rather a filename got currupted, and ended up with a "/" in the > name. "/" is an illegal character in filenames, so the file couldn't > be deleted, renamed, nothing. I had to format the drive to remove > the file. Formatting is pretty drastic. You could just find out which block the filename is in and poke that with hexedit or similar. From owner-linux-xfs@oss.sgi.com Fri Apr 23 18:35:39 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 23 Apr 2004 18:35:46 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i3O1ZdKO011601 for ; Fri, 23 Apr 2004 18:35:39 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i3O1ZdCk011600 for linux-xfs@oss.sgi.com; Fri, 23 Apr 2004 18:35:39 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i3O1ZbKQ011586 for ; Fri, 23 Apr 2004 18:35:37 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i3O0tIl7010955; Fri, 23 Apr 2004 17:55:18 -0700 Date: Fri, 23 Apr 2004 17:55:18 -0700 Message-Id: <200404240055.i3O0tIl7010955@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 325] New: Corrupted filesystem when using a XFS boot partition X-Bugzilla-Reason: AssignedTo X-archive-position: 2901 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1098 Lines: 28 http://oss.sgi.com/bugzilla/show_bug.cgi?id=325 Summary: Corrupted filesystem when using a XFS boot partition Product: Linux XFS Version: unspecified Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: magsilva@icmc.usp.br I'm currently using Conectiva Linux Snapshot, kernel 2.6.3. I set up a XFS partition as boot partition with grub. But doing this corrupted the filesystem. Fortunately, I could fix the corruption using xfs_recover (but could not boot with that partition even using it). I searched grub's bugzilla and found out some reports saying that XFS doesn't support being used as boot partition (http://savannah.gnu.org/search/?words=xfs&type_of_search=bugs&group_id=68&Search=Search&exact=1&max_rows=25). Is this true or it's some bug within XFS? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Fri Apr 23 19:08:58 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 23 Apr 2004 19:09:01 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i3O28wKO012429 for ; Fri, 23 Apr 2004 19:08:58 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i3O28wUY012428 for linux-xfs@oss.sgi.com; Fri, 23 Apr 2004 19:08:58 -0700 Received: from jdc.local (ppp1FAC.dsl.pacific.net.au [203.100.245.172]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3O28oKO012412; Fri, 23 Apr 2004 19:08:53 -0700 Received: from jdc.local (localhost [127.0.0.1]) by jdc.local (8.12.11/8.12.11/Debian-4) with ESMTP id i3O28h7Y012350; Sat, 24 Apr 2004 12:08:43 +1000 Received: (from jason@localhost) by jdc.local (8.12.11/8.12.11/Debian-4) id i3O28hcp012343; Sat, 24 Apr 2004 12:08:43 +1000 From: Jason White MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16521.52267.817886.10940@jdc.local> Date: Sat, 24 Apr 2004 12:08:43 +1000 To: bugzilla-daemon@oss.sgi.com Cc: xfs-master@oss.sgi.com Subject: Re: [Bug 325] New: Corrupted filesystem when using a XFS boot partition In-Reply-To: <200404240055.i3O0tIl7010955@oss.sgi.com> References: <200404240055.i3O0tIl7010955@oss.sgi.com> X-Mailer: VM 7.18 under Emacs 21.3.1 Reply-To: jasonw@ariel.ucs.unimelb.edu.au X-archive-position: 2902 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jasonw@ariel.ucs.unimelb.edu.au Precedence: bulk X-list: linux-xfs Content-Length: 798 Lines: 15 > http://oss.sgi.com/bugzilla/show_bug.cgi?id=325 > I'm currently using Conectiva Linux Snapshot, kernel 2.6.3. I set up a XFS partition as boot > partition with grub. But doing this corrupted the filesystem. Fortunately, I could fix the > corruption using xfs_recover (but could not boot with that partition even using it). I searched > grub's bugzilla and found out some reports saying that XFS doesn't support being used as boot > partition > (http://savannah.gnu.org/search/?words=xfs&type_of_search=bugs&group_id=68&Search=Search&exact=1&max_rows=25). > Is this true or it's some bug within XFS? http://oss.sgi.com/projects/xfs/faq.html#lilowork applies to grub too. If you install it in the MBR (Master Boot Record) of the drive, but not in the XFS partition, it will work. From owner-linux-xfs@oss.sgi.com Fri Apr 23 20:40:51 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 23 Apr 2004 20:40:57 -0700 (PDT) Received: from mail.syd.swiftdsl.com.au (mail.syd.swiftdsl.com.au [202.154.83.58]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3O3enKO016971 for ; Fri, 23 Apr 2004 20:40:50 -0700 Received: (qmail 11593 invoked from network); 24 Apr 2004 03:40:48 -0000 Received: from unknown (HELO sithmachine.myempire) (218.214.21.72) by mail.syd.swiftdsl.com.au with SMTP; 24 Apr 2004 03:40:48 -0000 From: MichaelM To: linux-xfs@oss.sgi.com Subject: Re: Problems with deleting directories Date: Sat, 24 Apr 2004 13:40:55 +1000 User-Agent: KMail/1.6 References: <4087A605.7090204@hasw.net> <200404230843.28227.lordvader@swifdsl.com.au> <20040423220926.GB8397@dingdong.cryptoapps.com> In-Reply-To: <20040423220926.GB8397@dingdong.cryptoapps.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200404241340.55059.lordvader@swifdsl.com.au> X-archive-position: 2903 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lordvader@swifdsl.com.au.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 574 Lines: 13 On Sat, 24 Apr 2004 08:09 am, you wrote: > On Fri, Apr 23, 2004 at 08:43:28AM +1000, MichaelM wrote: > > I once had a similar problem. It wasn't due to the filesystem, but > > rather a filename got currupted, and ended up with a "/" in the > > name. "/" is an illegal character in filenames, so the file couldn't > > be deleted, renamed, nothing. I had to format the drive to remove > > the file. > > Formatting is pretty drastic. You could just find out which block the > filename is in and poke that with hexedit or similar. Well yeah, but I was gonna format anyway :D From owner-linux-xfs@oss.sgi.com Sat Apr 24 08:09:40 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 24 Apr 2004 08:09:45 -0700 (PDT) Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3OF9eKO016234 for ; Sat, 24 Apr 2004 08:09:40 -0700 Received: from [24.118.125.111] (c-24-118-125-111.mn.client2.attbi.com [24.118.125.111]) by lips.borg.umn.edu (8.12.11/8.12.11) with ESMTP id i3OF9cnU089318; Sat, 24 Apr 2004 10:09:38 -0500 (CDT) (envelope-from cattelan@thebarn.com) Subject: Re: How to patch linux-2.6.5 with the current version of xfs From: Russell Cattelan To: "Jeffrey E. Hundstad" Cc: linux-xfs@oss.sgi.com In-Reply-To: <40896D63.9030606@mnsu.edu> References: <40896D63.9030606@mnsu.edu> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-wNc5HpWxuMn4227dwxhd" Message-Id: <1082819129.92674.19.camel@lupo.thebarn.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sat, 24 Apr 2004 10:05:30 -0500 X-archive-position: 2904 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 1434 Lines: 42 --=-wNc5HpWxuMn4227dwxhd Content-Type: text/plain Content-Transfer-Encoding: quoted-printable the linux-2.6-xfs tree is as 2.6.5 and should be buiding just fine. http://www.oss.sgi.com/projects/xfs/cvs_download.html On Fri, 2004-04-23 at 14:24, Jeffrey E. Hundstad wrote: > Hello again, >=20 > I've tried to follow the instructions on=20 > http://oss.sgi.com/projects/xfs/devtree.html "Installing the XFS=20 > Development Tree," without much luck. I'm trying to get a linux-2.6.5=20 > kernel with the ACL support. >=20 > - There is no current version in the patch sets. > - After I cvsup as per directions I get a directory linux/fs/xfs. If I= =20 > replace the linux-2.6.5/linux/fs/xfs with this directory I get a compile= =20 > time error: "fs/xfs/linux-2.6/xfs_super.c:282: `BDEV_FS' undeclared=20 > (first use in this function)". > - I can't seem to find the split patches for the ACL's like before. >=20 > Since it's quite obvious that I'm missing a clue somewhere... how do I=20 > get ACL support into linux-2.6.5. --=20 Russell Cattelan --=-wNc5HpWxuMn4227dwxhd Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQBAioI5NRmM+OaGhBgRAnQFAJwJQpd9D+NnrZ4oAtQw/aMsvBcUBwCeNHHq cTTp3MMaY3wVakVJfaxBnfY= =auLt -----END PGP SIGNATURE----- --=-wNc5HpWxuMn4227dwxhd-- From owner-linux-xfs@oss.sgi.com Sat Apr 24 08:35:44 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 24 Apr 2004 08:36:01 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i3OFZhKO019953 for ; Sat, 24 Apr 2004 08:35:43 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i3OFZhx3019952 for linux-xfs@oss.sgi.com; Sat, 24 Apr 2004 08:35:43 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i3OFZeKQ019938 for ; Sat, 24 Apr 2004 08:35:40 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i3OFD4tI016583; Sat, 24 Apr 2004 08:13:04 -0700 Date: Sat, 24 Apr 2004 08:13:04 -0700 Message-Id: <200404241513.i3OFD4tI016583@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 325] Corrupted filesystem when using a XFS boot partition X-Bugzilla-Reason: AssignedTo X-archive-position: 2905 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 598 Lines: 21 http://oss.sgi.com/bugzilla/show_bug.cgi?id=325 cattelan@thebarn.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Additional Comments From cattelan@thebarn.com 2004-24-04 08:13 PDT ------- Installing boot loaders to a XFS partition is not supported. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Sat Apr 24 10:35:42 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 24 Apr 2004 10:35:46 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i3OHZgKO025650 for ; Sat, 24 Apr 2004 10:35:42 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i3OHZgo4025649 for linux-xfs@oss.sgi.com; Sat, 24 Apr 2004 10:35:42 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i3OHZeKQ025635 for ; Sat, 24 Apr 2004 10:35:40 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i3OGsIRi021790; Sat, 24 Apr 2004 09:54:18 -0700 Date: Sat, 24 Apr 2004 09:54:18 -0700 Message-Id: <200404241654.i3OGsIRi021790@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 325] Corrupted filesystem when using a XFS boot partition X-Bugzilla-Reason: AssignedTo X-archive-position: 2906 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 531 Lines: 18 http://oss.sgi.com/bugzilla/show_bug.cgi?id=325 ------- Additional Comments From sandeen@sgi.com 2004-24-04 09:54 PDT ------- just to clarify, xfs works fine on a boot partition; you just can't install a bootloader to any xfs partition, because the xfs superblock lives at block zero, and will be overwritten by the bootloader. xfs on /boot is just fine as long as you install the bootloader to the MBR ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Apr 26 09:51:36 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 26 Apr 2004 09:51:40 -0700 (PDT) Received: from bruce-guenter.dyndns.org (h24-78-187-71.ss.shawcable.net [24.78.187.71]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3QGpaKO025002 for ; Mon, 26 Apr 2004 09:51:36 -0700 Received: (qmail 21640 invoked by uid 500); 26 Apr 2004 16:51:55 -0000 Date: Mon, 26 Apr 2004 10:51:55 -0600 From: Bruce Guenter To: linux-xfs@oss.sgi.com Subject: Speeding up XFS Message-ID: <20040426165155.GA19148@em.ca> Mail-Followup-To: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KsGdsel6WgEHnImy" Content-Disposition: inline User-Agent: Mutt/1.5.6i X-archive-position: 2910 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lists-linux-xfs@bruce-guenter.dyndns.org Precedence: bulk X-list: linux-xfs Content-Length: 1109 Lines: 37 --KsGdsel6WgEHnImy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Greetings. I have been running a series of custom benchmarks to see what filesystems perform best for a maildir-based mail server. http://untroubled.org/benchmarking/2004-04/ So far, XFS with an external journal has by far the best delivery rate. However, as the filesystem fills and delivery concurrency increases, the time required to list, read and delete the delivered files slows down to unacceptable levels. Is there anything I can do, settings to modify, patches to try, to improve this behavior? Thanks. --=20 Bruce Guenter http://em.ca/~bruceg/ http://untroubled.org/ OpenPGP key: 699980E8 / D0B7 C8DD 365D A395 29DA 2E2A E96F B2DC 6999 80E8 --KsGdsel6WgEHnImy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAjT4r6W+y3GmZgOgRAtYKAJkBAx5qZREkXn977l8U/yuPTWgNRQCgjN5v HI1b36u88ZoqWQPgEuF70Uk= =fhvq -----END PGP SIGNATURE----- --KsGdsel6WgEHnImy-- From owner-linux-xfs@oss.sgi.com Mon Apr 26 10:08:16 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 26 Apr 2004 10:08:21 -0700 (PDT) Received: from dingdong.cryptoapps.com (uslink-66.173.43-129.uslink.net [66.173.43.129] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3QH8FKO025651 for ; Mon, 26 Apr 2004 10:08:15 -0700 Received: by dingdong.cryptoapps.com (Postfix, from userid 1001) id 4D675FB953; Mon, 26 Apr 2004 12:07:53 -0500 (CDT) Date: Mon, 26 Apr 2004 10:07:53 -0700 From: Chris Wedgwood To: linux-xfs@oss.sgi.com Subject: Re: Speeding up XFS Message-ID: <20040426170753.GA30860@dingdong.cryptoapps.com> References: <20040426165155.GA19148@em.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040426165155.GA19148@em.ca> X-archive-position: 2911 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 437 Lines: 14 On Mon, Apr 26, 2004 at 10:51:55AM -0600, Bruce Guenter wrote: > However, as the filesystem fills and delivery concurrency increases, > the time required to list, read and delete the delivered files slows > down to unacceptable levels. Is there anything I can do, settings > to modify, patches to try, to improve this behavior? How large are the maildir's themselves (specifically how large are the new & cur directories)? --cw From owner-linux-xfs@oss.sgi.com Mon Apr 26 10:16:35 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 26 Apr 2004 10:16:42 -0700 (PDT) Received: from omx1.americas.sgi.com (cfcafw.sgi.com [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3QHGZKO026440 for ; Mon, 26 Apr 2004 10:16:35 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i3QHEOBN025563 for ; Mon, 26 Apr 2004 12:14:24 -0500 Received: from omx2.sgi.com (omx2.sgi.com [198.149.32.25]) by nodin.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i3QHED9f4268031 for ; Mon, 26 Apr 2004 10:14:13 -0700 (PDT) Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i3QJLi4o022030 for ; Mon, 26 Apr 2004 12:21:54 -0700 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i3QHDbKe37630674; Mon, 26 Apr 2004 12:13:37 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i3QHDPHO861299; Mon, 26 Apr 2004 12:13:37 -0500 (CDT) Subject: Re: Why problems with mount and strace From: Eric Sandeen To: "Blizbor (IMA)" Cc: linux-xfs@oss.sgi.com In-Reply-To: <3F716CB2.6010805@ima.pl> References: <3F716CB2.6010805@ima.pl> Content-Type: text/plain Organization: Eric Conspiracy Secret Labs Message-Id: <1082999605.9623.54.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 26 Apr 2004 12:13:25 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 2912 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1352 Lines: 47 I came across this again, and I have an answer for you... at least relating to today's code. xfs mount tries to start linvfs_xfs_syncd, which invokes a kernel_thread(), which contains this code: /* lock out any potential ptracer */ task_lock(task); if (task->ptrace) { task_unlock(task); return -EPERM; } for security reasons... in short, when stracing, linvfs_xfs_syncd() fails, and hence the mount fails. -Eric On Wed, 2003-09-24 at 05:06, Blizbor (IMA) wrote: > Hi, > > I have tested something and I have found weird behaviour. > > I repeated the same for fstype in ext2, jfs, reiserfs and xfs curious > how mkfs and mount > are working (trying to trace whats wrong beetween drbd and xfs) > > strace -o mkfs.${fstype}.txt -ff mkfs.${fstype} /dev/xxx > strace -o mount.${fstype} /dev/xxx /mountpoint > > I've got all mkfs logs. > I've got all but xfs logs for mount. > > Telling the trueth, I've got log of mounting xfs but something weird > happened. > Mount without strace was working fine but "strace mount" was failed. > (No such device, bad options ... easy to reproduce) > Why I can't mount xfs and strace it ? > > Regards, > Blizbor -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Mon Apr 26 10:22:10 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 26 Apr 2004 10:22:13 -0700 (PDT) Received: from bruce-guenter.dyndns.org (h24-78-187-71.ss.shawcable.net [24.78.187.71]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3QHM9KO027011 for ; Mon, 26 Apr 2004 10:22:09 -0700 Received: (qmail 22907 invoked by uid 500); 26 Apr 2004 17:22:30 -0000 Date: Mon, 26 Apr 2004 11:22:30 -0600 From: Bruce Guenter To: linux-xfs@oss.sgi.com Subject: Re: Speeding up XFS Message-ID: <20040426172230.GA22806@em.ca> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20040426165155.GA19148@em.ca> <20040426170753.GA30860@dingdong.cryptoapps.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qMm9M+Fa2AknHoGS" Content-Disposition: inline In-Reply-To: <20040426170753.GA30860@dingdong.cryptoapps.com> User-Agent: Mutt/1.5.6i X-archive-position: 2913 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lists-linux-xfs@bruce-guenter.dyndns.org Precedence: bulk X-list: linux-xfs Content-Length: 1244 Lines: 35 --qMm9M+Fa2AknHoGS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 26, 2004 at 10:07:53AM -0700, Chris Wedgwood wrote: > On Mon, Apr 26, 2004 at 10:51:55AM -0600, Bruce Guenter wrote: > > However, as the filesystem fills and delivery concurrency increases, > > the time required to list, read and delete the delivered files slows > > down to unacceptable levels. Is there anything I can do, settings > > to modify, patches to try, to improve this behavior? >=20 > How large are the maildir's themselves (specifically how large are the > new & cur directories)? During the run of the above benchmark, they are typically small -- less than a dozen entries in each one, with filenames of about 23 characters. --=20 Bruce Guenter http://em.ca/~bruceg/ http://untroubled.org/ OpenPGP key: 699980E8 / D0B7 C8DD 365D A395 29DA 2E2A E96F B2DC 6999 80E8 --qMm9M+Fa2AknHoGS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAjUVW6W+y3GmZgOgRAuONAJsFL/an9MaDqyvwgb6gYFxmODr+2gCgiElD M0c8DpLs4iz4OT6/V1NVhAQ= =ciWM -----END PGP SIGNATURE----- --qMm9M+Fa2AknHoGS-- From owner-linux-xfs@oss.sgi.com Mon Apr 26 10:26:16 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 26 Apr 2004 10:26:20 -0700 (PDT) Received: from omx1.americas.sgi.com (cfcafw.sgi.com [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3QHQGKO027525 for ; Mon, 26 Apr 2004 10:26:16 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i3QHQBBN030612 for ; Mon, 26 Apr 2004 12:26:11 -0500 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i3QHQAKe37575319; Mon, 26 Apr 2004 12:26:10 -0500 (CDT) Received: from zhadum.americas.sgi.com (zhadum.americas.sgi.com [128.162.233.43]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i3QHQAXa5410561; Mon, 26 Apr 2004 12:26:10 -0500 (CDT) Received: from zhadum.americas.sgi.com by zhadum.americas.sgi.com (SGI-8.12.5/SGI-client-1.7) via ESMTP id i3QHQ9Bh269889; Mon, 26 Apr 2004 12:26:09 -0500 (CDT) Received: (from overby@localhost) by zhadum.americas.sgi.com (SGI-8.12.5/8.12.5/Submit) id i3QHQ8Aj298772; Mon, 26 Apr 2004 12:26:08 -0500 (CDT) Date: Mon, 26 Apr 2004 12:26:08 -0500 (CDT) Message-Id: <200404261726.i3QHQ8Aj298772@zhadum.americas.sgi.com> From: Glen Overby To: linux-xfs@oss.sgi.com Cc: lists-linux-xfs@bruce-guenter.dyndns.org Subject: Re: Speeding up XFS In-Reply-To: message from Bruce Guenter sent 26 April 2004 References: <20040426165155.GA19148@em.ca> X-archive-position: 2914 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: overby@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1153 Lines: 27 On April 26, Bruce Guenter wrote: > So far, XFS with an external journal has by far the best delivery rate. > However, as the filesystem fills and delivery concurrency increases, the > time required to list, read and delete the delivered files slows down to > unacceptable levels. Is there anything I can do, settings to modify, > patches to try, to improve this behavior? Some generic suggestions: - more log buffers than fewer (try 8) - It looks like you're doing a lot of metadata intense operations, so you should try a larger log buffer size which are available in version 2 logs. I wrote version 2 logs, along with some other changes, to speed up metadata intense benchmarks. I think 128mb log buffers work on linux. Stay away from log striping. The last I heard, it still doesn't work. - You didn't say what your filesystem size is. There is an ugly hack we put in to kee inode numbers < 2**32. This changes inode and data placement (inodes are kept in the lower AGs, user data is spread around in the upper AGs) and brings on the full-filesystem case earlier. I think thats what you hit. Glen Overby From owner-linux-xfs@oss.sgi.com Mon Apr 26 10:32:39 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 26 Apr 2004 10:32:43 -0700 (PDT) Received: from bruce-guenter.dyndns.org (h24-78-187-71.ss.shawcable.net [24.78.187.71]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3QHWdKO028013 for ; Mon, 26 Apr 2004 10:32:39 -0700 Received: (qmail 23402 invoked by uid 500); 26 Apr 2004 17:33:00 -0000 Date: Mon, 26 Apr 2004 11:33:00 -0600 From: Bruce Guenter To: linux-xfs@oss.sgi.com Subject: Re: Speeding up XFS Message-ID: <20040426173300.GA23256@em.ca> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20040426165155.GA19148@em.ca> <200404261726.i3QHQ8Aj298772@zhadum.americas.sgi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yrj/dFKFPuw6o+aM" Content-Disposition: inline In-Reply-To: <200404261726.i3QHQ8Aj298772@zhadum.americas.sgi.com> User-Agent: Mutt/1.5.6i X-archive-position: 2915 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lists-linux-xfs@bruce-guenter.dyndns.org Precedence: bulk X-list: linux-xfs Content-Length: 1998 Lines: 60 --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 26, 2004 at 12:26:08PM -0500, Glen Overby wrote: > On April 26, Bruce Guenter wrote: > > So far, XFS with an external journal has by far the best delivery rate. > > However, as the filesystem fills and delivery concurrency increases, the > > time required to list, read and delete the delivered files slows down to > > unacceptable levels. Is there anything I can do, settings to modify, > > patches to try, to improve this behavior? >=20 > Some generic suggestions: >=20 > - more log buffers than fewer (try 8) I'm already using: mount -t xfs -o noatime,logbufs=3D8,logbsize=3D65536 > - It looks like you're doing a lot of metadata intense operations, so > you should try a larger log buffer size which are available in > version 2 logs. I wrote version 2 logs, along with some other > changes, to speed up metadata intense benchmarks. I think 128mb > log buffers work on linux.=20 I'll try that. > - You didn't say what your filesystem size is. I did so: Filesystem partition: 72GB on a software RAID-1 array of Fujitsu SCSI 15kRPM disks. > There is an ugly hack > we put in to kee inode numbers < 2**32. This changes inode and > data placement (inodes are kept in the lower AGs, user data is > spread around in the upper AGs) and brings on the full-filesystem > case earlier. I think thats what you hit. Is there any way to avoid this situation? --=20 Bruce Guenter http://em.ca/~bruceg/ http://untroubled.org/ OpenPGP key: 699980E8 / D0B7 C8DD 365D A395 29DA 2E2A E96F B2DC 6999 80E8 --yrj/dFKFPuw6o+aM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAjUfM6W+y3GmZgOgRAqP6AJ4sdM3248QF3DK3FAqfVyJ4cZhPPQCdH9p4 FkUvU+4sOvOLrDZkhYkgIto= =dHsp -----END PGP SIGNATURE----- --yrj/dFKFPuw6o+aM-- From owner-linux-xfs@oss.sgi.com Mon Apr 26 10:49:44 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 26 Apr 2004 10:49:48 -0700 (PDT) Received: from dingdong.cryptoapps.com (uslink-66.173.43-129.uslink.net [66.173.43.129] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3QHnhKO029163 for ; Mon, 26 Apr 2004 10:49:44 -0700 Received: by dingdong.cryptoapps.com (Postfix, from userid 1001) id DD07CFB960; Mon, 26 Apr 2004 12:49:28 -0500 (CDT) Date: Mon, 26 Apr 2004 10:49:28 -0700 From: Chris Wedgwood To: linux-xfs@oss.sgi.com Subject: Re: Speeding up XFS Message-ID: <20040426174928.GA31156@dingdong.cryptoapps.com> References: <20040426165155.GA19148@em.ca> <200404261726.i3QHQ8Aj298772@zhadum.americas.sgi.com> <20040426173300.GA23256@em.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040426173300.GA23256@em.ca> X-archive-position: 2916 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 552 Lines: 16 On Mon, Apr 26, 2004 at 11:33:00AM -0600, Bruce Guenter wrote: > > There is an ugly hack we put in to kee inode numbers < 2**32. > > This changes inode and data placement (inodes are kept in the > > lower AGs, user data is spread around in the upper AGs) and > > brings on the full-filesystem case earlier. I think thats what > > you hit. > Is there any way to avoid this situation? I don't think you are seeing that. You can avoid it by using fs' under 1TB or making your inodes larger (buys you a little). Or use a 64-bit CPU. From owner-linux-xfs@oss.sgi.com Mon Apr 26 10:54:03 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 26 Apr 2004 10:54:07 -0700 (PDT) Received: from bruce-guenter.dyndns.org (h24-78-187-71.ss.shawcable.net [24.78.187.71]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3QHs2KO029607 for ; Mon, 26 Apr 2004 10:54:03 -0700 Received: (qmail 24097 invoked by uid 500); 26 Apr 2004 17:54:23 -0000 Date: Mon, 26 Apr 2004 11:54:23 -0600 From: Bruce Guenter To: linux-xfs@oss.sgi.com Subject: Re: Speeding up XFS Message-ID: <20040426175423.GA24047@em.ca> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20040426165155.GA19148@em.ca> <200404261726.i3QHQ8Aj298772@zhadum.americas.sgi.com> <20040426173300.GA23256@em.ca> <20040426174928.GA31156@dingdong.cryptoapps.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YiEDa0DAkWCtVeE4" Content-Disposition: inline In-Reply-To: <20040426174928.GA31156@dingdong.cryptoapps.com> User-Agent: Mutt/1.5.6i X-archive-position: 2917 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lists-linux-xfs@bruce-guenter.dyndns.org Precedence: bulk X-list: linux-xfs Content-Length: 881 Lines: 29 --YiEDa0DAkWCtVeE4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 26, 2004 at 10:49:28AM -0700, Chris Wedgwood wrote: > You can avoid it by using fs' under 1TB or making your inodes larger > (buys you a little). Or use a 64-bit CPU. Well, that's solved -- the filesystem is only 72GB, and the benchmark is running on an Opteron (AMD 64-bit). --=20 Bruce Guenter http://em.ca/~bruceg/ http://untroubled.org/ OpenPGP key: 699980E8 / D0B7 C8DD 365D A395 29DA 2E2A E96F B2DC 6999 80E8 --YiEDa0DAkWCtVeE4 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAjUzP6W+y3GmZgOgRAhJ9AJ0S8ABIqcLp+yB+TzXQCTfgJMkZmACdHWcH vNbsNQ+/UbQRKyqepOBN6qU= =8sqc -----END PGP SIGNATURE----- --YiEDa0DAkWCtVeE4-- From owner-linux-xfs@oss.sgi.com Mon Apr 26 11:06:59 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 26 Apr 2004 11:07:03 -0700 (PDT) Received: from zok.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3QI6xKO030158 for ; Mon, 26 Apr 2004 11:06:59 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i3QHujhv010765 for ; Mon, 26 Apr 2004 10:56:45 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i3QHujKe37574268; Mon, 26 Apr 2004 12:56:45 -0500 (CDT) Received: from zhadum.americas.sgi.com (zhadum.americas.sgi.com [128.162.233.43]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i3QHuiXa5308222; Mon, 26 Apr 2004 12:56:44 -0500 (CDT) Received: from zhadum.americas.sgi.com by zhadum.americas.sgi.com (SGI-8.12.5/SGI-client-1.7) via ESMTP id i3QHuiBh157009; Mon, 26 Apr 2004 12:56:44 -0500 (CDT) Received: (from overby@localhost) by zhadum.americas.sgi.com (SGI-8.12.5/8.12.5/Submit) id i3QHuhr2327870; Mon, 26 Apr 2004 12:56:43 -0500 (CDT) Date: Mon, 26 Apr 2004 12:56:43 -0500 (CDT) Message-Id: <200404261756.i3QHuhr2327870@zhadum.americas.sgi.com> From: Glen Overby To: linux-xfs@oss.sgi.com Cc: lists-linux-xfs@bruce-guenter.dyndns.org Reply-To: linux-xfs@oss.sgi.com Subject: Re: Speeding up XFS In-Reply-To: message from Bruce Guenter sent 26 April 2004 References: <20040426165155.GA19148@em.ca> <200404261726.i3QHQ8Aj298772@zhadum.americas.sgi.com> <20040426173300.GA23256@em.ca> X-archive-position: 2918 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: overby@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 883 Lines: 24 On April 26, Bruce Guenter wrote: > > There is an ugly hack > > we put in to kee inode numbers < 2**32. This changes inode and > > data placement (inodes are kept in the lower AGs, user data is > > spread around in the upper AGs) and brings on the full-filesystem > > case earlier. I think thats what you hit. > > Is there any way to avoid this situation? On Irix: mount -o inode64 On Linux: rewrite linux to use 64 bit inode numbers :-) With your filesystem, you should not be hitting the 32 bit inode problem. It kicks in a bit above a terabyte. I recently did some test runs similar to yours and found that a 2048-byte filesystem and directory block size was fastest. I believe that was largely bounded by log writes. This was on some obsolete hardware: 180mhz SGI O200 + SGI TP9100 4+1 RAID (internal log) so your mileage will likely vary. Glen Overby From owner-linux-xfs@oss.sgi.com Mon Apr 26 12:29:41 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 26 Apr 2004 12:29:48 -0700 (PDT) Received: from localhost.localdomain ([63.81.117.28]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3QJTdKO003735 for ; Mon, 26 Apr 2004 12:29:40 -0700 Received: from xfs.org (jen [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id i3QIqlvE003073; Mon, 26 Apr 2004 13:52:48 -0500 Message-ID: <408D5A7F.1050108@xfs.org> Date: Mon, 26 Apr 2004 13:52:47 -0500 From: Steve Lord User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bruce Guenter CC: linux-xfs@oss.sgi.com Subject: Re: Speeding up XFS References: <20040426165155.GA19148@em.ca> In-Reply-To: <20040426165155.GA19148@em.ca> Content-Type: multipart/mixed; boundary="------------020402000409070900040900" X-archive-position: 2920 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 21823 Lines: 592 This is a multi-part message in MIME format. --------------020402000409070900040900 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bruce Guenter wrote: > Greetings. > > I have been running a series of custom benchmarks to see what > filesystems perform best for a maildir-based mail server. > > http://untroubled.org/benchmarking/2004-04/ > > So far, XFS with an external journal has by far the best delivery rate. > However, as the filesystem fills and delivery concurrency increases, the > time required to list, read and delete the delivered files slows down to > unacceptable levels. Is there anything I can do, settings to modify, > patches to try, to improve this behavior? > > Thanks. The very wierd part is the slowdown you see with an external journal in the last case. I can see no reason why an external vs an internal journal would be different except for the possibility that there is some form of interaction with queue unplugging in the elevators between devices. It might be worth trying Linus's latest bitkeeper tree (2.6.6-rc2) which has per device queue unplugging and see if that makes a difference. Your website also comments on xfs read performance slowing down when there are a large number of files present. Can you define 'a large number of files'. I attached a perl script. If you run this once a second and capture the output when things are going bad it might tell us a few things. Steve Steve --------------020402000409070900040900 Content-Type: text/x-perl; name="xfs_stats.pl" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="xfs_stats.pl" #!/usr/bin/perl -w use strict; # # Display raw XFS statistics from /proc/fs/xfs/stat. # Quota statistics are handled via a separate xqmstats command. # my $file = '/proc/fs/xfs/stat'; my $loop = 0; if (@ARGV > 0) { if ($ARGV[0] eq '-f') { $loop=1; print "\e[H\e[2J"; shift(@ARGV); } } do { my @values; my @tmp; unless (open(STATS, $file)) { print STDERR "Running kernel is not exporting XFS statistics.\n"; die "$file: $!"; } while () { chomp; /^qm/ && next; # use xqmstats command from quota-tools /^(extent_alloc # 0 - 3 |abt # 4 - 7 |blk_map # 8 - 14 |bmbt # 15 - 18 |dir # 19 - 22 |trans # 23 - 25 |ig # 26 - 32 |log # 33 - 37 |push_ail # 38 - 47 |xstrat # 48 - 49 |rw # 50 - 51 |attr # 52 - 55 |icluster # 56 - 58 |vnodes # 59 - 66 |buf # 67 - 75 |xpc # 76 - 78 )/x || next; #die "Unrecognised line in $file:\n\t'$_'\n"; foreach (split(' ', $')) { push @values, sprintf("%11s", $_); } } @tmp = @values[76..78]; # reorder some items to get Ted's format. splice(@values, 76); splice(@values, 48, 0, ($tmp[0])); splice(@values, 52, 0, ($tmp[1])); splice(@values, 54, 0, ($tmp[2])); ($#values == 78) || die "Found $#values XFS values, expected 78"; my $time = localtime(time); print qq(XFS Statistics [$time] Extent Allocation Tail-Pushing Stats xs_allocx............ $values[ 0] xs_sleep_logspace..... $values[39] xs_allocb............ $values[ 1] xs_try_logspace....... $values[38] xs_freex............. $values[ 2] xs_push_ail........... $values[40] xs_freeb............. $values[ 3] xs_push_ail_success... $values[41] Allocation Btree xs_push_ail_pushbuf... $values[42] xs_abt_lookup........ $values[ 4] xs_push_ail_pinned.... $values[43] xs_abt_compare....... $values[ 5] xs_push_ail_locked.... $values[44] xs_abt_insrec........ $values[ 6] xs_push_ail_flushing.. $values[45] xs_abt_delrec........ $values[ 7] xs_push_ail_restarts.. $values[46] Block Mapping xs_push_ail_flush..... $values[47] xs_blk_mapr.......... $values[ 8] IoMap Write Convert xs_blk_mapw.......... $values[ 9] xs_xstrat_bytes....... $values[48] xs_blk_unmap......... $values[10] xs_xstrat_quick....... $values[49] xs_add_exlist........ $values[11] xs_xstrat_split....... $values[50] xs_del_exlist........ $values[12] Read/Write Stats xs_look_exlist....... $values[13] xs_write_calls........ $values[51] xs_cmp_exlist........ $values[14] xs_write_bytes........ $values[52] Block Map Btree xs_read_calls......... $values[53] xs_bmbt_lookup....... $values[15] xs_read_bytes......... $values[54] xs_bmbt_compare...... $values[16] Attribute Operations xs_bmbt_insrec....... $values[17] xs_attr_get........... $values[55] xs_bmbt_delrec....... $values[18] xs_attr_set........... $values[56] Directory Operations xs_attr_remove........ $values[57] xs_dir_lookup........ $values[19] xs_attr_list.......... $values[58] xs_dir_create........ $values[20] Inode Clustering xs_dir_remove........ $values[21] xs_iflush_count....... $values[59] xs_dir_getdents...... $values[22] xs_icluster_flushcnt.. $values[60] Transactions xs_icluster_flushinode $values[61] xs_trans_sync........ $values[23] Vnode Statistics xs_trans_async....... $values[24] vn_active............. $values[62] xs_trans_empty....... $values[25] vn_alloc.............. $values[63] Inode Operations vn_get................ $values[64] xs_ig_attempts....... $values[26] vn_hold............... $values[65] xs_ig_found.......... $values[27] vn_rele............... $values[66] xs_ig_frecycle....... $values[28] vn_reclaim............ $values[67] xs_ig_missed......... $values[29] vn_remove............. $values[68] xs_ig_dup............ $values[30] Buf Statistics xs_ig_reclaims....... $values[31] pb_get................ $values[70] xs_ig_attrchg........ $values[32] pb_create............. $values[71] Log Operations pb_get_locked......... $values[72] xs_log_writes........ $values[33] pb_get_locked_waited.. $values[73] xs_log_blocks........ $values[34] pb_busy_locked........ $values[74] xs_log_noiclogs...... $values[35] pb_miss_locked........ $values[75] xs_log_force......... $values[36] pb_page_retries....... $values[76] xs_log_force_sleep... $values[37] pb_page_found......... $values[77] pb_get_read........... $values[78] ); if ($loop) { print "\e[H"; sleep(1); } } while ($loop); __END__ =head1 NAME xfs_stats - display XFS performance statistics =head1 SYNOPSIS B [ B<-h> I ] [ B<-a> I ] =head1 DESCRIPTION I uses the /proc interface to extract XFS performance data from the running kernel. Alternatively, the performance data can be sourced from a Performance Co-Pilot (PCP) host running the I(1) daemon or from a PCP archive created by the I(1) utility. =head1 OPTIONS =head2 B<-h> I The named I should be the source of live performance data, rather than /proc. =head2 B<-a> I The historical data contained in the named I should be displayed, rather than /proc. =head1 STATISTICS =head2 B (I) Number of file system extents allocated over all XFS filesystems. =head2 B (I) Number of file system blocks allocated over all XFS filesystems. =head2 B (I) Number of file system extents freed over all XFS filesystems. =head2 B (I) Number of file system blocks freed over all XFS filesystems. =head2 B (I) Number of lookup operations in XFS filesystem allocation btrees. =head2 B (I) Number of compares in XFS filesystem allocation btree lookups. =head2 B (I) Number of extent records inserted into XFS filesystem allocation btrees. =head2 B (I) Number of extent records deleted from XFS filesystem allocation btrees. =head2 B (I) Number of block map for read operations performed on XFS files. =head2 B (I) Number of block map for write operations performed on XFS files. =head2 B (I) Number of block unmap (delete) operations performed on XFS files. =head2 B (I) Number of extent list insertion operations for XFS files. =head2 B (I) Number of extent list deletion operations for XFS files. =head2 B (I) Number of extent list lookup operations for XFS files. =head2 B (I) Number of extent list comparisons in XFS extent list lookups. =head2 B (I) Number of block map btree lookup operations on XFS files. =head2 B (I) Number of block map btree compare operations in XFS block map lookups. =head2 B (I) Number of block map btree records inserted for XFS files. =head2 B (I) Number of block map btree records deleted for XFS files. =head2 B (I) This is a count of the number of file name directory lookups in XFS filesystems. It counts only those lookups which miss in the operating system's directory name lookup cache and must search the real directory structure for the name in question. The count is incremented once for each level of a pathname search that results in a directory lookup. =head2 B (I) This is the number of times a new directory entry was created in XFS filesystems. Each time that a new file, directory, link, symbolic link, or special file is created in the directory hierarchy the count is incremented. =head2 B (I) This is the number of times an existing directory entry was removed in XFS filesystems. Each time that a file, directory, link, symbolic link, or special file is removed from the directory hierarchy the count is incremented. =head2 B (I) This is the number of times the XFS directory getdents operation was performed. The getdents operation is used by programs to read the contents of directories in a file system independent fashion. This count corresponds exactly to the number of times the getdents(2) system call was successfully used on an XFS directory. =head2 B (I) This is the number of meta-data transactions which waited to be committed to the on-disk log before allowing the process performing the transaction to continue. These transactions are slower and more expensive than asynchronous transactions, because they force the in memory log buffers to be forced to disk more often and they wait for the completion of the log buffer writes. Synchronous transactions include file truncations and all directory updates when the file system is mounted with the 'wsync' option. =head2 B (I) This is the number of meta-data transactions which did not wait to be committed to the on-disk log before allowing the process performing the transaction to continue. These transactions are faster and more efficient than synchronous transactions, because they commit their data to the in memory log buffers without forcing those buffers to be written to disk. This allows multiple asynchronous transactions to be committed to disk in a single log buffer write. Most transactions used in XFS file systems are asynchronous. =head2 B (I) This is the number of meta-data transactions which did not actually change anything. These are transactions which were started for some purpose, but in the end it turned out that no change was necessary. =head2 B (I) This is the number of times the operating system looked for an XFS inode in the inode cache. Whether the inode was found in the cache or needed to be read in from the disk is not indicated here, but this can be computed from the ig_found and ig_missed counts. =head2 B (I) This is the number of times the operating system looked for an XFS inode in the inode cache and found it. The closer this count is to the ig_attempts count the better the inode cache is performing. =head2 B (I) This is the number of times the operating system looked for an XFS inode in the inode cache and saw that it was there but was unable to use the in memory inode because it was being recycled by another process. =head2 B (I) This is the number of times the operating system looked for an XFS inode in the inode cache and the inode was not there. The further this count is from the ig_attempts count the better. =head2 B (I) This is the number of times the operating system looked for an XFS inode in the inode cache and found that it was not there but upon attempting to add the inode to the cache found that another process had already inserted it. =head2 B (I) This is the number of times the operating system recycled an XFS inode from the inode cache in order to use the memory for that inode for another purpose. Inodes are recycled in order to keep the inode cache from growing without bound. If the reclaim rate is high it may be beneficial to raise the vnode_free_ratio kernel tunable variable to increase the size of the inode cache. =head2 B (I) This is the number of times the operating system explicitly changed the attributes of an XFS inode. For example, this could be to change the inode's owner, the inode's size, or the inode's timestamps. =head2 B (I) This variable counts the number of log buffer writes going to the physical log partitions of all XFS filesystems. Log data traffic is proportional to the level of meta-data updating. Log buffer writes get generated when they fill up or external syncs occur. =head2 B (I) This variable counts the number of Kbytes of information being written to the physical log partitions of all XFS filesystems. Log data traffic is proportional to the level of meta-data updating. The rate with which log data gets written depends on the size of internal log buffers and disk write speed. Therefore, filesystems with very high meta-data updating may need to stripe the log partition or put the log partition on a separate drive. =head2 B (I) This variable keeps track of times when a logged transaction can not get any log buffer space. When this occurs, all of the internal log buffers are busy flushing their data to the physical on-disk log. =head2 B (I) The number of times the in-core log is forced to disk. It is equivalent to the number of successful calls to the function xfs_log_force(). =head2 B (I) Value exported from the xs_log_force_sleep field of struct xfsstats. =head2 B (I) This is the number of buffers flushed out by the XFS flushing daemons which are written to contiguous space on disk. The buffers handled by the XFS daemons are delayed allocation buffers, so this count gives an indication of the success of the XFS daemons in allocating contiguous disk space for the data being flushed to disk. =head2 B (I) This is the number of buffers flushed out by the XFS flushing daemons which are written to non-contiguous space on disk. The buffers handled by the XFS daemons are delayed allocation buffers, so this count gives an indication of the failure of the XFS daemons in allocating contiguous disk space for the data being flushed to disk. Large values in this counter indicate that the file system has become fragmented. =head2 B (I) This is the number of write(2) system calls made to files in XFS file systems. =head2 B (I) This is the number of read(2) system calls made to files in XFS file systems. =head2 B (I) The number of "get" operations performed on extended file attributes within XFS filesystems. The "get" operation retrieves the value of an extended attribute. =head2 B (I) The number of "set" operations performed on extended file attributes within XFS filesystems. The "set" operation creates and sets the value of an extended attribute. =head2 B (I) The number of "remove" operations performed on extended file attributes within XFS filesystems. The "remove" operation deletes an extended attribute. =head2 B (I) The number of "list" operations performed on extended file attributes within XFS filesystems. The "list" operation retrieves the set of extended attributes associated with a file. =head2 B (I) Value from the xs_try_logspace field of struct xfsstats. =head2 B (I) Value from the xs_sleep_logspace field of struct xfsstats. =head2 B (I) The number of times the tail of the AIL is moved forward. It is equivalent to the number of successful calls to the function xfs_trans_push_ail(). =head2 B (I) Value from xs_push_ail_success field of struct xfsstats. =head2 B (I) Value from xs_push_ail_pushbuf field of struct xfsstats. =head2 B (I) Value from xs_push_ail_pinned field of struct xfsstats. =head2 B (I) Value from xs_push_ail_locked field of struct xfsstats. =head2 B (I) Value from xs_push_ail_flushing field of struct xfsstats. =head2 B (I) Value from xs_push_ail_restarts field of struct xfsstats. =head2 B (I) Value from xs_push_ail_flush field of struct xfsstats. =head2 B (I) This is the number of calls to xfs_iflush which gets called when an inode is being flushed (such as by bdflush or tail pushing). xfs_iflush searches for other inodes in the same cluster which are dirty and flushable. =head2 B (I) Value from xs_icluster_flushcnt field of struct xfsstats. =head2 B (I) This is the number of times that the inode clustering was not able to flush anything but the one inode it was called with. =head2 B (I) Number of vnodes not on free lists. =head2 B (I) Number of times vn_alloc called. =head2 B (I) Number of times vn_get called. =head2 B (I) Number of times vn_hold called. =head2 B (I) Number of times vn_rele called. =head2 B (I) Number of times vn_reclaim called. =head2 B (I) Number of times vn_remove called. =head2 B (I) This is a count of bytes written via B(2) system calls to files in XFS file systems. It can be used in conjunction with the write_calls count to calculate the average size of the write operations to files in XFS file systems. =head2 B (I) This is a count of bytes read via B(2) system calls to files in XFS file systems. It can be used in conjunction with the read_calls count to calculate the average size of the read operations to files in XFS file systems. =head2 B (I) This is a count of bytes of file data flushed out by the XFS flushing daemons. =head1 NOTES Many of these statistics are monotonically increasing counters, and of course are subject to counter overflow (the final three listed above are 64-bit values, all others are 32-bit values). As such they are of limited value in this raw form - if you are interested in monitoring throughput (e.g. bytes read/written per second), or other rates of change, you will be better served by investigating the PCP package more thoroughly - it contains a number of performance analysis tools which can help in this regard. =head1 FILES F - XFS statistical data =head1 SEE ALSO I(1), I(1), I(5), I(8). =cut --------------020402000409070900040900-- From owner-linux-xfs@oss.sgi.com Mon Apr 26 12:42:00 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 26 Apr 2004 12:42:04 -0700 (PDT) Received: from bruce-guenter.dyndns.org (h24-78-187-71.ss.shawcable.net [24.78.187.71]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3QJfvKO004604 for ; Mon, 26 Apr 2004 12:42:00 -0700 Received: (qmail 28512 invoked by uid 500); 26 Apr 2004 19:42:17 -0000 Date: Mon, 26 Apr 2004 13:42:17 -0600 From: Bruce Guenter To: linux-xfs@oss.sgi.com Subject: Re: Speeding up XFS Message-ID: <20040426194217.GA28350@em.ca> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20040426165155.GA19148@em.ca> <408D5A7F.1050108@xfs.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uAKRQypu60I7Lcqm" Content-Disposition: inline In-Reply-To: <408D5A7F.1050108@xfs.org> User-Agent: Mutt/1.5.6i X-archive-position: 2921 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lists-linux-xfs@bruce-guenter.dyndns.org Precedence: bulk X-list: linux-xfs Content-Length: 1627 Lines: 46 --uAKRQypu60I7Lcqm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 26, 2004 at 01:52:47PM -0500, Steve Lord wrote: > The very wierd part is the slowdown you see with an external journal > in the last case. I can see no reason why an external vs an internal > journal would be different except for the possibility that there > is some form of interaction with queue unplugging in the elevators > between devices. It might be worth trying Linus's latest bitkeeper > tree (2.6.6-rc2) which has per device queue unplugging and see > if that makes a difference. I am currently re-running some of the tests with 2.6.6-rc2-mm2. I'll re-run with XFS too and post my results. > Your website also comments on xfs read performance slowing down > when there are a large number of files present. Can you define > 'a large number of files'. Large is perhaps an exaggeration. On the order of 100,000 files (averaging roughly one per directory). > I attached a perl script. If you run this once a second and capture the > output when things are going bad it might tell us a few things. I'll do that. --=20 Bruce Guenter http://em.ca/~bruceg/ http://untroubled.org/ OpenPGP key: 699980E8 / D0B7 C8DD 365D A395 29DA 2E2A E96F B2DC 6999 80E8 --uAKRQypu60I7Lcqm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAjWYZ6W+y3GmZgOgRAjnSAKCgXCUXFgvpZ6b0LMhlST4QvTBXVgCeOqO6 /JSfbSQC/GGIWUdgGNOIi7E= =NBKw -----END PGP SIGNATURE----- --uAKRQypu60I7Lcqm-- From owner-linux-xfs@oss.sgi.com Mon Apr 26 14:37:41 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 26 Apr 2004 14:37:47 -0700 (PDT) Received: from rzcomm7.rz.tu-bs.de (rzcomm7.rz.tu-bs.de [134.169.9.53]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3QLbdKO014212 for ; Mon, 26 Apr 2004 14:37:40 -0700 Received: from localhost (localhost [127.0.0.1]) by rzcomm7.rz.tu-bs.de (8.11.1/8.11.1) with ESMTP id i3QDjIi06028 for ; Mon, 26 Apr 2004 15:45:18 +0200 (METDST) Received: from rzcomm7.rz.tu-bs.de ([127.0.0.1]) by localhost (rzcomm7 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05927-01-8 for ; Mon, 26 Apr 2004 15:45:16 +0200 (METDST) Received: from rzcomm12.rz.tu-bs.de (rzcomm12.rz.tu-bs.de [134.169.9.59]) by rzcomm7.rz.tu-bs.de (8.11.1/8.11.1) with ESMTP id i3QDhU605823 for ; Mon, 26 Apr 2004 15:43:30 +0200 (METDST) Received: from sycorax.strm.ing.tu-bs.de (sycorax.strm.ing.tu-bs.de [134.169.46.66]) by rzcomm12.rz.tu-bs.de (8.11.1/8.11.1) with ESMTP id i3QDhU828203 for ; Mon, 26 Apr 2004 15:43:30 +0200 (METDST) Received: by sycorax.strm.ing.tu-bs.de (Postfix, from userid 5239) id 9F6D8530009; Mon, 26 Apr 2004 15:43:29 +0200 (CEST) Date: Mon, 26 Apr 2004 15:43:29 +0200 From: Torsten Wolf To: linux-xfs@oss.sgi.com Subject: Not enough memory for xfs_repair Message-ID: <20040426134329.GA4617@sycorax> Reply-To: Torsten Wolf Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-Mailer: Mutt http://www.mutt.org/ Organization: TU Braunschweig X-Editor: Vim http://www.vim.org/ X-OpenPGP-Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xEE27B69C X-Fingerprint: 24EE 9FD9 5333 0206 541F 4602 C6A4 5F61 EE27 B69C X-Uptime: 15:39:59 up 5:04, 7 users, load average: 0.00, 0.14, 0.20 User-Agent: Mutt/1.5.5.1+cvs20040105i X-Virus-Scanned: by amavisd-new at tu-bs.de X-MIME-Autoconverted: from 8bit to quoted-printable by rzcomm7.rz.tu-bs.de id i3QDjIi06028 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i3QLbfKO014213 X-archive-position: 2922 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: t.wolf@tu-bs.de Precedence: bulk X-list: linux-xfs Content-Length: 3757 Lines: 94 Hi, recently, I purchased a 200GB HDD and created a single xfs partition (hdb1) on it for storage of lots of small data files. The machine runs under Debian/GNULinux (slightly outdated unstable) with kernel 2.4.25 and xfsprogs 2.6.5. The machine seems to suffer from flaky hardware (VIA chipset and 1.5GB RAM) which shows up when copying large amounts of data (several files differ afterwards). Also bzip2 complains about hardware problems. So far so bad. A few days ago, I wrote thousands of small files to hdb1 until the system froze various times. Finally, the nightly updatedb produced tons of the following messages: Apr 25 01:31:01 sycorax kernel: 0x0: 00 80 00 5e 00 80 0d 1b 90 79 29 ff 00 97 4c ba Apr 25 01:31:01 sycorax kernel: Filesystem "ide0(3,65)": XFS internal error xfs_da_do_buf(2) at line 2273 of file xfs_da_btree.c. Caller 0xc01bd117 Apr 25 01:31:01 sycorax kernel: d94ddcb8 c01bcb25 c0329231 00000001 f6a85800 c0329173 000008e1 c01bd117 Apr 25 01:31:01 sycorax kernel: c01bd117 d94ddd20 00000000 c0204498 f6a41c80 f6a50434 0000a201 00002000 Apr 25 01:31:01 sycorax kernel: 00000018 00800d1d 00000000 00000001 00000000 f6a85800 d94ddd3c 00000001 Apr 25 01:31:01 sycorax kernel: Call Trace: [] [] [] [] [] Apr 25 01:31:01 sycorax kernel: [] [] [] [] [] [] Apr 25 01:31:01 sycorax kernel: [] [] [] [] [] [] Apr 25 01:31:01 sycorax kernel: [] [] Apr 25 01:31:01 sycorax kernel: 3df49>] [] So I started xfs_repair and got the following result: sycorax:~# xfs_repair /dev/hdb1 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 bad directory leaf magic # 0xd2dc for directory inode 190 block 8388642 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - 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) ... - clearing existing "lost+found" inode - deleting existing "lost+found" entry - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... empty data block 5065 in directory inode 190: junking block unknown magic number 0xd2dc for block 8388642 in directory inode 190 rebuilding directory inode 190 xfs_repair: buf calloc failed (8228 bytes): Nicht genügend Hauptspeicher verfügbar Actually, xfs_repair eats up all of my memory (1.5GB RAM + 2GB swap). Searching google gave no useful result. So any hint how to recover this partition is greatly appreciated. Regards, Torsten From owner-linux-xfs@oss.sgi.com Mon Apr 26 15:24:50 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 26 Apr 2004 15:24:56 -0700 (PDT) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3QMOdKO015712 for ; Mon, 26 Apr 2004 15:24:39 -0700 X-Sasl-enc: g+YxU8LWXb2+2i8KotRdxw 1083016048 Received: from mailcan.com (t-indiv3-100.athome.tue.nl [131.155.240.100]) by www.fastmail.fm (Postfix) with ESMTP id AD15FAA88E1 for ; Mon, 26 Apr 2004 17:47:28 -0400 (EDT) Message-ID: <408D8370.2080702@mailcan.com> Date: Mon, 26 Apr 2004 23:47:28 +0200 From: Leon Woestenberg User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: Not enough memory for xfs_repair References: <20040426134329.GA4617@sycorax> In-Reply-To: <20040426134329.GA4617@sycorax> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2923 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: leonw@mailcan.com Precedence: bulk X-list: linux-xfs Content-Length: 862 Lines: 27 Hello Torsten, > and xfsprogs 2.6.5. The machine seems to suffer from flaky hardware (VIA > chipset and 1.5GB RAM) which shows up when copying large amounts of data > (several files differ afterwards). Also bzip2 complains about hardware > problems. So far so bad. > > A few days ago, I wrote thousands of small files to hdb1 until the > system froze various times. Finally, the nightly updatedb produced tons > of the following messages: > If you distrust the hardware for writing to disk correctly, I would never run xfs_repair (or anything that modifies the disk contents) on that same machine. You cannot expect it to work if the underlying hardware does not even work correctly. > ... > So I started xfs_repair and got the following result: Wouldn't it be better to attach the disk on another machine, and then see what can be done? Regards, Leon. From owner-linux-xfs@oss.sgi.com Mon Apr 26 18:16:44 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 26 Apr 2004 18:16:48 -0700 (PDT) Received: from omx1.americas.sgi.com (cfcafw.sgi.com [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3R1GhKO022677 for ; Mon, 26 Apr 2004 18:16:43 -0700 Received: from omx2.sgi.com ([198.149.32.25]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i3R1BaBN020829 for ; Mon, 26 Apr 2004 20:11:36 -0500 Received: from larry.melbourne.sgi.com ([134.14.52.130]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with SMTP id i3R38mGr028237 for ; Mon, 26 Apr 2004 20:08:58 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA02146; Tue, 27 Apr 2004 11:00:18 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i3R10F7X607062; Tue, 27 Apr 2004 11:00:16 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i3R10COi607674; Tue, 27 Apr 2004 11:00:12 +1000 (EST) Date: Tue, 27 Apr 2004 11:00:11 +1000 From: Nathan Scott To: Szima G?bor Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: XFS fsync() doesn't work under 2.4.26 Message-ID: <20040427110011.A604510@wobbly.melbourne.sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from sygma@tesla.hu on Fri, Apr 23, 2004 at 05:41:52PM +0200 X-archive-position: 2924 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1462 Lines: 48 On Fri, Apr 23, 2004 at 05:41:52PM +0200, Szima G?bor wrote: > > Hi, Hi there. > fsync() take no effect on XFS filesystem under Linux kernel 2.4.26. I'll look into it. Note your test below isn't quite showing that; what you want to do is do your writes, fsync, and then immediately pull the plug on fsync completion - if all the data isn't on disk, or the updates to the inode itself haven't been completed, then we have a problem (barring write caching caveats, etc). Having said that, the XFS flush time there seems too small - I'll audit the code and run tests to check if we're flushing everything out we that we should be. > Simple open-write-fsync-close test: > > ltrace -t /tmp/synctest: > ... > 0.002144 write(3, "", 1048576) = 1048576 > 0.002150 write(3, "", 1048576) = 1048576 > 0.002154 fsync(3, 0xbfeff684, 0x00100000, 0, 0) = 0 > 0.015962 close(3) = 0 > ^^^^^^^^ > > (64 x 1 MB data, ~8 MB/s disk write speed) > > > Under 2.4.25 or on other fs working fine: Are you saying here that XFS on 2.4.25 shows this larger time, as well as another filesystem? (i.e. just 2.4.26 XFS differs?) > ... > 0.002149 write(3, "", 1048576) = 1048576 > 0.002744 write(3, "", 1048576) = 1048576 > 0.002188 fsync(3, 0xbfeff664, 0x00100000, 0, 0) = 0 > 8.048844 close(3) = 0 > ^^^^^^^^ thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Apr 26 18:53:55 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 26 Apr 2004 18:53:59 -0700 (PDT) Received: from zok.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3R1rrKO024219 for ; Mon, 26 Apr 2004 18:53:55 -0700 Received: from larry.melbourne.sgi.com ([134.14.52.130]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id i3R1rkhv017359 for ; Mon, 26 Apr 2004 18:53:47 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA03188; Tue, 27 Apr 2004 11:53:44 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i3R1rg7X607575; Tue, 27 Apr 2004 11:53:43 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i3R1rfUw607630; Tue, 27 Apr 2004 11:53:41 +1000 (EST) Date: Tue, 27 Apr 2004 11:53:40 +1000 From: Nathan Scott To: linux-xfs@oss.sgi.com Cc: lists-linux-xfs@bruce-guenter.dyndns.org Subject: Re: Speeding up XFS Message-ID: <20040427115340.C604510@wobbly.melbourne.sgi.com> References: <20040426165155.GA19148@em.ca> <200404261726.i3QHQ8Aj298772@zhadum.americas.sgi.com> <20040426173300.GA23256@em.ca> <200404261756.i3QHuhr2327870@zhadum.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200404261756.i3QHuhr2327870@zhadum.americas.sgi.com>; from overby@sgi.com on Mon, Apr 26, 2004 at 12:56:43PM -0500 X-archive-position: 2925 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 899 Lines: 30 On Mon, Apr 26, 2004 at 12:56:43PM -0500, Glen Overby wrote: > On April 26, Bruce Guenter wrote: > > > > Is there any way to avoid this situation? > > On Irix: mount -o inode64 And on Linux. > On Linux: rewrite linux to use 64 bit inode numbers :-) On a 64 bit platform, 64 bit inode numbers are available. The inode64 option is enabled on such a system. IA64 was broken for some time in this regard, but we fixed that a long time ago. If your directories are indeed small, and directory operations are your bread and butter for this fs, I expect going to the smallest XFS inode size that fits all the directory entries inline in the inode (largest XFS inode size is 2k iirc, default is 256 bytes) to make the most difference. But, as you can tell from all the advice, there are lots of options, so fiddle with all the knobs till you find your ideal configuration. :) cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Apr 27 02:36:11 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 27 Apr 2004 02:36:17 -0700 (PDT) Received: from rzcomm7.rz.tu-bs.de (rzcomm7.rz.tu-bs.de [134.169.9.53]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3R9aAKO012936 for ; Tue, 27 Apr 2004 02:36:11 -0700 Received: from localhost (localhost [127.0.0.1]) by rzcomm7.rz.tu-bs.de (8.11.1/8.11.1) with ESMTP id i3R9a9i28257 for ; Tue, 27 Apr 2004 11:36:09 +0200 (METDST) Received: from unknown ([127.0.0.1]) by localhost (rzcomm7 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28174-01-9 for ; Tue, 27 Apr 2004 11:36:09 +0200 (METDST) Received: from rzcomm12.rz.tu-bs.de (rzcomm12.rz.tu-bs.de [134.169.9.59]) by rzcomm7.rz.tu-bs.de (8.11.1/8.11.1) with ESMTP id i3R9Zi628141 for ; Tue, 27 Apr 2004 11:35:44 +0200 (METDST) Received: from sycorax.strm.ing.tu-bs.de (sycorax.strm.ing.tu-bs.de [134.169.46.66]) by rzcomm12.rz.tu-bs.de (8.11.1/8.11.1) with ESMTP id i3R9Zh817368 for ; Tue, 27 Apr 2004 11:35:43 +0200 (METDST) Received: by sycorax.strm.ing.tu-bs.de (Postfix, from userid 5239) id 002BC530009; Tue, 27 Apr 2004 11:35:42 +0200 (CEST) Date: Tue, 27 Apr 2004 11:35:42 +0200 From: Torsten Wolf To: linux-xfs@oss.sgi.com Subject: Re: Not enough memory for xfs_repair Message-ID: <20040427093542.GB1440@sycorax> Reply-To: Torsten Wolf References: <20040426134329.GA4617@sycorax> <408D8370.2080702@mailcan.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <408D8370.2080702@mailcan.com> X-Mailer: Mutt http://www.mutt.org/ Organization: TU Braunschweig X-Editor: Vim http://www.vim.org/ X-OpenPGP-Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xEE27B69C X-Fingerprint: 24EE 9FD9 5333 0206 541F 4602 C6A4 5F61 EE27 B69C X-Uptime: 10:53:57 up 12 min, 4 users, load average: 0.14, 0.14, 0.10 User-Agent: Mutt/1.5.5.1+cvs20040105i X-Virus-Scanned: by amavisd-new at tu-bs.de X-archive-position: 2928 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: t.wolf@tu-bs.de Precedence: bulk X-list: linux-xfs Content-Length: 389 Lines: 18 Hello Leon, On Mo, 26 Apr 2004, Leon Woestenberg wrote: >Wouldn't it be better to attach the disk on another machine, and then >see what can be done? Yes, indeed. Attached to a more robust machine xfs_repair stopped at the same position followed by this dmesg output: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0) VM: killing process xfs_repair Any ideas? Regards, Torsten From owner-linux-xfs@oss.sgi.com Tue Apr 27 03:33:47 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 27 Apr 2004 03:33:51 -0700 (PDT) Received: from rrzd1.rz.uni-regensburg.de (rrzd1.rz.uni-regensburg.de [132.199.1.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3RAXkKO016645 for ; Tue, 27 Apr 2004 03:33:47 -0700 Received: from rrzd1 (rrzd1 [127.0.0.1]) by rrzd1.rz.uni-regensburg.de (8.12.3/8.12.3/Debian -4) with ESMTP id i3RAXiHT002763; Tue, 27 Apr 2004 12:33:44 +0200 Received: from pc9391.physik.uni-regensburg.de ([132.199.98.219]) by rrzd1 (MailMonitor for SMTP v1.2.2 ) ; Tue, 27 Apr 2004 12:33:44 +0200 (CEST) Subject: Re: Not enough memory for xfs_repair From: Christian Guggenberger Reply-To: christian.guggenberger@physik.uni-regensburg.de To: Torsten Wolf Cc: linux-xfs@oss.sgi.com In-Reply-To: <20040427093542.GB1440@sycorax> References: <20040426134329.GA4617@sycorax> <408D8370.2080702@mailcan.com> <20040427093542.GB1440@sycorax> Content-Type: text/plain Message-Id: <1083062025.3431.3.camel@pc9391> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 27 Apr 2004 12:33:45 +0200 Content-Transfer-Encoding: 7bit X-archive-position: 2929 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: christian.guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs Content-Length: 617 Lines: 21 On Tue, 2004-04-27 at 11:35, Torsten Wolf wrote: > Hello Leon, > > On Mo, 26 Apr 2004, Leon Woestenberg wrote: > > >Wouldn't it be better to attach the disk on another machine, and then > >see what can be done? > > Yes, indeed. Attached to a more robust machine xfs_repair stopped at the > same position followed by this dmesg output: > > __alloc_pages: 0-order allocation failed (gfp=0x1d2/0) several people experienced this, as seen on lkml. (not only with xfs) Could you go for a try with 2.4.26 ? (try with the oom killer first, then, if it still not works, without the oom killer enabled) - Christian From owner-linux-xfs@oss.sgi.com Tue Apr 27 07:48:17 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 27 Apr 2004 07:48:33 -0700 (PDT) Received: from rzcomm7.rz.tu-bs.de (rzcomm7.rz.tu-bs.de [134.169.9.53]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3REmGKO025227 for ; Tue, 27 Apr 2004 07:48:17 -0700 Received: from localhost (localhost [127.0.0.1]) by rzcomm7.rz.tu-bs.de (8.11.1/8.11.1) with ESMTP id i3REmFi12102 for ; Tue, 27 Apr 2004 16:48:15 +0200 (METDST) Received: from unknown ([127.0.0.1]) by localhost (rzcomm7 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11677-01-7 for ; Tue, 27 Apr 2004 16:48:14 +0200 (METDST) Received: from rzcomm12.rz.tu-bs.de (rzcomm12.rz.tu-bs.de [134.169.9.59]) by rzcomm7.rz.tu-bs.de (8.11.1/8.11.1) with ESMTP id i3REjS611671 for ; Tue, 27 Apr 2004 16:45:28 +0200 (METDST) Received: from rhea.strm.ing.tu-bs.de (rhea.strm.ing.tu-bs.de [134.169.46.7]) by rzcomm12.rz.tu-bs.de (8.11.1/8.11.1) with ESMTP id i3REjR813818 for ; Tue, 27 Apr 2004 16:45:27 +0200 (METDST) Received: by rhea.strm.ing.tu-bs.de (Postfix, from userid 5239) id 4A9EE568016; Tue, 27 Apr 2004 16:45:27 +0200 (CEST) Date: Tue, 27 Apr 2004 16:45:27 +0200 From: Torsten Wolf To: linux-xfs@oss.sgi.com Subject: Re: Not enough memory for xfs_repair Message-ID: <20040427144526.GA3887@gaia> Reply-To: Torsten Wolf References: <20040426134329.GA4617@sycorax> <408D8370.2080702@mailcan.com> <20040427093542.GB1440@sycorax> <1083062025.3431.3.camel@pc9391> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1083062025.3431.3.camel@pc9391> X-Mailer: Mutt http://www.mutt.org/ Organization: TU Braunschweig X-Editor: Vim http://www.vim.org/ X-OpenPGP-Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xEE27B69C X-Fingerprint: 24EE 9FD9 5333 0206 541F 4602 C6A4 5F61 EE27 B69C X-Uptime: 15:38:31 up 6:31, 6 users, load average: 0.08, 0.02, 0.01 User-Agent: Mutt/1.5.5.1+cvs20040105i X-Virus-Scanned: by amavisd-new at tu-bs.de X-archive-position: 2930 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: t.wolf@tu-bs.de Precedence: bulk X-list: linux-xfs Content-Length: 879 Lines: 25 On Di, 27 Apr 2004, Christian Guggenberger wrote: >On Tue, 2004-04-27 at 11:35, Torsten Wolf wrote: >> >> __alloc_pages: 0-order allocation failed (gfp=0x1d2/0) > >several people experienced this, as seen on lkml. (not only with xfs) >Could you go for a try with 2.4.26 ? (try with the oom killer first, >then, if it still not works, without the oom killer enabled) With oom killer enabled, I get Apr 27 16:36:31 sycorax kernel: Out of Memory: Killed process 1281 (xfs_repair). while without oom killer the kernel message is the same as above. And yes, both runs again on the flaky machine as there is no box around I could update to 2.4.26. But let me ask a more fundamental question: Is this the normal behaviour of xfs_repair to allocate such an amount of memory? Is there a way to estimate how much memory is needed to recover a damaged filesystem? Regards, Torsten From owner-linux-xfs@oss.sgi.com Tue Apr 27 08:05:06 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 27 Apr 2004 08:05:11 -0700 (PDT) Received: from stargate.coplanar.net (CPE0080c8c9b431-CM014280010574.cpe.net.cable.rogers.com [24.112.162.124]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3RF52KO025920 for ; Tue, 27 Apr 2004 08:05:05 -0700 Received: from coplanar.net (bridge.skynet.coplanar.net [192.168.7.10]) (authenticated bits=0) by stargate.coplanar.net (8.12.3/8.12.3/Debian-6.6) with ESMTP id i3RF4xYu020714 for ; Tue, 27 Apr 2004 11:04:59 -0400 Message-ID: <408E76B0.3020202@coplanar.net> Date: Tue, 27 Apr 2004 11:05:20 -0400 From: Jeremy Jackson Organization: Coplanar Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040122 Debian/1.6-1 X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Oops advice request 2.4.23 Content-Type: multipart/mixed; boundary="------------040202060807040802040101" Received-SPF: pass (stargate.coplanar.net: domain of jerj@coplanar.net designates 192.168.7.10 as SASL permitted sender) X-archive-position: 2931 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jerj@coplanar.net Precedence: bulk X-list: linux-xfs Content-Length: 4873 Lines: 116 This is a multi-part message in MIME format. --------------040202060807040802040101 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, I'm running linux 2.4.23 + XFS 2003-12-01_00:33_UTC snapshot, with EVMS. Debian 3.0 gcc 2.95 I had another oops, after 50 days uptime on an ancient Compaq Proliant 1500 dual PI-100 Suggestions? I will be upgrading to newer kernel/XFS soon, just wondering if this Oops looks like an area of code that has been fixed recently. Regards, Jeremy -- Jeremy Jackson Coplanar Networks (519)897-1516 http://www.coplanar.net --------------040202060807040802040101 Content-Type: text/plain; name="oops.out" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="oops.out" ksymoops 2.4.5 on i586 2.4.23-jerj1-686-smp. Options used -v vmlinux (specified) -k ksyms (specified) -l lsmod (specified) -o /lib/modules/2.4.23-jerj1-686-smp/ (default) -m /boot/System.map-2.4.23-jerj1-686-smp (specified) -S -i SGI XFS snapshot-2.4.23-2003-12-01_00:33_UTC with ACLs, debug enabled __alloc_pages: 4-order allocation failed (gfp=0xf0/0) __alloc_pages: 4-order allocation failed (gfp=0xf0/0) __alloc_pages: 4-order allocation failed (gfp=0xf0/0) __alloc_pages: 4-order allocation failed (gfp=0xf0/0) __alloc_pages: 4-order allocation failed (gfp=0xf0/0) __alloc_pages: 4-order allocation failed (gfp=0xf0/0) __alloc_pages: 4-order allocation failed (gfp=0xf0/0) __alloc_pages: 4-order allocation failed (gfp=0xf0/0) __alloc_pages: 4-order allocation failed (gfp=0xf0/0) __alloc_pages: 4-order allocation failed (gfp=0xf0/0) __alloc_pages: 4-order allocation failed (gfp=0xf0/0) XFS assertion failed: xfs_bmbt_disk_get_startoff(r1) + xfs_bmbt_disk_get_blockcount(r1) <= xfs_bmbt_disk_get_startoff(r2), file: xfs_btree.c, line: 287 kernel BUG at debug.c:55! invalid operand: 0000 CPU: 1 EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010286 eax: 00000098 ebx: 9031239b ecx: 00000046 edx: 00000001 esi: 002a3432 edi: c19e5fe8 ebp: c09eb018 esp: c1effac0 ds: 0018 es: 0018 ss: 0018 Process procmail (pid: 17462, stackpage=c1eff000) Stack: c03a3700 c03923a0 c0391f70 0000011f c01c398d c03923a0 c0391f70 0000011f c19e5fe8 c09eb018 c09eb018 000000fe c01bdde4 00000002 c19e5fe8 c09eb018 00000005 00000000 00000000 c172f3c0 c09ebfe8 00013771 00000001 c19e5fe8 [] xfs_btree_check_rec+0x149/0x154 [kernel] [] xfs_bmap_check_leaf_extents+0x310/0x484 [kernel] [] xfs_bmap_add_extent+0x521/0x538 [kernel] [] xfs_bmapi+0x9bd/0x1654 [kernel] [] xfs_bmap_search_extents+0x4c/0x54 [kernel] [] xfs_iomap_write_allocate+0x27f/0x410 [kernel] [] xfs_iomap+0x281/0x454 [kernel] [] xfs_iunlock+0x1d9/0x1e0 [kernel] [] xfs_iomap+0x39b/0x454 [kernel] [] xfs_bmap+0xa1/0xa8 [kernel] [] map_blocks+0x79/0xd4 [kernel] [] page_state_convert+0x279/0x50c [kernel] [] generic_make_request+0x128/0x138 [kernel] [] submit_bh+0x70/0xf8 [kernel] [] linvfs_writepage+0xbb/0x104 [kernel] [] fsync_buffers_list+0xc3/0x18c [kernel] [] fs_flush_pages+0x53/0x230 [kernel] [] xfs_fsync+0x18f/0x2bc [kernel] [] linvfs_fsync+0x5b/0x64 [kernel] [] sys_fsync+0x68/0xac [kernel] [] system_call+0x33/0x40 [kernel] Code: 0f 0b 37 00 2e 37 3a c0 83 c4 10 c3 8d 76 00 53 8b 1d a0 b4 >>EIP; c021d6d9 <===== >>ebx; 9031239b Before first symbol >>esi; 002a3432 Before first symbol >>edi; c19e5fe8 <_end+1450548/2286560> >>ebp; c09eb018 <_end+455578/2286560> >>esp; c1effac0 <_end+196a020/2286560> Code; c021d6d9 00000000 <_EIP>: Code; c021d6d9 0: 0f 0b ud2a <===== Code; c021d6db 2: 37 aaa Code; c021d6dc 3: 00 2e add %ch,(%esi) Code; c021d6de 5: 37 aaa Code; c021d6df 6: 3a c0 cmp %al,%al Code; c021d6e1 8: 83 c4 10 add $0x10,%esp Code; c021d6e4 b: c3 ret Code; c021d6e5 c: 8d 76 00 lea 0x0(%esi),%esi Code; c021d6e8 f: 53 push %ebx Code; c021d6e9 10: 8b 1d a0 b4 00 00 mov 0xb4a0,%ebx --------------040202060807040802040101-- From owner-linux-xfs@oss.sgi.com Tue Apr 27 08:57:06 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 27 Apr 2004 08:57:11 -0700 (PDT) Received: from zok.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3RFv6KO000359 for ; Tue, 27 Apr 2004 08:57:06 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i3RFuwhv018817 for ; Tue, 27 Apr 2004 08:56:58 -0700 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i3RFuvKe37650950; Tue, 27 Apr 2004 10:56:57 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i3RFuuHO976033; Tue, 27 Apr 2004 10:56:56 -0500 (CDT) Subject: Re: Not enough memory for xfs_repair From: Eric Sandeen To: Torsten Wolf Cc: linux-xfs@oss.sgi.com In-Reply-To: <20040427144526.GA3887@gaia> References: <20040426134329.GA4617@sycorax> <408D8370.2080702@mailcan.com> <20040427093542.GB1440@sycorax> <1083062025.3431.3.camel@pc9391> <20040427144526.GA3887@gaia> Content-Type: text/plain Organization: Eric Conspiracy Secret Labs Message-Id: <1083081415.14273.12.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 27 Apr 2004 10:56:56 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 2933 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2200 Lines: 58 Torsten - xfs_repair can indeed take a lot of memory, although I don't have a good rule of thumb for how much it might take for a given filesystem. 3G does seem excessive, but you have 200G of "very small files" so there may be a lot of data to work with. It's possible that there are memory leaks in repair that cause it to use more than necessary; I suppose it's also possible that the filesystem is corrupt in such a way that repair is getting confused and going off "in the weeds" allocating memory in a broken loop or something, hard to say without a debugger. I fixed a few memory leaks in 2.6.4, and you're using 2.6.5, so at least you have those. for now, I'd suggest creating a whole lot of swap and give it another go; it would be nice to be able to watch xfs_repair work on this filesystem to see what it's doing. You might also get the very latest xfsprogs (2.6.10 I think). just to get an idea of what your filesystem looks like, could you unmount it and run this command to print out some of the superblock information? xfs_db -r -c "sb 0" -c "p" /dev/ Thanks, -Eric On Tue, 2004-04-27 at 09:45, Torsten Wolf wrote: > On Di, 27 Apr 2004, Christian Guggenberger wrote: > > >On Tue, 2004-04-27 at 11:35, Torsten Wolf wrote: > >> > >> __alloc_pages: 0-order allocation failed (gfp=0x1d2/0) > > > >several people experienced this, as seen on lkml. (not only with xfs) > >Could you go for a try with 2.4.26 ? (try with the oom killer first, > >then, if it still not works, without the oom killer enabled) > > With oom killer enabled, I get > > Apr 27 16:36:31 sycorax kernel: Out of Memory: Killed process 1281 (xfs_repair). > > while without oom killer the kernel message is the same as above. And > yes, both runs again on the flaky machine as there is no box around I > could update to 2.4.26. > > But let me ask a more fundamental question: Is this the normal behaviour > of xfs_repair to allocate such an amount of memory? Is there a way to > estimate how much memory is needed to recover a damaged filesystem? > > Regards, > Torsten -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Tue Apr 27 09:51:38 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 27 Apr 2004 09:51:53 -0700 (PDT) Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3RGpaKO003273 for ; Tue, 27 Apr 2004 09:51:37 -0700 Received: (qmail 30053 invoked by uid 65534); 27 Apr 2004 16:51:30 -0000 Received: from 80-218-13-183.dclient.hispeed.ch (EHLO vaio.gigerstyle.ch) (80.218.13.183) by mail.gmx.net (mp022) with SMTP; 27 Apr 2004 18:51:30 +0200 X-Authenticated: #1226656 Date: Tue, 27 Apr 2004 18:51:24 +0200 From: Marc Giger To: Marc Giger Cc: Ivan Kokshaysky , linux-xfs@oss.sgi.com, =?ISO-8859-1?Q?M=E5ns_Rullg=E5rd?= , linux-kernel@vger.kernel.org Subject: Re: status of Linux on Alpha? Message-Id: <20040427185124.134073cd@vaio.gigerstyle.ch> In-Reply-To: <20040413194907.7ce8ceb7@vaio.gigerstyle.ch> References: <20040328201719.A14868@jurassic.park.msu.ru> <20040328204308.C14868@jurassic.park.msu.ru> <20040328221806.7fa20502@vaio.gigerstyle.ch> <20040329205233.5b7905aa@vaio.gigerstyle.ch> <20040404121032.7bb42b35@vaio.gigerstyle.ch> <20040409134534.67805dfd@vaio.gigerstyle.ch> <20040409134828.0e2984e5@vaio.gigerstyle.ch> <20040409230651.A727@den.park.msu.ru> <20040413194907.7ce8ceb7@vaio.gigerstyle.ch> X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2936 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gigerstyle@gmx.ch Precedence: bulk X-list: linux-xfs Content-Length: 1870 Lines: 63 Hi, What's the current status of the problem? Is nobody interested to fix it, or am I just impatient? Did I provide not enough information? I'm running 2.6.5 with the reverted patch for 2 weeks now without any problems. Regards Marc On Tue, 13 Apr 2004 19:49:07 +0200 Marc Giger wrote: > Hi Ivan, All > > First, sorry for the cross posting... > > After long sessions of patching, recompiling, and testing I finally > found the cause of my problems. XFS people, please read: > http://marc.theaimsgroup.com/?l=linux-kernel&m=108047692409817&w=2 > and > http://marc.theaimsgroup.com/?l=linux-kernel&m=107910319729364&w=2 > > After reverting 1.1608.29.12 all is fine again. > Interestingly, this patch was listed on bkbits between 2.6.3 > and 2.6.4-rc1 but was added to the source tree between 2.6.4-rc1 and > 2.6.4-rc2 :-( Again something learned for the future... > > Ivan, I think your new semaphore code is still ok because it doesn't > matter if it is the new or old code. Both versions have a problem with > the xfs-patch. > > For further questions you know how to reach me:-) > > greets > > Marc > > > On Fri, 9 Apr 2004 23:06:51 +0400 > Ivan Kokshaysky wrote: > > > On Fri, Apr 09, 2004 at 01:48:28PM +0200, Marc Giger wrote: > > > > Presently, I reached a stage on which I don't know longer what > > > > to do:-( I isolated the problem between 2.6.3-rc1 and 2.6.3-rc2. > > > > I > > > ^^^^^^^^^^^^^^^^^^^^^^^ > > > read as 2.6.4-rc1 and 2.6.4-rc2 > > > > Thanks for your work. > > > > > > also reverted 1.1608.56.1 , 1.1608.51.36 and all xfs related > > > > patches from rc2 with no luck. > > > > All other changes seems unrelated to me. > > > > I'd also revert 1.1608.51.22 and all networking changes. > > > > Ivan. > > > > From owner-linux-xfs@oss.sgi.com Tue Apr 27 10:25:29 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 27 Apr 2004 10:25:32 -0700 (PDT) Received: from zok.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3RHPRKO004579 for ; Tue, 27 Apr 2004 10:25:27 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i3RHNNhv002903 for ; Tue, 27 Apr 2004 10:23:23 -0700 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i3RHNMKe37610516; Tue, 27 Apr 2004 12:23:22 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i3RHNMHO1005175; Tue, 27 Apr 2004 12:23:22 -0500 (CDT) Subject: Re: status of Linux on Alpha? From: Eric Sandeen To: Marc Giger Cc: Ivan Kokshaysky , linux-xfs@oss.sgi.com, =?ISO-8859-1?Q?M=E5ns_Rullg=E5rd?= , LKML In-Reply-To: <20040427185124.134073cd@vaio.gigerstyle.ch> References: <20040328201719.A14868@jurassic.park.msu.ru> <20040328204308.C14868@jurassic.park.msu.ru> <20040328221806.7fa20502@vaio.gigerstyle.ch> <20040329205233.5b7905aa@vaio.gigerstyle.ch> <20040404121032.7bb42b35@vaio.gigerstyle.ch> <20040409134534.67805dfd@vaio.gigerstyle.ch> <20040409134828.0e2984e5@vaio.gigerstyle.ch> <20040409230651.A727@den.park.msu.ru> <20040413194907.7ce8ceb7@vaio.gigerstyle.ch> <20040427185124.134073cd@vaio.gigerstyle.ch> Content-Type: text/plain Organization: Eric Conspiracy Secret Labs Message-Id: <1083086601.14273.45.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 27 Apr 2004 12:23:22 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 2938 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 596 Lines: 26 Marc, do you have a patch associated with the changeset you found to be the culprit? I don't know how to get from that changeset number to a diff. Thanks, -Eric On Tue, 2004-04-27 at 11:51, Marc Giger wrote: > Hi, > > What's the current status of the problem? Is nobody interested to fix > it, or am I just impatient? Did I provide not enough information? > I'm running 2.6.5 with the reverted patch for 2 weeks now without any > problems. > > Regards > > Marc > -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Tue Apr 27 10:24:58 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 27 Apr 2004 10:25:04 -0700 (PDT) Received: from hptimail01.HPTI.COM ([208.20.6.201]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3RHOvKO004527 for ; Tue, 27 Apr 2004 10:24:57 -0700 Received: from hpti9.fsl.noaa.gov ([137.75.132.229]) by hptimail01.HPTI.COM with Microsoft SMTPSVC(6.0.3790.0); Tue, 27 Apr 2004 13:24:55 -0400 Subject: Using debug and tracing features in 2.4.26 From: Craig Tierney To: linux-xfs@oss.sgi.com Content-Type: text/plain Message-Id: <1083086648.2374.15.camel@hpti9.fsl.noaa.gov> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Tue, 27 Apr 2004 11:24:08 -0600 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Apr 2004 17:24:56.0348 (UTC) FILETIME=[8F363DC0:01C42C7C] X-archive-position: 2937 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ctierney@HPTI.com Precedence: bulk X-list: linux-xfs Content-Length: 567 Lines: 24 I have enabled debugging and tracing features in XFS using the 2.4.26 kernel. When I load the xfs module, it reports that tracing and debugging are enabled. (From dmesg) SGI XFS with tracing, debug enabled SGI XFS Quota Management subsystem To enable tracing, the Configure.help file says to set /proc/sys/vm/pagebuf/debug. However, I could not find this sysctl, or anything that was similar in the /proc/fs/xfs or /proc/sys/fs/xfs directories. How do I turn this on? Also, with debugging enabled, do all debug messages go to the kernel log? Thanks, Craig From owner-linux-xfs@oss.sgi.com Tue Apr 27 10:55:25 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 27 Apr 2004 10:55:32 -0700 (PDT) Received: from jurassic.park.msu.ru (jurassic.park.msu.ru [195.208.223.243]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3RHtNKO006158 for ; Tue, 27 Apr 2004 10:55:24 -0700 Received: from den.park.msu.ru (den.park.msu.ru [212.192.253.17]) by jurassic.park.msu.ru (8.11.6/8.11.6) with ESMTP id i3RHsoJ15089; Tue, 27 Apr 2004 21:54:50 +0400 Received: (from ink@localhost) by den.park.msu.ru (8.11.6/8.11.6) id i3RHtFt00815; Tue, 27 Apr 2004 21:55:15 +0400 Date: Tue, 27 Apr 2004 21:55:14 +0400 From: Ivan Kokshaysky To: Marc Giger Cc: Dru , linux-xfs@oss.sgi.com, =?koi8-r?Q?M=E5ns_Rullg=E5rd?= , linux-kernel@vger.kernel.org Subject: Re: status of Linux on Alpha? Message-ID: <20040427215514.A651@den.park.msu.ru> References: <20040328204308.C14868@jurassic.park.msu.ru> <20040328221806.7fa20502@vaio.gigerstyle.ch> <20040329205233.5b7905aa@vaio.gigerstyle.ch> <20040404121032.7bb42b35@vaio.gigerstyle.ch> <20040409134534.67805dfd@vaio.gigerstyle.ch> <20040409134828.0e2984e5@vaio.gigerstyle.ch> <20040409230651.A727@den.park.msu.ru> <20040413194907.7ce8ceb7@vaio.gigerstyle.ch> <20040427185124.134073cd@vaio.gigerstyle.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20040427185124.134073cd@vaio.gigerstyle.ch>; from gigerstyle@gmx.ch on Tue, Apr 27, 2004 at 06:51:24PM +0200 X-archive-position: 2939 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ink@jurassic.park.msu.ru Precedence: bulk X-list: linux-xfs Content-Length: 926 Lines: 33 On Tue, Apr 27, 2004 at 06:51:24PM +0200, Marc Giger wrote: > What's the current status of the problem? Hopefully resolved - thanks to Dru , who provided an easy way to reproduce the problem. What we have in lib/rwsem.c:__rwsem_do_wake(): int woken, loop; ^^^ and several lines below: loop = woken; woken *= RWSEM_ACTIVE_BIAS-RWSEM_WAITING_BIAS; woken -= RWSEM_ACTIVE_BIAS; However, rw_semaphore->count is 64-bit on Alpha, so RWSEM_WAITING_BIAS has been defined as -0x0000000100000000L. Obviously, this blows up in the write contention case. Ivan. --- linux.orig/lib/rwsem.c Mon Apr 26 20:11:36 2004 +++ linux/lib/rwsem.c Tue Apr 27 20:04:14 2004 @@ -40,8 +40,7 @@ static inline struct rw_semaphore *__rws { struct rwsem_waiter *waiter; struct list_head *next; - signed long oldcount; - int woken, loop; + signed long oldcount, woken, loop; rwsemtrace(sem,"Entering __rwsem_do_wake"); From owner-linux-xfs@oss.sgi.com Tue Apr 27 10:57:30 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 27 Apr 2004 10:57:35 -0700 (PDT) Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3RHvTKO006509 for ; Tue, 27 Apr 2004 10:57:29 -0700 Received: (qmail 24419 invoked by uid 65534); 27 Apr 2004 17:57:22 -0000 Received: from 80-218-13-183.dclient.hispeed.ch (EHLO vaio.gigerstyle.ch) (80.218.13.183) by mail.gmx.net (mp016) with SMTP; 27 Apr 2004 19:57:22 +0200 X-Authenticated: #1226656 Date: Tue, 27 Apr 2004 19:57:21 +0200 From: Marc Giger To: Eric Sandeen Cc: Ivan Kokshaysky , linux-xfs@oss.sgi.com, =?ISO-8859-1?Q?M=E5ns_Rullg=E5rd?= , LKML Subject: Re: status of Linux on Alpha? Message-Id: <20040427195721.10931425@vaio.gigerstyle.ch> In-Reply-To: <1083086601.14273.45.camel@stout.americas.sgi.com> References: <20040328201719.A14868@jurassic.park.msu.ru> <20040328204308.C14868@jurassic.park.msu.ru> <20040328221806.7fa20502@vaio.gigerstyle.ch> <20040329205233.5b7905aa@vaio.gigerstyle.ch> <20040404121032.7bb42b35@vaio.gigerstyle.ch> <20040409134534.67805dfd@vaio.gigerstyle.ch> <20040409134828.0e2984e5@vaio.gigerstyle.ch> <20040409230651.A727@den.park.msu.ru> <20040413194907.7ce8ceb7@vaio.gigerstyle.ch> <20040427185124.134073cd@vaio.gigerstyle.ch> <1083086601.14273.45.camel@stout.americas.sgi.com> X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2940 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gigerstyle@gmx.ch Precedence: bulk X-list: linux-xfs Content-Length: 11464 Lines: 453 Hi Eric, On 27 Apr 2004 12:23:22 -0500 Eric Sandeen wrote: > Marc, do you have a patch associated with the changeset you found to > be the culprit? > > I don't know how to get from that changeset number to a diff. Yep, you will find all changesets and the belonging patches on http://linux.bkbits.net:8080/linux-2.5 Reverting the following patch and all is fine... # This is a BitKeeper generated diff -Nru style patch. # # ChangeSet # 2004/02/27 18:17:12+11:00 nathans@sgi.com # [XFS] Implement mrlocks on top of rwsems, instead of using our own mrlock code.# # SGI Modid: xfs-linux:xfs-kern:167181a # # BitKeeper/deleted/.del-mrlock.c~4fd914a7832bd60d # 2004/02/27 18:16:18+11:00 nathans@sgi.com +0 -0 # Delete: fs/xfs/linux/mrlock.c # # fs/xfs/Makefile # 2004/02/27 18:16:53+11:00 nathans@sgi.com +0 -1 # [XFS] Implement mrlocks on top of rwsems, instead of using our own mrlock code.# # fs/xfs/linux/mrlock.h # 2004/02/27 18:16:53+11:00 nathans@sgi.com +62 -45 # [XFS] Implement mrlocks on top of rwsems, instead of using our own mrlock code.# diff -Nru a/fs/xfs/Makefile b/fs/xfs/Makefile --- a/fs/xfs/Makefile Mon Apr 12 08:43:27 2004 +++ b/fs/xfs/Makefile Mon Apr 12 08:43:27 2004 @@ -130,7 +130,6 @@ # Objects in linux/ xfs-y += $(addprefix linux/, \ - mrlock.o \ xfs_aops.o \ xfs_buf.o \ xfs_file.o \ diff -Nru a/fs/xfs/linux/mrlock.c b/fs/xfs/linux/mrlock.c --- a/fs/xfs/linux/mrlock.c Mon Apr 12 08:43:27 2004 +++ /dev/null Wed Dec 31 16:00:00 1969 @@ -1,274 +0,0 @@ -/* - * Copyright (c) 2000-2003 Silicon Graphics, Inc. All Rights Reserved. - * - * This program is free software; you can redistribute it and/or modify it- * under the terms of version 2 of the GNU General Public License as - * published by the Free Software Foundation. - * - * This program is distributed in the hope that it would be useful, but - * WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. - * - * Further, this software is distributed without any warranty that it is- * free of the rightful claim of any third person regarding infringement- * or the like. Any license provided herein, whether implied or- * otherwise, applies only to this software file. Patent licenses, if- * any, provided herein do not apply to combinations of this program with- * other software, or any other product whatsoever. - * - * You should have received a copy of the GNU General Public License along- * with this program; if not, write the Free Software Foundation, Inc., 59- * Temple Place - Suite 330, Boston MA 02111-1307, USA. - * - * Contact information: Silicon Graphics, Inc., 1600 Amphitheatre Pkwy, - * Mountain View, CA 94043, or: - * - * http://www.sgi.com - * - * For further information regarding this notice, see: - * - * http://oss.sgi.com/projects/GenInfo/SGIGPLNoticeExplan/ - */ - -#include -#include -#include -#include -#include - -#include "mrlock.h" - - -#if USE_RW_WAIT_QUEUE_SPINLOCK -# define wq_write_lock write_lock -#else -# define wq_write_lock spin_lock -#endif - -/* - * We don't seem to need lock_type (only one supported), name, or - * sequence. But, XFS will pass it so let's leave them here for now. - */ -/* ARGSUSED */ -void -mrlock_init(mrlock_t *mrp, int lock_type, char *name, long sequence) -{ - mrp->mr_count = 0; - mrp->mr_reads_waiting = 0; - mrp->mr_writes_waiting = 0; - init_waitqueue_head(&mrp->mr_readerq); - init_waitqueue_head(&mrp->mr_writerq); - mrp->mr_lock = SPIN_LOCK_UNLOCKED; -} - -/* - * Macros to lock/unlock the mrlock_t. - */ - -#define MRLOCK(m) spin_lock(&(m)->mr_lock); -#define MRUNLOCK(m) spin_unlock(&(m)->mr_lock); - - -/* - * lock_wait should never be called in an interrupt thread. - * - * mrlocks can sleep (i.e. call schedule) and so they can't ever - * be called from an interrupt thread. - * - * threads that wake-up should also never be invoked from interrupt threads.- * - * But, waitqueue_lock is locked from interrupt threads - and we are - * called with interrupts disabled, so it is all OK. - */ - -/* ARGSUSED */ -void -lock_wait(wait_queue_head_t *q, spinlock_t *lock, int rw) -{ - DECLARE_WAITQUEUE( wait, current ); - - __set_current_state(TASK_UNINTERRUPTIBLE); - - spin_lock(&q->lock); - if (rw) { - __add_wait_queue_tail(q, &wait); - } else { - __add_wait_queue(q, &wait); - } - - spin_unlock(&q->lock); - spin_unlock(lock); - - schedule(); - - spin_lock(&q->lock); - __remove_wait_queue(q, &wait); - spin_unlock(&q->lock); - - spin_lock(lock); - - /* return with lock held */ -} - -/* ARGSUSED */ -void -mrfree(mrlock_t *mrp) -{ -} - -/* ARGSUSED */ -void -mrlock(mrlock_t *mrp, int type, int flags) -{ - if (type == MR_ACCESS) - mraccess(mrp); - else - mrupdate(mrp); -} - -/* ARGSUSED */ -void -mraccessf(mrlock_t *mrp, int flags) -{ - MRLOCK(mrp); - if(mrp->mr_writes_waiting > 0) { - mrp->mr_reads_waiting++; - lock_wait(&mrp->mr_readerq, &mrp->mr_lock, 0); - mrp->mr_reads_waiting--; - } - while (mrp->mr_count < 0) { - mrp->mr_reads_waiting++; - lock_wait(&mrp->mr_readerq, &mrp->mr_lock, 0); - mrp->mr_reads_waiting--; - } - mrp->mr_count++; - MRUNLOCK(mrp); -} - -/* ARGSUSED */ -void -mrupdatef(mrlock_t *mrp, int flags) -{ - MRLOCK(mrp); - while(mrp->mr_count) { - mrp->mr_writes_waiting++; - lock_wait(&mrp->mr_writerq, &mrp->mr_lock, 1); - mrp->mr_writes_waiting--; - } - - mrp->mr_count = -1; /* writer on it */ - MRUNLOCK(mrp); -} - -int -mrtryaccess(mrlock_t *mrp) -{ - MRLOCK(mrp); - /* - * If anyone is waiting for update access or the lock is held for update- * fail the request. - */ - if(mrp->mr_writes_waiting > 0 || mrp->mr_count < 0) { - MRUNLOCK(mrp); - return 0; - } - mrp->mr_count++; - MRUNLOCK(mrp); - return 1; -} - -int -mrtrypromote(mrlock_t *mrp) -{ - MRLOCK(mrp); - - if(mrp->mr_count == 1) { /* We are the only thread with the lock */ - mrp->mr_count = -1; /* writer on it */ - MRUNLOCK(mrp); - return 1; - } - - MRUNLOCK(mrp); - return 0; -} - -int -mrtryupdate(mrlock_t *mrp) -{ - MRLOCK(mrp); - - if(mrp->mr_count) { - MRUNLOCK(mrp); - return 0; - } - - mrp->mr_count = -1; /* writer on it */ - MRUNLOCK(mrp); - return 1; -} - -static __inline__ void mrwake(mrlock_t *mrp) -{ - /* - * First, if the count is now 0, we need to wake-up anyone waiting. - */ - if (!mrp->mr_count) { - if (mrp->mr_writes_waiting) { /* Wake-up first writer waiting */- wake_up(&mrp->mr_writerq); - } else if (mrp->mr_reads_waiting) { /* Wakeup any readers waiting */- wake_up(&mrp->mr_readerq); - } - } -} - -void -mraccunlock(mrlock_t *mrp) -{ - MRLOCK(mrp); - mrp->mr_count--; - mrwake(mrp); - MRUNLOCK(mrp); -} - -void -mrunlock(mrlock_t *mrp) -{ - MRLOCK(mrp); - if (mrp->mr_count < 0) { - mrp->mr_count = 0; - } else { - mrp->mr_count--; - } - mrwake(mrp); - MRUNLOCK(mrp); -} - -int -ismrlocked(mrlock_t *mrp, int type) /* No need to lock since info can change */-{ - if (type == MR_ACCESS) - return (mrp->mr_count > 0); /* Read lock */ - else if (type == MR_UPDATE) - return (mrp->mr_count < 0); /* Write lock */ - else if (type == (MR_UPDATE | MR_ACCESS)) - return (mrp->mr_count); /* Any type of lock held */ - else /* Any waiters */ - return (mrp->mr_reads_waiting | mrp->mr_writes_waiting); -} - -/* - * Demote from update to access. We better be the only thread with the - * lock in update mode so it should be easy to set to 1. - * Wake-up any readers waiting. - */ - -void -mrdemote(mrlock_t *mrp) -{ - MRLOCK(mrp); - mrp->mr_count = 1; - if (mrp->mr_reads_waiting) { /* Wakeup all readers waiting */ - wake_up(&mrp->mr_readerq); - } - MRUNLOCK(mrp); -} diff -Nru a/fs/xfs/linux/mrlock.h b/fs/xfs/linux/mrlock.h --- a/fs/xfs/linux/mrlock.h Mon Apr 12 08:43:27 2004 +++ b/fs/xfs/linux/mrlock.h Mon Apr 12 08:43:27 2004 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2000-2003 Silicon Graphics, Inc. All Rights Reserved. + * Copyright (c) 2000-2004 Silicon Graphics, Inc. All Rights Reserved. * * This program is free software; you can redistribute it and/or modify it * under the terms of version 2 of the GNU General Public License as @@ -32,56 +32,73 @@ #ifndef __XFS_SUPPORT_MRLOCK_H__ #define __XFS_SUPPORT_MRLOCK_H__ -#include -#include -#include -#include +#include -/* - * Implement mrlocks on Linux that work for XFS. - * - * These are sleep locks and not spinlocks. If one wants read/write spinlocks,- * use read_lock, write_lock, ... see spinlock.h. - */ +enum { MR_NONE, MR_ACCESS, MR_UPDATE }; -typedef struct mrlock_s { - int mr_count; - unsigned short mr_reads_waiting; - unsigned short mr_writes_waiting; - wait_queue_head_t mr_readerq; - wait_queue_head_t mr_writerq; - spinlock_t mr_lock; +typedef struct { + struct rw_semaphore mr_lock; + int mr_writer; } mrlock_t; -#define MR_ACCESS 1 -#define MR_UPDATE 2 - -#define MRLOCK_BARRIER 0x1 -#define MRLOCK_ALLOW_EQUAL_PRI 0x8 +#define mrinit(mrp, name) \ + ( (mrp)->mr_writer = 0, init_rwsem(&(mrp)->mr_lock) ) +#define mrlock_init(mrp, t,n,s) mrinit(mrp, n) +#define mrfree(mrp) do { } while (0) +#define mraccess(mrp) mraccessf(mrp, 0) +#define mrupdate(mrp) mrupdatef(mrp, 0) + +static inline void mraccessf(mrlock_t *mrp, int flags) +{ + down_read(&mrp->mr_lock); +} + +static inline void mrupdatef(mrlock_t *mrp, int flags) +{ + down_write(&mrp->mr_lock); + mrp->mr_writer = 1; +} + +static inline int mrtryaccess(mrlock_t *mrp) +{ + return down_read_trylock(&mrp->mr_lock); +} + +static inline int mrtryupdate(mrlock_t *mrp) +{ + if (!down_write_trylock(&mrp->mr_lock)) + return 0; + mrp->mr_writer = 1; + return 1; +} + +static inline void mrunlock(mrlock_t *mrp) +{ + if (mrp->mr_writer) { + mrp->mr_writer = 0; + up_write(&mrp->mr_lock); + } else { + up_read(&mrp->mr_lock); + } +} + +static inline void mrdemote(mrlock_t *mrp) +{ + mrp->mr_writer = 0; + downgrade_write(&mrp->mr_lock); +} /* - * mraccessf/mrupdatef take flags to be passed in while sleeping; - * only PLTWAIT is currently supported. + * Debug-only routine, without some platform-specific asm code, we can + * now only answer requests regarding whether we hold the lock for write+ * (reader state is outside our visibility, we only track writer state).+ * Note: means !ismrlocked would give false positivies, so don't do that. */ - -extern void mraccessf(mrlock_t *, int); -extern void mrupdatef(mrlock_t *, int); -extern void mrlock(mrlock_t *, int, int); -extern void mrunlock(mrlock_t *); -extern void mraccunlock(mrlock_t *); -extern int mrtryupdate(mrlock_t *); -extern int mrtryaccess(mrlock_t *); -extern int mrtrypromote(mrlock_t *); -extern void mrdemote(mrlock_t *); - -extern int ismrlocked(mrlock_t *, int); -extern void mrlock_init(mrlock_t *, int type, char *name, long sequence);-extern void mrfree(mrlock_t *); - -#define mrinit(mrp, name) mrlock_init(mrp, MRLOCK_BARRIER, name, -1) -#define mraccess(mrp) mraccessf(mrp, 0) /* grab for READ/ACCESS */ -#define mrupdate(mrp) mrupdatef(mrp, 0) /* grab for WRITE/UPDATE */ -#define mrislocked_access(mrp) ((mrp)->mr_count > 0) -#define mrislocked_update(mrp) ((mrp)->mr_count < 0) +static inline int ismrlocked(mrlock_t *mrp, int type) +{ + if (type == MR_UPDATE) + return mrp->mr_writer; + return 1; +} #endif /* __XFS_SUPPORT_MRLOCK_H__ */ From owner-linux-xfs@oss.sgi.com Tue Apr 27 11:08:39 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 27 Apr 2004 11:08:43 -0700 (PDT) Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3RI8cKO007162 for ; Tue, 27 Apr 2004 11:08:38 -0700 Received: (qmail 15307 invoked by uid 65534); 27 Apr 2004 18:08:32 -0000 Received: from 80-218-13-183.dclient.hispeed.ch (EHLO vaio.gigerstyle.ch) (80.218.13.183) by mail.gmx.net (mp013) with SMTP; 27 Apr 2004 20:08:32 +0200 X-Authenticated: #1226656 Date: Tue, 27 Apr 2004 20:08:30 +0200 From: Marc Giger To: Ivan Kokshaysky Cc: Dru , linux-xfs@oss.sgi.com, =?ISO-8859-1?Q?M=E5ns_?= =?ISO-8859-1?Q?Rullg=E5rd?= , linux-kernel@vger.kernel.org Subject: Re: status of Linux on Alpha? Message-Id: <20040427200830.3f485a54@vaio.gigerstyle.ch> In-Reply-To: <20040427215514.A651@den.park.msu.ru> References: <20040328204308.C14868@jurassic.park.msu.ru> <20040328221806.7fa20502@vaio.gigerstyle.ch> <20040329205233.5b7905aa@vaio.gigerstyle.ch> <20040404121032.7bb42b35@vaio.gigerstyle.ch> <20040409134534.67805dfd@vaio.gigerstyle.ch> <20040409134828.0e2984e5@vaio.gigerstyle.ch> <20040409230651.A727@den.park.msu.ru> <20040413194907.7ce8ceb7@vaio.gigerstyle.ch> <20040427185124.134073cd@vaio.gigerstyle.ch> <20040427215514.A651@den.park.msu.ru> X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2941 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gigerstyle@gmx.ch Precedence: bulk X-list: linux-xfs Content-Length: 1359 Lines: 54 Hi Ivan, Cool! I will try your patch after I finished moving to my new flat:-) I wonder why it happens only with the XFS code. What I saw rw_sem is used all over the place in the kernel. Thank you and Dru for the work and hopefully it will fix my problem. Regards Marc On Tue, 27 Apr 2004 21:55:14 +0400 Ivan Kokshaysky wrote: > On Tue, Apr 27, 2004 at 06:51:24PM +0200, Marc Giger wrote: > > What's the current status of the problem? > > Hopefully resolved - thanks to Dru , who provided > an easy way to reproduce the problem. > > What we have in lib/rwsem.c:__rwsem_do_wake(): > int woken, loop; > ^^^ > and several lines below: > loop = woken; > woken *= RWSEM_ACTIVE_BIAS-RWSEM_WAITING_BIAS; > woken -= RWSEM_ACTIVE_BIAS; > > However, rw_semaphore->count is 64-bit on Alpha, so > RWSEM_WAITING_BIAS has been defined as -0x0000000100000000L. > Obviously, this blows up in the write contention case. > > Ivan. > > --- linux.orig/lib/rwsem.c Mon Apr 26 20:11:36 2004 > +++ linux/lib/rwsem.c Tue Apr 27 20:04:14 2004 > @@ -40,8 +40,7 @@ static inline struct rw_semaphore *__rws > { > struct rwsem_waiter *waiter; > struct list_head *next; > - signed long oldcount; > - int woken, loop; > + signed long oldcount, woken, loop; > > rwsemtrace(sem,"Entering __rwsem_do_wake"); > > > From owner-linux-xfs@oss.sgi.com Tue Apr 27 11:57:56 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 27 Apr 2004 11:58:01 -0700 (PDT) Received: from localhost.localdomain (outgoingmail.adic.com [63.81.117.28]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3RIvsKO009022 for ; Tue, 27 Apr 2004 11:57:55 -0700 Received: from xfs.org (jen [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id i3RIqtvE022062; Tue, 27 Apr 2004 13:52:57 -0500 Message-ID: <408EAC06.7010404@xfs.org> Date: Tue, 27 Apr 2004 13:52:54 -0500 From: Steve Lord User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Craig Tierney CC: linux-xfs@oss.sgi.com Subject: Re: Using debug and tracing features in 2.4.26 References: <1083086648.2374.15.camel@hpti9.fsl.noaa.gov> In-Reply-To: <1083086648.2374.15.camel@hpti9.fsl.noaa.gov> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2942 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 942 Lines: 30 Craig Tierney wrote: > I have enabled debugging and tracing features in XFS > using the 2.4.26 kernel. When I load the xfs module, > it reports that tracing and debugging are enabled. > > (From dmesg) > SGI XFS with tracing, debug enabled > SGI XFS Quota Management subsystem > > To enable tracing, the Configure.help file says to set > /proc/sys/vm/pagebuf/debug. However, I could not find this > sysctl, or anything that was similar in the /proc/fs/xfs or > /proc/sys/fs/xfs directories. > > How do I turn this on? > > Also, with debugging enabled, do all debug messages go to the > kernel log? The tracing is to internal kernel buffers and is not much use unless you have a debugger capable of looking at them, which means kdb and the xfs support for kdb. Any reason for turning on debug? It adds thousands of checks to the code base, any one of them will oops if it triggers. Never run this way with data you care about. Steve From owner-linux-xfs@oss.sgi.com Tue Apr 27 13:08:44 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 27 Apr 2004 13:08:50 -0700 (PDT) Received: from zak.futurequest.net (zak.futurequest.net [69.5.6.152]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3RK8hKO014369 for ; Tue, 27 Apr 2004 13:08:44 -0700 Received: (qmail 19122 invoked from network); 27 Apr 2004 20:08:43 -0000 Received: from localhost ([127.0.0.1]) by zak.futurequest.net ([69.5.6.152]); 27 Apr 2004 20:08:43 -0000 Received: from bruce-guenter.dyndns.org (unknown [127.0.0.1]) by localhost ([127.0.0.1]) with SMTP via TCP; 27 Apr 2004 20:08:43 -0000 Received: (qmail 16620 invoked by uid 500); 27 Apr 2004 20:09:04 -0000 Date: Tue, 27 Apr 2004 14:09:04 -0600 From: Bruce Guenter To: linux-xfs@oss.sgi.com Subject: Re: Speeding up XFS Message-ID: <20040427200904.GA16349@em.ca> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20040426165155.GA19148@em.ca> <408D5A7F.1050108@xfs.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YZ5djTAD1cGYuMQK" Content-Disposition: inline In-Reply-To: <408D5A7F.1050108@xfs.org> User-Agent: Mutt/1.5.6i X-archive-position: 2944 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lists-linux-xfs@bruce-guenter.dyndns.org Precedence: bulk X-list: linux-xfs Content-Length: 1620 Lines: 42 --YZ5djTAD1cGYuMQK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 26, 2004 at 01:52:47PM -0500, Steve Lord wrote: > The very wierd part is the slowdown you see with an external journal > in the last case. I can see no reason why an external vs an internal > journal would be different except for the possibility that there > is some form of interaction with queue unplugging in the elevators > between devices. It might be worth trying Linus's latest bitkeeper > tree (2.6.6-rc2) which has per device queue unplugging and see > if that makes a difference. I have re-run the benchmarks using the 2.6.6-rc2-mm2 kernel. The slowdowns still happen, but they aren't as severe. > I attached a perl script. If you run this once a second and capture the > output when things are going bad it might tell us a few things. I saved the output to a directory, one file per second. It is available at http://untroubled.org/benchmarking/2004-04/xfs_stats.tar.bz2 The worse slowdowns (200ms average time to list+read+unlink the contents of a directory) occurred between 14:04:07 and 14:19:12. --=20 Bruce Guenter http://em.ca/~bruceg/ http://untroubled.org/ OpenPGP key: 699980E8 / D0B7 C8DD 365D A395 29DA 2E2A E96F B2DC 6999 80E8 --YZ5djTAD1cGYuMQK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAjr3g6W+y3GmZgOgRAtyXAJ44NaW1FhkCsMvD8yke8wPc7N/hDACgqBPb WfoExF8FckvwhwqopiUJorM= =gfce -----END PGP SIGNATURE----- --YZ5djTAD1cGYuMQK-- From owner-linux-xfs@oss.sgi.com Tue Apr 27 13:19:16 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 27 Apr 2004 13:19:23 -0700 (PDT) Received: from hptimail01.HPTI.COM ([208.20.6.201]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3RKJFKO016440 for ; Tue, 27 Apr 2004 13:19:15 -0700 Received: from hpti9.fsl.noaa.gov ([137.75.132.229]) by hptimail01.HPTI.COM with Microsoft SMTPSVC(6.0.3790.0); Tue, 27 Apr 2004 16:19:14 -0400 Subject: Re: Using debug and tracing features in 2.4.26 From: Craig Tierney To: Steve Lord Cc: linux-xfs@oss.sgi.com In-Reply-To: <408EAC06.7010404@xfs.org> References: <1083086648.2374.15.camel@hpti9.fsl.noaa.gov> <408EAC06.7010404@xfs.org> Content-Type: text/plain Message-Id: <1083097106.2374.37.camel@hpti9.fsl.noaa.gov> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Tue, 27 Apr 2004 14:18:26 -0600 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Apr 2004 20:19:14.0391 (UTC) FILETIME=[E8B0F670:01C42C94] X-archive-position: 2945 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ctierney@HPTI.com Precedence: bulk X-list: linux-xfs Content-Length: 1662 Lines: 50 On Tue, 2004-04-27 at 12:52, Steve Lord wrote: > Craig Tierney wrote: > > I have enabled debugging and tracing features in XFS > > using the 2.4.26 kernel. When I load the xfs module, > > it reports that tracing and debugging are enabled. > > > > (From dmesg) > > SGI XFS with tracing, debug enabled > > SGI XFS Quota Management subsystem > > > > To enable tracing, the Configure.help file says to set > > /proc/sys/vm/pagebuf/debug. However, I could not find this > > sysctl, or anything that was similar in the /proc/fs/xfs or > > /proc/sys/fs/xfs directories. > > > > How do I turn this on? > > > > Also, with debugging enabled, do all debug messages go to the > > kernel log? > > > The tracing is to internal kernel buffers and is not much use > unless you have a debugger capable of looking at them, which > means kdb and the xfs support for kdb. > > Any reason for turning on debug? It adds thousands of checks to > the code base, any one of them will oops if it triggers. Never > run this way with data you care about. > > Steve I am exporting my XFS filesystems over NFS. Under load we are seeing corruption on writes. Corruption is in multiples of 4KB, and are always paged aligned. I sent a post to the list last week: http://oss.sgi.com/archives/linux-xfs/2004-04/msg00180.html Besides that post, it happens when kernel is booted as "nosmp,noapic", and corruptions seems to happen more as the performance of the server goes up. I get more corruption for a given number of runs on a Dual 2.6Ghz Xeon than on a Dual 933Mhz PIII. I was able to generate corrupted output with debugging enabled, but no oopses occurred. Thanks, Craig From owner-linux-xfs@oss.sgi.com Tue Apr 27 13:20:19 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 27 Apr 2004 13:20:23 -0700 (PDT) Received: from jurassic.park.msu.ru (jurassic.park.msu.ru [195.208.223.243]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3RKKHKO016618 for ; Tue, 27 Apr 2004 13:20:18 -0700 Received: from den.park.msu.ru (den.park.msu.ru [212.192.253.17]) by jurassic.park.msu.ru (8.11.6/8.11.6) with ESMTP id i3RKJlJ15563; Wed, 28 Apr 2004 00:19:47 +0400 Received: (from ink@localhost) by den.park.msu.ru (8.11.6/8.11.6) id i3RKKIC00950; Wed, 28 Apr 2004 00:20:18 +0400 Date: Wed, 28 Apr 2004 00:20:18 +0400 From: Ivan Kokshaysky To: Marc Giger Cc: Dru , linux-xfs@oss.sgi.com, =?koi8-r?Q?M=E5ns_Rullg=E5rd?= , linux-kernel@vger.kernel.org Subject: Re: status of Linux on Alpha? Message-ID: <20040428002018.A827@den.park.msu.ru> References: <20040329205233.5b7905aa@vaio.gigerstyle.ch> <20040404121032.7bb42b35@vaio.gigerstyle.ch> <20040409134534.67805dfd@vaio.gigerstyle.ch> <20040409134828.0e2984e5@vaio.gigerstyle.ch> <20040409230651.A727@den.park.msu.ru> <20040413194907.7ce8ceb7@vaio.gigerstyle.ch> <20040427185124.134073cd@vaio.gigerstyle.ch> <20040427215514.A651@den.park.msu.ru> <20040427200830.3f485a54@vaio.gigerstyle.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20040427200830.3f485a54@vaio.gigerstyle.ch>; from gigerstyle@gmx.ch on Tue, Apr 27, 2004 at 08:08:30PM +0200 X-archive-position: 2946 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ink@jurassic.park.msu.ru Precedence: bulk X-list: linux-xfs Content-Length: 428 Lines: 12 On Tue, Apr 27, 2004 at 08:08:30PM +0200, Marc Giger wrote: > I wonder why it happens only with the XFS code. What I saw > rw_sem is used all over the place in the kernel. Dru says it happens with ext3 as well. XFS folks used their own locking code (which hasn't suffered from that bug) until 2.6.4, that's why you noticed the difference... In either case, you need _really_ heavy write IO activity to trigger the bug. Ivan. From owner-linux-xfs@oss.sgi.com Tue Apr 27 13:42:40 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 27 Apr 2004 13:42:44 -0700 (PDT) Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3RKgdKO017516 for ; Tue, 27 Apr 2004 13:42:39 -0700 Received: (qmail 5326 invoked by uid 65534); 27 Apr 2004 20:42:33 -0000 Received: from 80-218-13-183.dclient.hispeed.ch (EHLO vaio.gigerstyle.ch) (80.218.13.183) by mail.gmx.net (mp023) with SMTP; 27 Apr 2004 22:42:33 +0200 X-Authenticated: #1226656 Date: Tue, 27 Apr 2004 22:42:31 +0200 From: Marc Giger To: Ivan Kokshaysky Cc: Dru , linux-xfs@oss.sgi.com, =?ISO-8859-1?Q?M=E5ns_?= =?ISO-8859-1?Q?Rullg=E5rd?= , linux-kernel@vger.kernel.org Subject: Re: status of Linux on Alpha? Message-Id: <20040427224231.0e439344@vaio.gigerstyle.ch> In-Reply-To: <20040428002018.A827@den.park.msu.ru> References: <20040329205233.5b7905aa@vaio.gigerstyle.ch> <20040404121032.7bb42b35@vaio.gigerstyle.ch> <20040409134534.67805dfd@vaio.gigerstyle.ch> <20040409134828.0e2984e5@vaio.gigerstyle.ch> <20040409230651.A727@den.park.msu.ru> <20040413194907.7ce8ceb7@vaio.gigerstyle.ch> <20040427185124.134073cd@vaio.gigerstyle.ch> <20040427215514.A651@den.park.msu.ru> <20040427200830.3f485a54@vaio.gigerstyle.ch> <20040428002018.A827@den.park.msu.ru> X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2947 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gigerstyle@gmx.ch Precedence: bulk X-list: linux-xfs Content-Length: 888 Lines: 27 On Wed, 28 Apr 2004 00:20:18 +0400 Ivan Kokshaysky wrote: > On Tue, Apr 27, 2004 at 08:08:30PM +0200, Marc Giger wrote: > > I wonder why it happens only with the XFS code. What I saw > > rw_sem is used all over the place in the kernel. > > Dru says it happens with ext3 as well. XFS folks used their own > locking code (which hasn't suffered from that bug) until 2.6.4, > that's why you noticed the difference... Yes, as I saw that the patch uses the semaphore code in "arch" I was not sure any longer if it is really a XFS related bug. > In either case, you need _really_ heavy write IO activity to > trigger the bug. I noticed that. The best way to trigger it was "make -j20 vmlinux" so that the pdflushd comes strongly into action. Perhaps Dru can show me his "easy way" to reproduce the problem so that I can test it more easily. Thanks again Marc From owner-linux-xfs@oss.sgi.com Tue Apr 27 14:27:41 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 27 Apr 2004 14:27:46 -0700 (PDT) Received: from jurassic.park.msu.ru (jurassic.park.msu.ru [195.208.223.243]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3RLReKO018887 for ; Tue, 27 Apr 2004 14:27:41 -0700 Received: from den.park.msu.ru (den.park.msu.ru [212.192.253.17]) by jurassic.park.msu.ru (8.11.6/8.11.6) with ESMTP id i3RLR8J15726; Wed, 28 Apr 2004 01:27:08 +0400 Received: (from ink@localhost) by den.park.msu.ru (8.11.6/8.11.6) id i3RLRgo01047; Wed, 28 Apr 2004 01:27:42 +0400 Date: Wed, 28 Apr 2004 01:27:42 +0400 From: Ivan Kokshaysky To: Marc Giger Cc: Dru , linux-xfs@oss.sgi.com, =?koi8-r?Q?M=E5ns_Rullg=E5rd?= , linux-kernel@vger.kernel.org Subject: Re: status of Linux on Alpha? Message-ID: <20040428012742.B827@den.park.msu.ru> References: <20040404121032.7bb42b35@vaio.gigerstyle.ch> <20040409134534.67805dfd@vaio.gigerstyle.ch> <20040409134828.0e2984e5@vaio.gigerstyle.ch> <20040409230651.A727@den.park.msu.ru> <20040413194907.7ce8ceb7@vaio.gigerstyle.ch> <20040427185124.134073cd@vaio.gigerstyle.ch> <20040427215514.A651@den.park.msu.ru> <20040427200830.3f485a54@vaio.gigerstyle.ch> <20040428002018.A827@den.park.msu.ru> <20040427224231.0e439344@vaio.gigerstyle.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20040427224231.0e439344@vaio.gigerstyle.ch>; from gigerstyle@gmx.ch on Tue, Apr 27, 2004 at 10:42:31PM +0200 X-archive-position: 2948 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ink@jurassic.park.msu.ru Precedence: bulk X-list: linux-xfs Content-Length: 239 Lines: 8 On Tue, Apr 27, 2004 at 10:42:31PM +0200, Marc Giger wrote: > Perhaps Dru can show me his "easy way" to reproduce the problem so that > I can test it more easily. http://marc.theaimsgroup.com/?l=linux-kernel&m=108296356805411&w=2 Ivan. From owner-linux-xfs@oss.sgi.com Tue Apr 27 20:29:56 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 27 Apr 2004 20:30:01 -0700 (PDT) Received: from omx2.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3S3TpKO001250 for ; Tue, 27 Apr 2004 20:29:51 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i3S5bXhg029511 for ; Tue, 27 Apr 2004 22:37:45 -0700 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i3S3T1AL58760993; Wed, 28 Apr 2004 13:29:02 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i3S3SxgZ55007961; Wed, 28 Apr 2004 13:28:59 +1000 (EST) Date: Wed, 28 Apr 2004 13:28:59 +1000 (EST) From: Nathan Scott Message-Id: <200404280328.i3S3SxgZ55007961@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 910624 - fix a recent 2.4 fsync regression X-archive-position: 2950 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 412 Lines: 14 Fix fsync regression resulting from moving data flushing out from under the inode IOLOCK. Only affects 2.4 kernels. Date: Tue Apr 27 20:27:22 PDT 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/ultra-clean-xfs-linux Inspected by: sandeen@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:170782a linux-2.4/xfs_file.c - 1.105 From owner-linux-xfs@oss.sgi.com Tue Apr 27 22:43:12 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 27 Apr 2004 22:43:16 -0700 (PDT) Received: from zok.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3S5hCKO004937 for ; Tue, 27 Apr 2004 22:43:12 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i3S5Uuhv002629 for ; Tue, 27 Apr 2004 22:30:57 -0700 Received: (from nathans@localhost) by chook.melbourne.sgi.com (8.11.6/8.11.6) id i3S5UtH25671 for linux-xfs@oss.sgi.com; Wed, 28 Apr 2004 15:30:55 +1000 Date: Wed, 28 Apr 2004 15:30:55 +1000 From: Nathan Scott Message-Id: <200404280530.i3S5UtH25671@chook.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 904196 - update 2.4 split patches X-archive-position: 2951 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@chook.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 708 Lines: 29 Fix typo when dumping delalloc flag buffer count in sysrq-m Date: Tue Apr 27 22:25:01 PDT 2004 Workarea: chook.melbourne.sgi.com:/build/nathans/2.4.x-xfs Inspected by: nathans@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: 2.4.x-xfs:linux:170784a fs/buffer.c - 1.2 Update 2.4 split patches. Date: Tue Apr 27 22:29:46 PDT 2004 Workarea: chook.melbourne.sgi.com:/build/nathans/2.4.x-xfs Inspected by: nathans@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: 2.4.x-xfs:linux:170785a split-patches/bhdelay-typo - 1.1 split-patches/wait-call_usermodehelper - 1.1 split-patches/series - 1.2 From owner-linux-xfs@oss.sgi.com Tue Apr 27 23:01:39 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 27 Apr 2004 23:01:43 -0700 (PDT) Received: from omx1.americas.sgi.com (cfcafw.sgi.com [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3S61cKO005616 for ; Tue, 27 Apr 2004 23:01:38 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with SMTP id i3S5qsBN013625 for ; Wed, 28 Apr 2004 00:52:55 -0500 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA07579; Wed, 28 Apr 2004 15:52:30 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i3S5qS7X641967; Wed, 28 Apr 2004 15:52:28 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i3S5qRRK642421; Wed, 28 Apr 2004 15:52:27 +1000 (EST) Date: Wed, 28 Apr 2004 15:52:26 +1000 From: Nathan Scott To: Craig Tierney Cc: linux-xfs@oss.sgi.com Subject: Re: Using debug and tracing features in 2.4.26 Message-ID: <20040428155226.B640934@wobbly.melbourne.sgi.com> References: <1083086648.2374.15.camel@hpti9.fsl.noaa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1083086648.2374.15.camel@hpti9.fsl.noaa.gov>; from ctierney@HPTI.com on Tue, Apr 27, 2004 at 11:24:08AM -0600 X-archive-position: 2952 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 889 Lines: 28 On Tue, Apr 27, 2004 at 11:24:08AM -0600, Craig Tierney wrote: > I have enabled debugging and tracing features in XFS > using the 2.4.26 kernel. When I load the xfs module, > it reports that tracing and debugging are enabled. > > (From dmesg) > SGI XFS with tracing, debug enabled > SGI XFS Quota Management subsystem > > To enable tracing, the Configure.help file says to set > /proc/sys/vm/pagebuf/debug. However, I could not find this thats a slightly out-of-date doc - that variable no longer exists. i need to update Marcelo's tree for that. > Also, with debugging enabled, do all debug messages go to the > kernel log? you really want kdb enabled if you use debug/tracing, else its not overly useful. then you'll need a serial console too. there aren't much in the way of debug messages, its more to provide a whole lot of runtime consistency checks. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Apr 27 23:13:29 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 27 Apr 2004 23:13:33 -0700 (PDT) Received: from zok.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3S6DSKO006282 for ; Tue, 27 Apr 2004 23:13:29 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id i3S60Shv000990 for ; Tue, 27 Apr 2004 23:00:29 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA07783; Wed, 28 Apr 2004 16:00:14 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i3S6097X643448; Wed, 28 Apr 2004 16:00:10 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i3S603jc642377; Wed, 28 Apr 2004 16:00:03 +1000 (EST) Date: Wed, 28 Apr 2004 16:00:03 +1000 From: Nathan Scott To: Marc Giger Cc: Ivan Kokshaysky , Dru , linux-xfs@oss.sgi.com, M?ns Rullg?rd , linux-kernel@vger.kernel.org Subject: Re: status of Linux on Alpha? Message-ID: <20040428160003.C640934@wobbly.melbourne.sgi.com> References: <20040329205233.5b7905aa@vaio.gigerstyle.ch> <20040404121032.7bb42b35@vaio.gigerstyle.ch> <20040409134534.67805dfd@vaio.gigerstyle.ch> <20040409134828.0e2984e5@vaio.gigerstyle.ch> <20040409230651.A727@den.park.msu.ru> <20040413194907.7ce8ceb7@vaio.gigerstyle.ch> <20040427185124.134073cd@vaio.gigerstyle.ch> <20040427215514.A651@den.park.msu.ru> <20040427200830.3f485a54@vaio.gigerstyle.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20040427200830.3f485a54@vaio.gigerstyle.ch>; from gigerstyle@gmx.ch on Tue, Apr 27, 2004 at 08:08:30PM +0200 X-archive-position: 2953 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 543 Lines: 21 On Tue, Apr 27, 2004 at 08:08:30PM +0200, Marc Giger wrote: > Hi Ivan, > > Cool! > > I will try your patch after I finished moving to my new flat:-) > > I wonder why it happens only with the XFS code. What I saw > rw_sem is used all over the place in the kernel. We do use the downgrade_write interface in XFS, which has an architecture specific component and a generic component. Its much less widely used than the rest of the rw_semaphore code - that'd be a good spot to look if one architecture is behaving oddly. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Apr 28 00:38:24 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 28 Apr 2004 00:38:32 -0700 (PDT) Received: from rzcomm7.rz.tu-bs.de (rzcomm7.rz.tu-bs.de [134.169.9.53]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3S7cNKO014041 for ; Wed, 28 Apr 2004 00:38:23 -0700 Received: from localhost (localhost [127.0.0.1]) by rzcomm7.rz.tu-bs.de (8.11.1/8.11.1) with ESMTP id i3S7cMi11916 for ; Wed, 28 Apr 2004 09:38:22 +0200 (METDST) Received: from unknown ([127.0.0.1]) by localhost (rzcomm7 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11860-01-4 for ; Wed, 28 Apr 2004 09:38:20 +0200 (METDST) Received: from rzcomm12.rz.tu-bs.de (rzcomm12.rz.tu-bs.de [134.169.9.59]) by rzcomm7.rz.tu-bs.de (8.11.1/8.11.1) with ESMTP id i3S7bN611769 for ; Wed, 28 Apr 2004 09:37:23 +0200 (METDST) Received: from rhea.strm.ing.tu-bs.de (rhea.strm.ing.tu-bs.de [134.169.46.7]) by rzcomm12.rz.tu-bs.de (8.11.1/8.11.1) with ESMTP id i3S7bN821075 for ; Wed, 28 Apr 2004 09:37:23 +0200 (METDST) Received: by rhea.strm.ing.tu-bs.de (Postfix, from userid 5239) id 68717568019; Wed, 28 Apr 2004 09:37:22 +0200 (CEST) Date: Wed, 28 Apr 2004 09:37:22 +0200 From: Torsten Wolf To: linux-xfs@oss.sgi.com Subject: Re: Not enough memory for xfs_repair Message-ID: <20040428073721.GA4662@gaia> Reply-To: Torsten Wolf References: <20040426134329.GA4617@sycorax> <408D8370.2080702@mailcan.com> <20040427093542.GB1440@sycorax> <1083062025.3431.3.camel@pc9391> <20040427144526.GA3887@gaia> <1083081415.14273.12.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1083081415.14273.12.camel@stout.americas.sgi.com> X-Mailer: Mutt http://www.mutt.org/ Organization: TU Braunschweig X-Editor: Vim http://www.vim.org/ X-OpenPGP-Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xEE27B69C X-Fingerprint: 24EE 9FD9 5333 0206 541F 4602 C6A4 5F61 EE27 B69C X-Uptime: 07:36:42 up 7:55, 4 users, load average: 0.23, 0.17, 0.08 User-Agent: Mutt/1.5.5.1+cvs20040105i X-Virus-Scanned: by amavisd-new at tu-bs.de X-archive-position: 2954 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: t.wolf@tu-bs.de Precedence: bulk X-list: linux-xfs Content-Length: 1321 Lines: 62 On Di, 27 Apr 2004, Eric Sandeen wrote: >I fixed a few memory leaks in 2.6.4, and you're using 2.6.5, so at least >you have those. for now, I'd suggest creating a whole lot of swap and >give it another go; it would be nice to be able to watch xfs_repair work >on this filesystem to see what it's doing. You might also get the very >latest xfsprogs (2.6.10 I think). I have a 160GB harddrive to rescue the remaining data. First, I'm going to add this space as swapspace, which is hopefully enough. I'll also give the latest xfsprogs a try. >xfs_db -r -c "sb 0" -c "p" /dev/ magicnum = 0x58465342 blocksize = 4096 dblocks = 48839600 rblocks = 0 rextents = 0 uuid = e8a643a1-e490-472f-9cb6-13104ef76f1c logstart = 33554436 rootino = 128 rbmino = 129 rsumino = 130 rextsize = 16 agblocks = 3052475 agcount = 16 rbmblocks = 0 logblocks = 23847 versionnum = 0x3084 sectsize = 512 inodesize = 256 inopblock = 16 fname = "\000\000\000\000\000\000\000\000\000\000\000\000" blocklog = 12 sectlog = 9 inodelog = 8 inopblog = 4 agblklog = 22 rextslog = 0 inprogress = 0 imax_pct = 25 icount = 1222464 ifree = 9342 fdblocks = 6021601 frextents = 0 uquotino = 0 gquotino = 0 qflags = 0 flags = 0 shared_vn = 0 inoalignmt = 2 unit = 0 width = 0 dirblklog = 0 logsectlog = 0 logsectsize = 0 logsunit = 0 Regards, Torsten From owner-linux-xfs@oss.sgi.com Wed Apr 28 06:14:28 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 28 Apr 2004 06:14:33 -0700 (PDT) Received: from treshna.com ([203.97.82.178]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3SDEQKO027670 for ; Wed, 28 Apr 2004 06:14:27 -0700 Received: from treshna.com (nikita.localnet [192.168.2.2]) by treshna.com (8.12.3/8.12.3/Debian-6.6) with ESMTP id i3SDDH4I024982; Thu, 29 Apr 2004 01:13:19 +1200 Message-ID: <408FADE8.6090705@treshna.com> Date: Thu, 29 Apr 2004 01:13:12 +1200 From: Dru User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040312 Debian/1.6-3 X-Accept-Language: en MIME-Version: 1.0 To: Marc Giger CC: Ivan Kokshaysky , linux-xfs@oss.sgi.com, =?ISO-8859-1?Q?M=E5ns_Rullg=E5rd?= , linux-kernel@vger.kernel.org Subject: Re: status of Linux on Alpha? References: <20040328204308.C14868@jurassic.park.msu.ru> <20040328221806.7fa20502@vaio.gigerstyle.ch> <20040329205233.5b7905aa@vaio.gigerstyle.ch> <20040404121032.7bb42b35@vaio.gigerstyle.ch> <20040409134534.67805dfd@vaio.gigerstyle.ch> <20040409134828.0e2984e5@vaio.gigerstyle.ch> <20040409230651.A727@den.park.msu.ru> <20040413194907.7ce8ceb7@vaio.gigerstyle.ch> <20040427185124.134073cd@vaio.gigerstyle.ch> <20040427215514.A651@den.park.msu.ru> <20040427200830.3f485a54@vaio.gigerstyle.ch> In-Reply-To: <20040427200830.3f485a54@vaio.gigerstyle.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2955 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: andru@treshna.com Precedence: bulk X-list: linux-xfs Content-Length: 1965 Lines: 78 I've tested the patch on high loads and it handles it fine, its even still very responsive under those loads (can't say the same for my pentium4) Thanks a lot guys. I'll put it though some more heavier tests over the next few days to make certain its rock solid. I did notice one other very minor issue, which was if i set it the alpha system type to Nautilus instead of generic it doesnt boot. It cycles lost interupt when detecting drives, it doesnt time out (each lost intrupt times out but it keeps looking continally). Marc Giger wrote: >Hi Ivan, > >Cool! > >I will try your patch after I finished moving to my new flat:-) > >I wonder why it happens only with the XFS code. What I saw >rw_sem is used all over the place in the kernel. > >Thank you and Dru for the work and hopefully it will fix my problem. > >Regards > >Marc > > >On Tue, 27 Apr 2004 21:55:14 +0400 >Ivan Kokshaysky wrote: > > > >>On Tue, Apr 27, 2004 at 06:51:24PM +0200, Marc Giger wrote: >> >> >>>What's the current status of the problem? >>> >>> >>Hopefully resolved - thanks to Dru , who provided >>an easy way to reproduce the problem. >> >>What we have in lib/rwsem.c:__rwsem_do_wake(): >> int woken, loop; >> ^^^ >>and several lines below: >> loop = woken; >> woken *= RWSEM_ACTIVE_BIAS-RWSEM_WAITING_BIAS; >> woken -= RWSEM_ACTIVE_BIAS; >> >>However, rw_semaphore->count is 64-bit on Alpha, so >>RWSEM_WAITING_BIAS has been defined as -0x0000000100000000L. >>Obviously, this blows up in the write contention case. >> >>Ivan. >> >>--- linux.orig/lib/rwsem.c Mon Apr 26 20:11:36 2004 >>+++ linux/lib/rwsem.c Tue Apr 27 20:04:14 2004 >>@@ -40,8 +40,7 @@ static inline struct rw_semaphore *__rws >> { >> struct rwsem_waiter *waiter; >> struct list_head *next; >>- signed long oldcount; >>- int woken, loop; >>+ signed long oldcount, woken, loop; >> >> rwsemtrace(sem,"Entering __rwsem_do_wake"); >> >> >> >> >> From owner-linux-xfs@oss.sgi.com Wed Apr 28 06:30:19 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 28 Apr 2004 06:30:26 -0700 (PDT) Received: from ford.pronto.tv (213-187-164-3.dd.nextgentel.com [213.187.164.3]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3SDUHKO028509 for ; Wed, 28 Apr 2004 06:30:18 -0700 Received: from ford.pronto.tv (IDENT:51770@localhost [127.0.0.1]) by ford.pronto.tv (8.12.8/8.12.8) with ESMTP id i3SDTnIS003269; Wed, 28 Apr 2004 15:29:49 +0200 Received: (from mru@localhost) by ford.pronto.tv (8.12.8/8.12.8/Submit) id i3SDThmp003268; Wed, 28 Apr 2004 15:29:43 +0200 X-Authentication-Warning: ford.pronto.tv: mru set sender to mru@kth.se using -f To: Dru Cc: Marc Giger , Ivan Kokshaysky , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: status of Linux on Alpha? References: <20040328204308.C14868@jurassic.park.msu.ru> <20040328221806.7fa20502@vaio.gigerstyle.ch> <20040329205233.5b7905aa@vaio.gigerstyle.ch> <20040404121032.7bb42b35@vaio.gigerstyle.ch> <20040409134534.67805dfd@vaio.gigerstyle.ch> <20040409134828.0e2984e5@vaio.gigerstyle.ch> <20040409230651.A727@den.park.msu.ru> <20040413194907.7ce8ceb7@vaio.gigerstyle.ch> <20040427185124.134073cd@vaio.gigerstyle.ch> <20040427215514.A651@den.park.msu.ru> <20040427200830.3f485a54@vaio.gigerstyle.ch> <408FADE8.6090705@treshna.com> From: =?iso-8859-1?q?M=E5ns_Rullg=E5rd?= Date: Wed, 28 Apr 2004 15:29:43 +0200 In-Reply-To: <408FADE8.6090705@treshna.com> (Dru's message of "Thu, 29 Apr 2004 01:13:12 +1200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i3SDUJKO028510 X-archive-position: 2956 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mru@kth.se Precedence: bulk X-list: linux-xfs Content-Length: 747 Lines: 21 Dru writes: > I've tested the patch on high loads and it handles it fine, its even > still very responsive under those loads (can't say the same for > my pentium4) Thanks a lot guys. > > I'll put it though some more heavier tests over the next few days > to make certain its rock solid. > > I did notice one other very minor issue, which was if i set it the alpha > system type to Nautilus instead of generic it doesnt boot. > It cycles lost interupt when detecting drives, it doesnt time out (each lost > intrupt times out but it keeps looking continally). Is that related to this patch, or is it a different issue? I run 2.6.3 kernels compiled for SX164, Miata, and Avanti with no problems. -- Måns Rullgård mru@kth.se From owner-linux-xfs@oss.sgi.com Wed Apr 28 06:46:25 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 28 Apr 2004 06:46:30 -0700 (PDT) Received: from web41908.mail.yahoo.com (web41908.mail.yahoo.com [66.218.93.159]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3SDkPKO029276 for ; Wed, 28 Apr 2004 06:46:25 -0700 Message-ID: <20040428134620.19156.qmail@web41908.mail.yahoo.com> Received: from [144.16.64.4] by web41908.mail.yahoo.com via HTTP; Wed, 28 Apr 2004 06:46:20 PDT Date: Wed, 28 Apr 2004 06:46:20 -0700 (PDT) From: shilpa s Subject: xfs To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 2957 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: s_shilpa_15@yahoo.com Precedence: bulk X-list: linux-xfs Content-Length: 240 Lines: 14 Hello, I wud like to know as to what is the full form of xfs. regards, shilpa __________________________________ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover From owner-linux-xfs@oss.sgi.com Wed Apr 28 12:01:13 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 28 Apr 2004 12:01:17 -0700 (PDT) Received: from pimout1-ext.prodigy.net (pimout1-ext.prodigy.net [207.115.63.77]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3SJ1CKO017162 for ; Wed, 28 Apr 2004 12:01:13 -0700 Received: from taniwha.stupidest.org (adsl-67-124-117-208.dsl.snfc21.pacbell.net [67.124.117.208]) by pimout1-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id i3SJ1BNO227768; Wed, 28 Apr 2004 15:01:12 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id 5351614911; Wed, 28 Apr 2004 12:01:11 -0700 (PDT) Date: Wed, 28 Apr 2004 12:01:11 -0700 From: Chris Wedgwood To: shilpa s Cc: linux-xfs@oss.sgi.com Subject: Re: xfs Message-ID: <20040428190111.GA20725@taniwha.stupidest.org> References: <20040428134620.19156.qmail@web41908.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040428134620.19156.qmail@web41908.mail.yahoo.com> X-archive-position: 2958 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 160 Lines: 9 On Wed, Apr 28, 2004 at 06:46:20AM -0700, shilpa s wrote: > I wud like to know as to what is the full form of xfs. http://oss.sgi.com/projects/xfs/ --cw From owner-linux-xfs@oss.sgi.com Wed Apr 28 18:51:16 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 28 Apr 2004 18:51:19 -0700 (PDT) Received: from stargate.coplanar.net (root@CPE0080c8c9b431-CM014280010574.cpe.net.cable.rogers.com [24.112.162.124]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3T1pDKO031945 for ; Wed, 28 Apr 2004 18:51:15 -0700 Received: from coplanar.net (bridge.skynet.coplanar.net [192.168.7.10]) (authenticated bits=0) by stargate.coplanar.net (8.12.3/8.12.3/Debian-6.6) with ESMTP id i3T1ojYu032077; Wed, 28 Apr 2004 21:51:03 -0400 Message-ID: <40905F8F.5020100@coplanar.net> Date: Wed, 28 Apr 2004 21:51:11 -0400 From: Jeremy Jackson Organization: Coplanar Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040122 Debian/1.6-1 X-Accept-Language: en MIME-Version: 1.0 To: Steve Lord CC: linux-xfs@oss.sgi.com Subject: Re: Using debug and tracing features in 2.4.26 References: <1083086648.2374.15.camel@hpti9.fsl.noaa.gov> <408EAC06.7010404@xfs.org> In-Reply-To: <408EAC06.7010404@xfs.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (stargate.coplanar.net: domain of jerj@coplanar.net designates 192.168.7.10 as SASL permitted sender) X-archive-position: 2959 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jerj@coplanar.net Precedence: bulk X-list: linux-xfs Content-Length: 644 Lines: 21 Steve Lord wrote: > Any reason for turning on debug? It adds thousands of checks to > the code base, any one of them will oops if it triggers. Never > run this way with data you care about. > So I've been causing the problems I'm seeing by turning debug on? I'm getting a debug related oops about every 2 months, but wouldn't turning debug off just cause silent data corruption? I don't recall reading any dire warnings in the help for the configure option, although it does say for XFS developers only. If it is the official recommendation, I will turn it off. -- Jeremy Jackson Coplanar Networks (519)897-1516 http://www.coplanar.net From owner-linux-xfs@oss.sgi.com Wed Apr 28 22:10:28 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 28 Apr 2004 22:10:36 -0700 (PDT) Received: from zok.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3T5ASKO007464 for ; Wed, 28 Apr 2004 22:10:28 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i3T5ALhv022515 for ; Wed, 28 Apr 2004 22:10:22 -0700 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i3T5AKAL58597744 for ; Thu, 29 Apr 2004 15:10:20 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i3T5AJBp56536862 for linux-xfs@oss.sgi.com; Thu, 29 Apr 2004 15:10:19 +1000 (EST) Date: Thu, 29 Apr 2004 15:10:19 +1000 (EST) From: Nathan Scott Message-Id: <200404290510.i3T5AJBp56536862@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 912155 - remove extraneous vmtruncate X-archive-position: 2961 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 394 Lines: 14 Remove extraneous vmtruncate call, missed in earlier merge. Date: Wed Apr 28 22:09:31 PDT 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/ultra-clean-xfs-linux Inspected by: hch@lst.de,felixb@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:170858a linux-2.6/xfs_iops.c - 1.217 linux-2.4/xfs_iops.c - 1.206 From owner-linux-xfs@oss.sgi.com Thu Apr 29 00:01:38 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 29 Apr 2004 00:01:42 -0700 (PDT) Received: from omx1.americas.sgi.com (cfcafw.sgi.com [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3T71bKO009508 for ; Thu, 29 Apr 2004 00:01:37 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i3T6mxBN013302 for ; Thu, 29 Apr 2004 01:48:59 -0500 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i3T6muAL46545477 for ; Thu, 29 Apr 2004 16:48:57 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i3T6mtB759050866 for linux-xfs@oss.sgi.com; Thu, 29 Apr 2004 16:48:55 +1000 (EST) Date: Thu, 29 Apr 2004 16:48:55 +1000 (EST) From: Nathan Scott Message-Id: <200404290648.i3T6mtB759050866@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 913468 - security namespace fix X-archive-position: 2962 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 438 Lines: 16 Remove xfs_iaccess checks on security namespace, all need to be done outside of the filesystem in the security module(s). Date: Wed Apr 28 23:47:33 PDT 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/ultra-clean-xfs-linux Inspected by: tes@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:170861a xfs_acl.c - 1.50 xfs_attr.c - 1.115 xfs_attr.h - 1.31 From owner-linux-xfs@oss.sgi.com Thu Apr 29 12:57:58 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 29 Apr 2004 12:58:02 -0700 (PDT) Received: from postfix3-1.free.fr (postfix@postfix3-1.free.fr [213.228.0.44]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3TJvjKO000663 for ; Thu, 29 Apr 2004 12:57:48 -0700 Received: from lns-th2-4f-81-56-250-144.adsl.proxad.net (lns-th2-4f-81-56-250-144.adsl.proxad.net [81.56.250.144]) by postfix3-1.free.fr (Postfix) with ESMTP id 7E582C454D for ; Thu, 29 Apr 2004 21:28:43 +0200 (CEST) From: Johann Lombardi Reply-To: johann.lombardi@free.fr To: linux-xfs@oss.sgi.com Subject: Unsupported sector size Date: Thu, 29 Apr 2004 21:34:23 +0200 User-Agent: KMail/1.5.4 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200404292134.23178.johann.lombardi@free.fr> X-archive-position: 2965 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: johann.lombardi@free.fr Precedence: bulk X-list: linux-xfs Content-Length: 707 Lines: 23 Folks, When I want to mount a XFS filesystem stored on a 4K sector size device, I get the following error message: XFS: device supports only 4096 byte sectors (not 512) Here is a patch fixing this small mistake: diff -Nru a/fs/xfs/xfs_mount.c b/fs/xfs/xfs_mount.c --- a/fs/xfs/xfs_mount.c 2004-04-04 11:42:41.000000000 +0200 +++ b/fs/xfs/xfs_mount.c 2004-04-29 20:42:07.000000000 +0200 @@ -508,7 +508,7 @@ if (sector_size > mp->m_sb.sb_sectsize) { cmn_err(CE_WARN, "XFS: device supports only %u byte sectors (not %u)", - sector_size, mp->m_sb.sb_sectsize); + mp->m_sb.sb_sectsize, sector_size); error = ENOSYS; goto fail; } Johann From owner-linux-xfs@oss.sgi.com Thu Apr 29 13:16:43 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 29 Apr 2004 13:16:48 -0700 (PDT) Received: from omx1.americas.sgi.com (cfcafw.sgi.com [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3TKGhKO001819 for ; Thu, 29 Apr 2004 13:16:43 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i3TKFPBN007732 for ; Thu, 29 Apr 2004 15:15:25 -0500 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i3TKFPKe37755386; Thu, 29 Apr 2004 15:15:25 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i3TKFLHO1339105; Thu, 29 Apr 2004 15:15:25 -0500 (CDT) Subject: Re: Unsupported sector size From: Eric Sandeen To: johann.lombardi@free.fr Cc: linux-xfs@oss.sgi.com In-Reply-To: <200404292134.23178.johann.lombardi@free.fr> References: <200404292134.23178.johann.lombardi@free.fr> Content-Type: text/plain Organization: Eric Conspiracy Secret Labs Message-Id: <1083269720.22208.30.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 29 Apr 2004 15:15:21 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 2967 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1267 Lines: 39 Hm, sector_size is gleaned from the underlying block device, via xfs_getsize_buftarg, which calls block_size, which gets bdev->bd_block_size. so, the message you got is correct I think - the filesystem was made with 512b sectors, your device supports only 4k sectors. hence: XFS: device supports only 4096 byte sectors (not 512) -Eric On Thu, 2004-04-29 at 14:34, Johann Lombardi wrote: > Folks, > > When I want to mount a XFS filesystem stored on a 4K sector size device, I get > the following error message: > XFS: device supports only 4096 byte sectors (not 512) > > Here is a patch fixing this small mistake: > > diff -Nru a/fs/xfs/xfs_mount.c b/fs/xfs/xfs_mount.c > --- a/fs/xfs/xfs_mount.c 2004-04-04 11:42:41.000000000 +0200 > +++ b/fs/xfs/xfs_mount.c 2004-04-29 20:42:07.000000000 +0200 > @@ -508,7 +508,7 @@ > if (sector_size > mp->m_sb.sb_sectsize) { > cmn_err(CE_WARN, > "XFS: device supports only %u byte sectors (not %u)", > - sector_size, mp->m_sb.sb_sectsize); > + mp->m_sb.sb_sectsize, sector_size); > error = ENOSYS; > goto fail; > } > > Johann -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Thu Apr 29 14:50:10 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 29 Apr 2004 14:50:14 -0700 (PDT) Received: from andrei.myip.org (c-24-6-174-200.client.comcast.net [24.6.174.200]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3TLoAKO005139 for ; Thu, 29 Apr 2004 14:50:10 -0700 Received: by andrei.myip.org (Postfix, from userid 103) id 2A9FC4223; Thu, 29 Apr 2004 14:50:10 -0700 (PDT) Received: from stantz.corp.sgi.com (unknown [163.154.36.38]) by andrei.myip.org (Postfix) with ESMTP id 98A87421E for ; Thu, 29 Apr 2004 14:50:09 -0700 (PDT) Received: by stantz.corp.sgi.com (Postfix, from userid 500) id 54907BF43; Thu, 29 Apr 2004 14:50:09 -0700 (PDT) Subject: bugzilla entries for XFS in Fedora Core 2 test 3 From: Florin Andrei Reply-To: linux-xfs@oss.sgi.com To: linux-xfs Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1083275408.1106.37.camel@stantz.corp.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) Date: Thu, 29 Apr 2004 14:50:09 -0700 X-archive-position: 2968 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: florin@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 766 Lines: 27 I did a test install for Fedora Core 2 test 3 using XFS. In order to enable XFS in the Fedora installer, when the installer boots up, at the very first prompt, enter "linux xfs" (or "linux text xfs" to run the installer in text mode). I've found a few bugs which i filed to Bugzilla: https://bugzilla.redhat.com/ The numbers of the bugs are: 122017 122018 122043 (use the "Goto bug #" form in the upper-right corner) They are rather installer-related than XFS bugs proper. However, some of them might severely affect the usability of XFS with Fedora (especially the last one). So, if you think you have significant comments to make, feel free to add them to bugzilla, so the bugs get fixed before the final release. -- Florin Andrei http://florin.myip.org/ From owner-linux-xfs@oss.sgi.com Thu Apr 29 14:59:05 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 29 Apr 2004 14:59:09 -0700 (PDT) Received: from omx2.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3TLx4KO005597 for ; Thu, 29 Apr 2004 14:59:04 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i3U074iQ016879 for ; Thu, 29 Apr 2004 17:07:14 -0700 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i3TLwTKe37777156 for ; Thu, 29 Apr 2004 16:58:29 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i3TLwSHO1353864 for ; Thu, 29 Apr 2004 16:58:28 -0500 (CDT) Subject: Re: bugzilla entries for XFS in Fedora Core 2 test 3 From: Eric Sandeen To: linux-xfs@oss.sgi.com In-Reply-To: <1083275408.1106.37.camel@stantz.corp.sgi.com> References: <1083275408.1106.37.camel@stantz.corp.sgi.com> Content-Type: text/plain Organization: Eric Conspiracy Secret Labs Message-Id: <1083275907.22208.35.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 29 Apr 2004 16:58:28 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 2969 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1076 Lines: 31 Thanks Florin - FWIW, I can't get the xfs code in FC2test3 to pass xfsqa / xfstests, either... trying a few things to sort it out. -Eric On Thu, 2004-04-29 at 16:50, Florin Andrei wrote: > I did a test install for Fedora Core 2 test 3 using XFS. > In order to enable XFS in the Fedora installer, when the installer boots > up, at the very first prompt, enter "linux xfs" (or "linux text xfs" to > run the installer in text mode). > I've found a few bugs which i filed to Bugzilla: > > https://bugzilla.redhat.com/ > > The numbers of the bugs are: > > 122017 > 122018 > 122043 > > (use the "Goto bug #" form in the upper-right corner) > > They are rather installer-related than XFS bugs proper. However, some of > them might severely affect the usability of XFS with Fedora (especially > the last one). So, if you think you have significant comments to make, > feel free to add them to bugzilla, so the bugs get fixed before the > final release. -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Thu Apr 29 18:15:07 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 29 Apr 2004 18:15:11 -0700 (PDT) Received: from omx2.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3U1EvKO018897 for ; Thu, 29 Apr 2004 18:14:57 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with SMTP id i3U3MvmN013602 for ; Thu, 29 Apr 2004 20:23:07 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA27762; Fri, 30 Apr 2004 11:14:15 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i3U1EEln028881; Fri, 30 Apr 2004 11:14:14 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i3U1EC1t028897; Fri, 30 Apr 2004 11:14:12 +1000 (EST) Date: Fri, 30 Apr 2004 11:14:12 +1000 From: Nathan Scott To: johann.lombardi@free.fr, Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: Unsupported sector size Message-ID: <20040430111412.A28855@wobbly.melbourne.sgi.com> References: <200404292134.23178.johann.lombardi@free.fr> <1083269720.22208.30.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1083269720.22208.30.camel@stout.americas.sgi.com>; from sandeen@sgi.com on Thu, Apr 29, 2004 at 03:15:21PM -0500 X-archive-position: 2970 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 640 Lines: 21 On Thu, Apr 29, 2004 at 03:15:21PM -0500, Eric Sandeen wrote: > Hm, sector_size is gleaned from the underlying block device, via > xfs_getsize_buftarg, which calls block_size, which gets > bdev->bd_block_size. > > so, the message you got is correct I think - the filesystem was made The message is indeed correct. You should have got a warning from mkfs.xfs when you created the filesystem flagging this as a problem too - did you? (cos if not, thats a driver bug that should be fixed). > with 512b sectors, your device supports only 4k sectors. hence: > > XFS: device supports only 4096 byte sectors (not 512) cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Apr 29 18:17:41 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 29 Apr 2004 18:17:45 -0700 (PDT) Received: from andrei.myip.org (c-24-6-174-200.client.comcast.net [24.6.174.200]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3U1HfKO019292 for ; Thu, 29 Apr 2004 18:17:41 -0700 Received: by andrei.myip.org (Postfix, from userid 103) id 220434223; Thu, 29 Apr 2004 18:17:41 -0700 (PDT) Received: from rivendell.home.local (rivendell.home.local [192.168.0.12]) by andrei.myip.org (Postfix) with ESMTP id 98CA0421E for ; Thu, 29 Apr 2004 18:17:38 -0700 (PDT) Subject: Re: bugzilla entries for XFS in Fedora Core 2 test 3 From: Florin Andrei Reply-To: linux-xfs@oss.sgi.com To: linux-xfs@oss.sgi.com In-Reply-To: <1083275907.22208.35.camel@stout.americas.sgi.com> References: <1083275408.1106.37.camel@stantz.corp.sgi.com> <1083275907.22208.35.camel@stout.americas.sgi.com> Content-Type: text/plain Organization: SGI Message-Id: <1083287858.5785.0.camel@rivendell.home.local> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.3 (1.4.3-1.duke.1) Date: 29 Apr 2004 18:17:38 -0700 Content-Transfer-Encoding: 7bit X-archive-position: 2971 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: florin@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1171 Lines: 35 Does the vanilla 2.6.5 kernel pass the test? (FC2t3 is based on 2.6.5) On Thu, 2004-04-29 at 14:58, Eric Sandeen wrote: > Thanks Florin - FWIW, I can't get the xfs code in FC2test3 to pass xfsqa > / xfstests, either... trying a few things to sort it out. > > -Eric > > On Thu, 2004-04-29 at 16:50, Florin Andrei wrote: > > I did a test install for Fedora Core 2 test 3 using XFS. > > In order to enable XFS in the Fedora installer, when the installer boots > > up, at the very first prompt, enter "linux xfs" (or "linux text xfs" to > > run the installer in text mode). > > I've found a few bugs which i filed to Bugzilla: > > > > https://bugzilla.redhat.com/ > > > > The numbers of the bugs are: > > > > 122017 > > 122018 > > 122043 > > > > (use the "Goto bug #" form in the upper-right corner) > > > > They are rather installer-related than XFS bugs proper. However, some of > > them might severely affect the usability of XFS with Fedora (especially > > the last one). So, if you think you have significant comments to make, > > feel free to add them to bugzilla, so the bugs get fixed before the > > final release. -- Florin Andrei http://florin.myip.org/ From owner-linux-xfs@oss.sgi.com Thu Apr 29 18:31:43 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 29 Apr 2004 18:31:47 -0700 (PDT) Received: from omx1.americas.sgi.com (cfcafw.sgi.com [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3U1VgKO019971 for ; Thu, 29 Apr 2004 18:31:43 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with SMTP id i3U1GeBN002821 for ; Thu, 29 Apr 2004 20:16:41 -0500 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA27787; Fri, 30 Apr 2004 11:16:37 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i3U1GZln028882; Fri, 30 Apr 2004 11:16:36 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i3U1GY5N028892; Fri, 30 Apr 2004 11:16:34 +1000 (EST) Date: Fri, 30 Apr 2004 11:16:34 +1000 From: Nathan Scott To: johann.lombardi@free.fr Cc: linux-xfs@oss.sgi.com Subject: Re: Unsupported sector size Message-ID: <20040430111634.B28855@wobbly.melbourne.sgi.com> References: <200404292134.23178.johann.lombardi@free.fr> <1083269720.22208.30.camel@stout.americas.sgi.com> <20040430111412.A28855@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20040430111412.A28855@wobbly.melbourne.sgi.com>; from nathans@sgi.com on Fri, Apr 30, 2004 at 11:14:12AM +1000 X-archive-position: 2972 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 439 Lines: 16 On Fri, Apr 30, 2004 at 11:14:12AM +1000, Nathan Scott wrote: > > The message is indeed correct. You should have got a warning > from mkfs.xfs when you created the filesystem flagging this as > a problem too - did you? (cos if not, thats a driver bug that > should be fixed). Gak, pressed "send" too soon :) -- you'll want to use -ssize=4k at mkfs time with this device, if you haven't found that option already. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Apr 29 19:20:27 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 29 Apr 2004 19:20:33 -0700 (PDT) Received: from relay02.roc.ny.frontiernet.net (relay02.roc.ny.frontiernet.net [66.133.131.35]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3U2KQKO021041 for ; Thu, 29 Apr 2004 19:20:26 -0700 Received: (qmail 11069 invoked from network); 30 Apr 2004 02:20:25 -0000 Received: from 208-186-10-249.nrp1.brv.mn.frontiernet.net (HELO xfs.org) ([208.186.10.249]) (envelope-sender ) by relay02.roc.ny.frontiernet.net (FrontierMTA 2.3.18) with SMTP for ; 30 Apr 2004 02:20:25 -0000 Message-ID: <4091B7BE.8040701@xfs.org> Date: Thu, 29 Apr 2004 21:19:42 -0500 From: Steve Lord User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: bugzilla entries for XFS in Fedora Core 2 test 3 References: <1083275408.1106.37.camel@stantz.corp.sgi.com> In-Reply-To: <1083275408.1106.37.camel@stantz.corp.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2973 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 756 Lines: 26 Florin Andrei wrote: > I did a test install for Fedora Core 2 test 3 using XFS. > In order to enable XFS in the Fedora installer, when the installer boots > up, at the very first prompt, enter "linux xfs" (or "linux text xfs" to > run the installer in text mode). > I've found a few bugs which i filed to Bugzilla: > > https://bugzilla.redhat.com/ > > The numbers of the bugs are: > > 122017 looks like redhat is getting lazy here > 122018 ditto > 122043 XFS does labels just fine, something else is going on here, in fact I have a fedora core setup which is all XFS (except /boot because of the grub issue). I have about 4 filesystems which all mount fine, but I am using device mapper for them all which probably changes the mount sequence. Steve From owner-linux-xfs@oss.sgi.com Thu Apr 29 19:25:52 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 29 Apr 2004 19:25:56 -0700 (PDT) Received: from zok.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3U2PqKO021508 for ; Thu, 29 Apr 2004 19:25:52 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id i3U2PQhv025917 for ; Thu, 29 Apr 2004 19:25:27 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA29341 for ; Fri, 30 Apr 2004 12:25:25 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i3U2PNln030627 for ; Fri, 30 Apr 2004 12:25:23 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i3U2PMYj030577 for linux-xfs@oss.sgi.com; Fri, 30 Apr 2004 12:25:22 +1000 (EST) Date: Fri, 30 Apr 2004 12:25:21 +1000 From: Nathan Scott To: linux-xfs@oss.sgi.com Subject: Re: bugzilla entries for XFS in Fedora Core 2 test 3 Message-ID: <20040430122521.C28855@wobbly.melbourne.sgi.com> References: <1083275408.1106.37.camel@stantz.corp.sgi.com> <1083275907.22208.35.camel@stout.americas.sgi.com> <1083287858.5785.0.camel@rivendell.home.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1083287858.5785.0.camel@rivendell.home.local>; from florin@sgi.com on Thu, Apr 29, 2004 at 06:17:38PM -0700 X-archive-position: 2974 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 245 Lines: 11 On Thu, Apr 29, 2004 at 06:17:38PM -0700, Florin Andrei wrote: > Does the vanilla 2.6.5 kernel pass the test? (FC2t3 is based on 2.6.5) Yep, certainly does, the vanilla kernels are what we spend most time hacking/testing. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Apr 29 20:31:40 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 29 Apr 2004 20:31:46 -0700 (PDT) Received: from omx1.americas.sgi.com (cfcafw.sgi.com [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3U3VeKO025813 for ; Thu, 29 Apr 2004 20:31:40 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i3U3NQBN006470 for ; Thu, 29 Apr 2004 22:23:27 -0500 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i3U3NOAL33055631 for ; Fri, 30 Apr 2004 13:23:24 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i3U3NMVk59937463 for linux-xfs@oss.sgi.com; Fri, 30 Apr 2004 13:23:22 +1000 (EST) Date: Fri, 30 Apr 2004 13:23:22 +1000 (EST) From: Nathan Scott Message-Id: <200404300323.i3U3NMVk59937463@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 907752 - minor xfsprogs updates X-archive-position: 2975 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 4276 Lines: 175 Flushing my TAKE mail backlog for a bunch of trivial userspace changes; some of these checked in quite a while back. Sync a userspace header with its kernel counterpart. Date: Sun Apr 4 19:49:33 PDT 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-cmds Inspected by: nathans@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:169621a xfsprogs/include/xfs_trans.h - 1.16 Debian packaging updates. Date: Thu Apr 15 18:55:33 PDT 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-cmds Inspected by: nathans@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:170198a xfsprogs/debian/changelog - 1.95 xfsdump/debian/changelog - 1.48 Update Debian packaging information. Date: Fri Apr 16 01:06:14 PDT 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-cmds Inspected by: nathans@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:170205a xfsdump/debian/changelog - 1.49 Update xfsprogs changelog for Russells fix. Date: Tue Apr 20 16:02:28 PDT 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-cmds Inspected by: nathans@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:170402a xfsprogs/doc/CHANGES - 1.143 Update Debian packaging info for attr package. Date: Tue Apr 20 16:03:32 PDT 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-cmds Inspected by: nathans@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:170403a attr/VERSION - 1.46 attr/doc/CHANGES - 1.54 attr/debian/control - 1.13 attr/debian/changelog - 1.47 Update DMAPI debian packaging. Date: Tue Apr 27 15:58:02 PDT 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-cmds Inspected by: nathans@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:170772a dmapi/debian/changelog - 1.19 Update user/kernel source checker to work better with separate user/kernel trees. Date: Thu Apr 29 19:58:44 PDT 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-cmds Inspected by: nathans@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:170946a xfstests/tools/srcdiff - 1.29 Sync up different copies of the m4 macros, noop change for these packages. Date: Thu Apr 29 20:04:58 PDT 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-cmds Inspected by: nathans@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:170947a acl/m4/package_attrdev.m4 - 1.2 dmapi/m4/package_xfslibs.m4 - 1.4 xfstests/m4/package_attrdev.m4 - 1.2 xfstests/m4/package_xfslibs.m4 - 1.4 Trivial fixes to compiler warnings on 64 bit platforms. Date: Thu Apr 29 20:07:10 PDT 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-cmds Inspected by: nathans@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:170948a xfsprogs/logprint/log_misc.c - 1.16 xfsprogs/libxfs/xfs_da_btree.c - 1.24 xfsprogs/io/mmap.c - 1.2 Sync up user/kernel libxfs and headers Date: Thu Apr 29 20:16:43 PDT 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-cmds Inspected by: nathans@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:170950a xfsprogs/libxlog/xfs_log_recover.c - 1.27 xfsprogs/include/xfs_ag.h - 1.16 xfsprogs/include/xfs_log_priv.h - 1.17 xfsprogs/include/xfs_mount.h - 1.43 xfsprogs/include/xfs_attr_leaf.h - 1.10 xfsprogs/include/xfs_types.h - 1.23 xfsprogs/include/xfs_quota.h - 1.14 xfsprogs/libxfs/xfs_alloc.c - 1.21 Fix printf format for bytes read/written output. Date: Thu Apr 29 20:20:25 PDT 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-cmds Inspected by: nathans@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:170952a xfsprogs/io/pread.c - 1.12 xfsprogs/io/pwrite.c - 1.12 From owner-linux-xfs@oss.sgi.com Thu Apr 29 20:52:06 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 29 Apr 2004 20:52:10 -0700 (PDT) Received: from omx2.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3U3q1KO026435 for ; Thu, 29 Apr 2004 20:52:01 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i3U602ot030401 for ; Thu, 29 Apr 2004 23:00:13 -0700 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i3U3pFAL58979535; Fri, 30 Apr 2004 13:51:16 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i3U3pEZ059861923; Fri, 30 Apr 2004 13:51:14 +1000 (EST) Date: Fri, 30 Apr 2004 13:51:14 +1000 (EST) From: Nathan Scott Message-Id: <200404300351.i3U3pEZ059861923@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 913109 - xfsprogs-2.6.12 X-archive-position: 2976 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 562 Lines: 20 Update libdisk to extract stripe info from device mapper, for mkfs.xfs. Date: Thu Apr 29 20:50:20 PDT 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-cmds Inspected by: sandeen@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:170955a xfsprogs/libdisk/dm.c - 1.1 xfsprogs/VERSION - 1.106 xfsprogs/doc/CHANGES - 1.144 xfsprogs/libdisk/drivers.c - 1.14 xfsprogs/libdisk/Makefile - 1.10 xfsprogs/libdisk/lvm.c - 1.12 xfsprogs/debian/changelog - 1.96 xfsprogs/libdisk/drivers.h - 1.5 From owner-linux-xfs@oss.sgi.com Thu Apr 29 21:46:37 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 29 Apr 2004 21:46:41 -0700 (PDT) Received: from omx1.americas.sgi.com (cfcafw.sgi.com [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3U4kaKO027860 for ; Thu, 29 Apr 2004 21:46:37 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i3U4XcBN024237 for ; Thu, 29 Apr 2004 23:33:38 -0500 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i3U4XbKe37744668; Thu, 29 Apr 2004 23:33:37 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i3U4XbHP1412432; Thu, 29 Apr 2004 23:33:37 -0500 (CDT) Date: Thu, 29 Apr 2004 23:33:37 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Steve Lord cc: linux-xfs@oss.sgi.com Subject: Re: bugzilla entries for XFS in Fedora Core 2 test 3 In-Reply-To: <4091B7BE.8040701@xfs.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2977 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 549 Lines: 21 florin, i hand-labeled & mounted a filesystem on an fc2test3 system, no problems... can you try xfs_admin -l on the devices in question to see if they have valid fs labels? -Eric On Thu, 29 Apr 2004, Steve Lord wrote: > > 122043 > XFS does labels just fine, something else is going on here, in fact I > have a fedora core setup which is all XFS (except /boot because of > the grub issue). I have about 4 filesystems which all mount fine, > but I am using device mapper for them all which probably changes > the mount sequence. > > Steve > > From owner-linux-xfs@oss.sgi.com Thu Apr 29 21:54:04 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 29 Apr 2004 21:54:09 -0700 (PDT) Received: from office.labsysgrp.com (wsip-68-14-253-125.ph.ph.cox.net [68.14.253.125]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3U4s4KO028293 for ; Thu, 29 Apr 2004 21:54:04 -0700 Received: from [127.0.0.1] (helo=localhost) by office.labsysgrp.com with esmtp (Exim 4.24) id 1BJQ2A-0001al-Pv for linux-xfs@oss.sgi.com; Thu, 29 Apr 2004 21:53:58 -0700 Received: from office.labsysgrp.com ([127.0.0.1]) by localhost (office.lsg.internal [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06088-01 for ; Thu, 29 Apr 2004 21:53:58 -0700 (MST) Received: from jeeves.kpf.internal ([192.168.170.1]) by office.labsysgrp.com with esmtp (Exim 4.24) id 1BJQ2A-0001af-4G for linux-xfs@oss.sgi.com; Thu, 29 Apr 2004 21:53:58 -0700 Received: from [192.168.172.107] (helo=backtobasicsmgmt.com) by jeeves.kpf.internal with esmtp (Exim 4.05) id 1BJQ29-0002nl-00 for linux-xfs@oss.sgi.com; Thu, 29 Apr 2004 21:53:57 -0700 Message-ID: <4091DBE6.60301@backtobasicsmgmt.com> Date: Thu, 29 Apr 2004 21:53:58 -0700 From: "Kevin P. Fleming" Organization: Back To Basics Network Management User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Cross-compile of xfsprogs-2.6.10 fails Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at labsysgrp.com X-archive-position: 2978 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kpfleming@backtobasicsmgmt.com Precedence: bulk X-list: linux-xfs Content-Length: 639 Lines: 12 I'm trying to cross-compile xfsprogs-2.6.10. I have successfully run the configure script specifying the correct build, target and host strings. Most of xfsprogs builds properly, except for mkfs. Building mkfs requires building mkfs/maxtrres and then _running_ it, which means its a build-system binary, not a target binary. Unfortunately the xfsprogs Makefiles don't make any distinction, and use the target compiler/linker to build maxtrres, which means it won't run on the build system. I can manually build and run it for now using the correct compiler/linker, but this should be properly fixed in the xfsprogs distribution. From owner-linux-xfs@oss.sgi.com Thu Apr 29 22:03:55 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 29 Apr 2004 22:03:59 -0700 (PDT) Received: from omx2.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3U53iKO028838 for ; Thu, 29 Apr 2004 22:03:44 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with SMTP id i3U7Bkov013872 for ; Fri, 30 Apr 2004 00:11:56 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA02200; Fri, 30 Apr 2004 15:02:41 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i3U52eln033195; Fri, 30 Apr 2004 15:02:40 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i3U52cNj033707; Fri, 30 Apr 2004 15:02:38 +1000 (EST) Date: Fri, 30 Apr 2004 15:02:38 +1000 From: Nathan Scott To: "Kevin P. Fleming" Cc: linux-xfs@oss.sgi.com, ivanr@sgi.com Subject: Re: Cross-compile of xfsprogs-2.6.10 fails Message-ID: <20040430150238.B32573@wobbly.melbourne.sgi.com> References: <4091DBE6.60301@backtobasicsmgmt.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4091DBE6.60301@backtobasicsmgmt.com>; from kpfleming@backtobasicsmgmt.com on Thu, Apr 29, 2004 at 09:53:58PM -0700 X-archive-position: 2979 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 984 Lines: 23 On Thu, Apr 29, 2004 at 09:53:58PM -0700, Kevin P. Fleming wrote: > I'm trying to cross-compile xfsprogs-2.6.10. I have successfully run the > configure script specifying the correct build, target and host strings. > Most of xfsprogs builds properly, except for mkfs. Building mkfs > requires building mkfs/maxtrres and then _running_ it, which means its a > build-system binary, not a target binary. Unfortunately the xfsprogs > Makefiles don't make any distinction, and use the target compiler/linker > to build maxtrres, which means it won't run on the build system. > > I can manually build and run it for now using the correct > compiler/linker, but this should be properly fixed in the xfsprogs > distribution. Ivan had a version of mkfs that does away with the maxtrres program completely, and the whopping big table it generates. I should follow up with him and get that merged sometime, it will have the side-effect of resolving this problem. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Apr 29 22:18:31 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 29 Apr 2004 22:18:35 -0700 (PDT) Received: from office.labsysgrp.com (wsip-68-14-253-125.ph.ph.cox.net [68.14.253.125]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3U5IVKO029463 for ; Thu, 29 Apr 2004 22:18:31 -0700 Received: from [127.0.0.1] (helo=localhost) by office.labsysgrp.com with esmtp (Exim 4.24) id 1BJQPq-0001bu-EL; Thu, 29 Apr 2004 22:18:26 -0700 Received: from office.labsysgrp.com ([127.0.0.1]) by localhost (office.lsg.internal [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06088-03; Thu, 29 Apr 2004 22:18:25 -0700 (MST) Received: from jeeves.kpf.internal ([192.168.170.1]) by office.labsysgrp.com with esmtp (Exim 4.24) id 1BJQPp-0001bo-Oz; Thu, 29 Apr 2004 22:18:25 -0700 Received: from [192.168.172.107] (helo=backtobasicsmgmt.com) by jeeves.kpf.internal with esmtp (Exim 4.05) id 1BJQPp-0000yk-00; Thu, 29 Apr 2004 22:18:25 -0700 Message-ID: <4091E1A2.90709@backtobasicsmgmt.com> Date: Thu, 29 Apr 2004 22:18:26 -0700 From: "Kevin P. Fleming" Organization: Back To Basics Network Management User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nathan Scott CC: linux-xfs@oss.sgi.com, ivanr@sgi.com Subject: Re: Cross-compile of xfsprogs-2.6.10 fails References: <4091DBE6.60301@backtobasicsmgmt.com> <20040430150238.B32573@wobbly.melbourne.sgi.com> In-Reply-To: <20040430150238.B32573@wobbly.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at labsysgrp.com X-archive-position: 2980 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kpfleming@backtobasicsmgmt.com Precedence: bulk X-list: linux-xfs Content-Length: 500 Lines: 12 Nathan Scott wrote: > Ivan had a version of mkfs that does away with the maxtrres > program completely, and the whopping big table it generates. > I should follow up with him and get that merged sometime, it > will have the side-effect of resolving this problem. Yes please, the problem is much worse than I originally reported, because maxtrres uses libxfs, which means libxfs has to be built for the build system, run maxtrres, then throw away libxfs and rebuild it for the target. Yuck. :-) From owner-linux-xfs@oss.sgi.com Fri Apr 30 10:03:23 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 30 Apr 2004 10:03:27 -0700 (PDT) Received: from office.labsysgrp.com (wsip-68-14-253-125.ph.ph.cox.net [68.14.253.125]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3UH3LKO019657 for ; Fri, 30 Apr 2004 10:03:23 -0700 Received: from [127.0.0.1] (helo=localhost) by office.labsysgrp.com with esmtp (Exim 4.24) id 1BJbPv-0002BG-RG for linux-xfs@oss.sgi.com; Fri, 30 Apr 2004 10:03:15 -0700 Received: from office.labsysgrp.com ([127.0.0.1]) by localhost (office.lsg.internal [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08361-01 for ; Fri, 30 Apr 2004 10:03:15 -0700 (MST) Received: from jeeves.kpf.internal ([192.168.170.1]) by office.labsysgrp.com with esmtp (Exim 4.24) id 1BJbPv-0002B9-0o for linux-xfs@oss.sgi.com; Fri, 30 Apr 2004 10:03:15 -0700 Received: from [192.168.172.107] (helo=backtobasicsmgmt.com) by jeeves.kpf.internal with esmtp (Exim 4.05) id 1BJbPu-0000CM-00 for linux-xfs@oss.sgi.com; Fri, 30 Apr 2004 10:03:14 -0700 Message-ID: <409286D4.90804@backtobasicsmgmt.com> Date: Fri, 30 Apr 2004 10:03:16 -0700 From: "Kevin P. Fleming" Organization: Back To Basics Network Management User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: [PATCH] xfsprogs does not support DESTDIR for "make install" Content-Type: multipart/mixed; boundary="------------010203090304090507070008" X-Virus-Scanned: by amavisd-new at labsysgrp.com X-archive-position: 2981 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kpfleming@backtobasicsmgmt.com Precedence: bulk X-list: linux-xfs Content-Length: 1504 Lines: 46 This is a multi-part message in MIME format. --------------010203090304090507070008 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Very simple, just prefixes DESTDIR on all the destination paths so xfsprogs can be installed somewhere different than --prefix was set for. If there's another way to accomplish this with the existing Makefiles please let me know, I couldn't seem to find it. --------------010203090304090507070008 Content-Type: text/plain; name="xfsprogs-DESTDIR.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="xfsprogs-DESTDIR.patch" --- xfsprogs-2.6.10/include/builddefs.old Thu Apr 29 22:44:25 2004 +++ xfsprogs-2.6.10/include/builddefs.in Thu Apr 29 22:45:06 2004 @@ -60,14 +60,14 @@ PKG_VERSION = @pkg_version@ PKG_PLATFORM = @pkg_platform@ PKG_DISTRIBUTION= @pkg_distribution@ -PKG_BIN_DIR = @bindir@ -PKG_SBIN_DIR = @sbindir@ -PKG_LIB_DIR = @libdir@ -PKG_DEVLIB_DIR = @libexecdir@ -PKG_INC_DIR = @includedir@/xfs -PKG_MAN_DIR = @mandir@ -PKG_DOC_DIR = @datadir@/doc/@pkg_name@ -PKG_LOCALE_DIR = @datadir@/locale +PKG_BIN_DIR = $(DESTDIR)@bindir@ +PKG_SBIN_DIR = $(DESTDIR)@sbindir@ +PKG_LIB_DIR = $(DESTDIR)@libdir@ +PKG_DEVLIB_DIR = $(DESTDIR)@libexecdir@ +PKG_INC_DIR = $(DESTDIR)@includedir@/xfs +PKG_MAN_DIR = $(DESTDIR)@mandir@ +PKG_DOC_DIR = $(DESTDIR)@datadir@/doc/@pkg_name@ +PKG_LOCALE_DIR = $(DESTDIR)@datadir@/locale CC = @cc@ AWK = @awk@ --------------010203090304090507070008-- From owner-linux-xfs@oss.sgi.com Fri Apr 30 10:38:50 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 30 Apr 2004 10:38:55 -0700 (PDT) Received: from hell.org.pl (qmailr@hell.org.pl [212.244.218.42]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3UHcnKO021920 for ; Fri, 30 Apr 2004 10:38:49 -0700 Received: (qmail 193 invoked by uid 777); 30 Apr 2004 17:38:53 -0000 Date: Fri, 30 Apr 2004 19:38:53 +0200 From: Karol Kozimor To: linux-xfs@oss.sgi.com Subject: Indestructible directories? Message-ID: <20040430173853.GC1844@hell.org.pl> Mail-Followup-To: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline User-Agent: Mutt/1.4.2i X-archive-position: 2982 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sziwan@hell.org.pl Precedence: bulk X-list: linux-xfs Content-Length: 1872 Lines: 46 Hi, I suffered from major filesystem corruption while testing third party patches. The filesystem shut down and was handled with xfs_repair. After that, several directories were found in /lost+found that could no longer be removed, e.g.: # ls -la /lost+found/12616156/ total 8 drwxrwxrwx 2 root root 4096 2004-04-29 15:22 ./ drwxr-xr-x 12 root root 155 2004-04-30 10:53 ../ # rmdir /lost+found/12616156 rmdir: `/lost+found/12616156': Directory not empty # # rm -rf /lost+found/12616156 rm: cannot remove directory `/lost+found/12616156': Directory not empty Here's a trace of rm -rf /lost+found/12616156: #v+ unlink("/lost+found/12616156") = -1 EISDIR (Is a directory) open(".", O_RDONLY|O_LARGEFILE|O_DIRECTORY) = 3 lstat64("/lost+found/12616156", {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0 chdir("/lost+found/12616156") = 0 lstat64(".", {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0 open("/dev/null", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = -1 ENOTDIR (Not a directory) open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 4 fstat64(4, {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0 fcntl64(4, F_SETFD, FD_CLOEXEC) = 0 brk(0) = 0x8054000 brk(0x8055000) = 0x8055000 getdents64(4, /* 2 entries */, 4096) = 48 getdents64(4, /* 0 entries */, 4096) = 0 close(4) = 0 fchdir(3) = 0 lstat64(".", {st_mode=S_IFDIR|0710, st_size=4096, ...}) = 0 rmdir("/lost+found/12616156") = -1 ENOTEMPTY (Directory not empty) #v- Subsequent xfs_repair runs do not fix the problem, the directories are simply unlinked and relinked in /lost+found. Was it ext2, I would have used debugfs. What can I do to rectify this and / or provide any useful information? Best regards, -- Karol 'sziwan' Kozimor sziwan@hell.org.pl From owner-linux-xfs@oss.sgi.com Fri Apr 30 12:05:50 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 30 Apr 2004 12:05:56 -0700 (PDT) Received: from hptimail01.HPTI.COM ([208.20.6.201]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3UJ5nKO023892 for ; Fri, 30 Apr 2004 12:05:50 -0700 Received: from hpti9.fsl.noaa.gov ([137.75.132.229]) by hptimail01.HPTI.COM with Microsoft SMTPSVC(6.0.3790.0); Fri, 30 Apr 2004 15:06:13 -0400 Subject: Re: Using debug and tracing features in 2.4.26 From: Craig Tierney To: Jeremy Jackson Cc: Steve Lord , linux-xfs@oss.sgi.com In-Reply-To: <40905F8F.5020100@coplanar.net> References: <1083086648.2374.15.camel@hpti9.fsl.noaa.gov> <408EAC06.7010404@xfs.org> <40905F8F.5020100@coplanar.net> Content-Type: text/plain Message-Id: <1083351887.2377.12.camel@hpti9.fsl.noaa.gov> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 30 Apr 2004 13:04:47 -0600 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Apr 2004 19:06:13.0588 (UTC) FILETIME=[34C4B940:01C42EE6] X-archive-position: 2983 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ctierney@HPTI.com Precedence: bulk X-list: linux-xfs Content-Length: 788 Lines: 24 On Wed, 2004-04-28 at 19:51, Jeremy Jackson wrote: > Steve Lord wrote: > > > Any reason for turning on debug? It adds thousands of checks to > > the code base, any one of them will oops if it triggers. Never > > run this way with data you care about. > > > So I've been causing the problems I'm seeing by turning debug on? > I'm getting a debug related oops about every 2 months, but wouldn't > turning debug off just cause silent data corruption? > > I don't recall reading any dire warnings in the help for the configure > option, although it does say for XFS developers only. > > If it is the official recommendation, I will turn it off. Have you actually found any data corruption? Or you just see oopses every once and awhile, but those might not cause corruption? Craig From owner-linux-xfs@oss.sgi.com Fri Apr 30 15:34:26 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 30 Apr 2004 15:34:30 -0700 (PDT) Received: from postfix4-1.free.fr (postfix4-1.free.fr [213.228.0.62]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i3UMYPKO001912 for ; Fri, 30 Apr 2004 15:34:26 -0700 Received: from lns-th2-4f-81-56-250-144.adsl.proxad.net (lns-th2-4f-81-56-250-144.adsl.proxad.net [81.56.250.144]) by postfix4-1.free.fr (Postfix) with ESMTP id E8C4E102D70; Sat, 1 May 2004 00:34:23 +0200 (CEST) From: Johann Lombardi Reply-To: johann.lombardi@free.fr To: Nathan Scott Subject: Re: Unsupported sector size Date: Sat, 1 May 2004 00:40:06 +0200 User-Agent: KMail/1.5.4 Cc: linux-xfs@oss.sgi.com References: <200404292134.23178.johann.lombardi@free.fr> <20040430111412.A28855@wobbly.melbourne.sgi.com> <20040430111634.B28855@wobbly.melbourne.sgi.com> In-Reply-To: <20040430111634.B28855@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200405010040.06340.johann.lombardi@free.fr> X-archive-position: 2985 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: johann.lombardi@free.fr Precedence: bulk X-list: linux-xfs Content-Length: 2707 Lines: 56 > > The message is indeed correct. You should have got a warning > > from mkfs.xfs when you created the filesystem flagging this as > > a problem too - did you? (cos if not, thats a driver bug that > > should be fixed). Arrr, read the error message too fast, it is indeed correct. Sorry. > Gak, pressed "send" too soon :) -- you'll want to use -ssize=4k > at mkfs time with this device, if you haven't found that option > already. My xfsprogs is to old, this option isn't available. I am going to upgrade this package as soon as possible. Thanks. After this issue, I decided to change the sector size from 4096 to 512. I encountered no problem with the mkfs. However, when I wanted to mount the device, I got the following call trace in dmesg : Filesystem "sdh": XFS internal error xfs_mount_validate_sb(4) at line 281 of file fs/xfs/xfs_mount.c. Caller 0xa000000200a26260 Call Trace: [] show_stack+0x80/0xa0 sp=e0000013f805fb50 bsp=e0000013f8059558 [] xfs_error_report+0xb0/0xc0 [xfs] sp=e0000013f805fd20 bsp=e0000013f8059510 [] xfs_mount_validate_sb+0x4b0/0x6e0 [xfs] sp=e0000013f805fd20 bsp=e0000013f80594e8 [] xfs_readsb+0x200/0x440 [xfs] sp=e0000013f805fd20 bsp=e0000013f80594a0 [] xfs_mount+0x5c0/0x960 [xfs] sp=e0000013f805fd20 bsp=e0000013f8059438 [] vfs_mount+0xd0/0x100 [xfs] sp=e0000013f805fd30 bsp=e0000013f8059408 [] linvfs_fill_super+0x180/0x520 [xfs] sp=e0000013f805fd30 bsp=e0000013f80593b8 [] get_sb_bdev+0x270/0x360 sp=e0000013f805fdc0 bsp=e0000013f8059370 [] linvfs_get_sb+0x40/0x60 [xfs] sp=e0000013f805fde0 bsp=e0000013f8059338 [] do_kern_mount+0xb0/0x280 sp=e0000013f805fde0 bsp=e0000013f80592f0 [] do_add_mount+0x100/0x380 sp=e0000013f805fde0 bsp=e0000013f80592a8 [] do_mount+0x210/0x280 sp=e0000013f805fde0 bsp=e0000013f8059260 [] sys_mount+0x180/0x2c0 sp=e0000013f805fe10 bsp=e0000013f80591d8 [] ia64_ret_from_syscall+0x0/0x20 sp=e0000013f805fe30 bsp=e0000013f80591d8 XFS: SB validate failed Any idea of what's wrong? Thanks for your help. Cheers, Johann From owner-linux-xfs@oss.sgi.com Fri Apr 30 21:18:54 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 30 Apr 2004 21:18:58 -0700 (PDT) Received: from omx2.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i414IsKO020573 for ; Fri, 30 Apr 2004 21:18:54 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i414KEBO018885 for ; Fri, 30 Apr 2004 21:20:15 -0700 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i414ImKe37850739; Fri, 30 Apr 2004 23:18:48 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i414ImHP1599369; Fri, 30 Apr 2004 23:18:48 -0500 (CDT) Date: Fri, 30 Apr 2004 23:18:48 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Steve Lord cc: linux-xfs@oss.sgi.com Subject: Re: bugzilla entries for XFS in Fedora Core 2 test 3 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2987 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 804 Lines: 31 problem is that mkfs.xfs wasn't quite obliterating the raid sb for some device sizes, and mount-by-label code bails out when it finds that. will fix shortly. -eric On Thu, 29 Apr 2004, Eric Sandeen wrote: > florin, i hand-labeled & mounted a filesystem on an fc2test3 system, > no problems... > > can you try xfs_admin -l on the devices in question to see if they > have valid fs labels? > > -Eric > > On Thu, 29 Apr 2004, Steve Lord wrote: > > > > 122043 > > XFS does labels just fine, something else is going on here, in fact I > > have a fedora core setup which is all XFS (except /boot because of > > the grub issue). I have about 4 filesystems which all mount fine, > > but I am using device mapper for them all which probably changes > > the mount sequence. > > > > Steve > > > > > > From owner-linux-xfs@oss.sgi.com Fri Apr 30 21:31:37 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 30 Apr 2004 21:31:42 -0700 (PDT) Received: from omx1.americas.sgi.com (cfcafw.sgi.com [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i414VaKO021170 for ; Fri, 30 Apr 2004 21:31:37 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i414PHBN018219 for ; Fri, 30 Apr 2004 23:25:17 -0500 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i414PEKe37805563; Fri, 30 Apr 2004 23:25:14 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i414PEHP1616873; Fri, 30 Apr 2004 23:25:14 -0500 (CDT) Date: Fri, 30 Apr 2004 23:25:14 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Johann Lombardi cc: Nathan Scott , Subject: Re: Unsupported sector size In-Reply-To: <200405010040.06340.johann.lombardi@free.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2988 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 694 Lines: 28 On Sat, 1 May 2004, Johann Lombardi wrote: > After this issue, I decided to change the sector size from 4096 to 512. > I encountered no problem with the mkfs. However, when I wanted to mount the > device, I got the following call trace in dmesg : > > Filesystem "sdh": XFS internal error xfs_mount_validate_sb(4) at line 281 > of file fs/xfs/xfs_mount.c. Caller 0xa000000200a26260 you get this message if: you have 0 data blocks in your fs or your data block count doesn't jive with the allocation groups & ag size try: xfs_db /dev/whatever sb 0 p dblocks p agcount p agblocks and send the results (and look at that line in xfs_mount.c and sort out what's wrong if you'd like) -Eric