From owner-xfs@oss.sgi.com Wed Nov 1 15:51:31 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 01 Nov 2006 15:51:38 -0800 (PST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kA1NpUaG032113 for ; Wed, 1 Nov 2006 15:51:31 -0800 X-ASG-Debug-ID: 1162420629-18514-10-0 X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.mmtab.se (unknown [212.209.150.85]) by cuda.sgi.com (Spam Firewall) with ESMTP id 8515C4EA816 for ; Wed, 1 Nov 2006 14:37:09 -0800 (PST) Received: from [10.0.0.145] ([212.209.150.84]) (authenticated bits=0) by mail.mmtab.se (8.13.7/8.13.7) with ESMTP id kA1Mb71W003236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 1 Nov 2006 23:37:08 +0100 Message-ID: <4549218B.2020807@mmtab.se> Date: Wed, 01 Nov 2006 23:36:59 +0100 From: Per Mellander User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: xfs@oss.sgi.com X-ASG-Orig-Subj: xfs_growfs after lvextend don't increase mounted size. Subject: xfs_growfs after lvextend don't increase mounted size. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Spam-Score: 1.10 X-Barracuda-Spam-Status: No, SCORE=1.10 using per-user scores of TAG_LEVEL=3.5 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC1_SA036d X-Barracuda-Spam-Report: Code version 3.02, rules version 3.0.24778 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 1.10 BSF_SC1_SA036d Custom Rule SA036d X-archive-position: 9514 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: per.m@mmtab.se Precedence: bulk X-list: xfs Content-Length: 1909 Lines: 61 Hi! I've got a 6.5TB xfs filesystem on a LVM2 volume. I wanted to increase the size of the fs so I added another ~10TB to the volume. Every step taken was successfull, (ie no errors) but the filesystem size remained unchanged even after the xfs_growfs. What I did was the following: I extended the lvm using pvcreate, vgextend and finally lvextend. pvscan gives: PV /dev/sda1 VG vg01 lvm2 [1.59 TB / 0 free] PV /dev/sdb1 VG vg01 lvm2 [1.59 TB / 0 free] PV /dev/sdc1 VG vg01 lvm2 [1.59 TB / 0 free] PV /dev/sdd1 VG vg01 lvm2 [1.59 TB / 0 free] PV /dev/sde1 VG vg01 lvm2 [2.00 TB / 0 free] PV /dev/sdf1 VG vg01 lvm2 [2.00 TB / 0 free] PV /dev/sdg1 VG vg01 lvm2 [2.00 TB / 0 free] PV /dev/sdh1 VG vg01 lvm2 [2.00 TB / 0 free] PV /dev/sdi1 VG vg01 lvm2 [1.55 TB / 0 free] Total: 9 [15.91 TB] / in use: 9 [15.91 TB] / in no VG: 0 [0 ] and lvdisplay: --- Logical volume --- LV Name /dev/vg01/lv01 VG Name vg01 LV UUID rDSEQ3-DdhV-oLci-nNYT-dMdX-cppA-7v1r3e LV Write Access read/write LV Status available # open 1 LV Size 15.91 TB Current LE 4169996 Segments 9 Allocation inherit Read ahead sectors 0 Block device 253:0 After xfs_growfs /vol1 ( mounted fs ) df -h gives: /dev/mapper/vg01-lv01 6.4T 6.4T 36G 100% /vol1 The fs remains in previous size!! # cat /sys/block/dm-0/size 34160607232 which is equal to 15.91 TB Have I missed something when I extended the volume / growed the xfs fs? The system running xfs is a Fedora Core 4, 2.6.15-1.1831_FC4smp, lvm2-2.01.08-2.1, xfsprogs-2.6.13-4 Per _________________________________ This email has been ClamScanned ! www.clamav.net From owner-xfs@oss.sgi.com Wed Nov 1 19:43:56 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 01 Nov 2006 19:44:07 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kA23hraG015861 for ; Wed, 1 Nov 2006 19:43:55 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA29220; Thu, 2 Nov 2006 14:42:59 +1100 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 kA23gv7Y22495852; Thu, 2 Nov 2006 14:42:57 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id kA23gsYm22416042; Thu, 2 Nov 2006 14:42:54 +1100 (AEDT) Date: Thu, 2 Nov 2006 14:42:54 +1100 From: David Chinner To: Per Mellander Cc: xfs@oss.sgi.com Subject: Re: xfs_growfs after lvextend don't increase mounted size. Message-ID: <20061102034254.GC11034@melbourne.sgi.com> References: <4549218B.2020807@mmtab.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4549218B.2020807@mmtab.se> User-Agent: Mutt/1.4.2.1i X-archive-position: 9518 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 840 Lines: 27 On Wed, Nov 01, 2006 at 11:36:59PM +0100, Per Mellander wrote: > Hi! > > I've got a 6.5TB xfs filesystem on a LVM2 volume. I wanted to increase > the size of the fs so I added another ~10TB to the volume. Every step > taken was successfull, (ie no errors) but the filesystem size remained > unchanged even after the xfs_growfs. There's a 32 bit overflow in the growfs code (and transaction code on 32 bit systems) so you can't grow by more than 2TB at a time. I've got a fix under test for this at the moment. Can you see if you can grow using: # xfs_growfs -D FSB = filesystem block size, and the current size is also in FSB. You can get both the current size and the FSB from xfs_growfs -n Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Wed Nov 1 22:08:00 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 01 Nov 2006 22:08:09 -0800 (PST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kA267xaG011292 for ; Wed, 1 Nov 2006 22:08:00 -0800 X-ASG-Debug-ID: 1162443331-27234-621-0 X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.233]) by cuda.sgi.com (Spam Firewall) with ESMTP id 57CDA4E771A for ; Wed, 1 Nov 2006 20:55:31 -0800 (PST) Received: by wx-out-0506.google.com with SMTP id h29so27101wxd for ; Wed, 01 Nov 2006 20:55:31 -0800 (PST) Received: by 10.70.90.12 with SMTP id n12mr10854229wxb; Wed, 01 Nov 2006 19:57:04 -0800 (PST) Received: from ?192.168.23.241? ( [208.195.10.2]) by mx.google.com with ESMTP id h14sm1810249wxd.2006.11.01.19.57.04; Wed, 01 Nov 2006 19:57:04 -0800 (PST) Message-ID: <45496C84.4090309@novacell.com> Date: Wed, 01 Nov 2006 19:56:52 -0800 From: John Novak User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: xfs@oss.sgi.com X-ASG-Orig-Subj: xfs over iscsi via initiator on CentOS 4.4 Subject: xfs over iscsi via initiator on CentOS 4.4 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=3.5 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.02, rules version 3.0.24802 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-archive-position: 9519 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jnovak@novacell.com Precedence: bulk X-list: xfs Content-Length: 470 Lines: 16 Does anyone have information about running an xfs file system over iscsi from the CentOS 4.4 iscsi initiator ? The only post I could find about this is one from Aug of 04 indicating a known issue. (http://oss.sgi.com/archives/xfs/2004-08/msg00155.html) I tries this on CentOS 4.4 with kernel 2.6.9-42.0.3.plus.c4smp running on a dual core AMD proc. I'm seeing the same symptom as reported in this earlier post. Any pointers are appreciated, Best, John Novak From owner-xfs@oss.sgi.com Thu Nov 2 09:26:58 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 02 Nov 2006 09:27:06 -0800 (PST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kA2HQvaG013977 for ; Thu, 2 Nov 2006 09:26:58 -0800 X-ASG-Debug-ID: 1162488370-28353-201-0 X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from rrzmta2.rz.uni-regensburg.de (rrzmta2.rz.uni-regensburg.de [132.199.1.17]) by cuda.sgi.com (Spam Firewall) with ESMTP id EDF404ED0B6 for ; Thu, 2 Nov 2006 09:26:11 -0800 (PST) Received: from rrzmta2.rz.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B5BCF6C6AB for ; Thu, 2 Nov 2006 18:26:15 +0100 (CET) Received: from pc51072.physik.uni-regensburg.de (pc51072.physik.uni-regensburg.de [132.199.98.129]) by rrzmta2.rz.uni-regensburg.de (Postfix) with ESMTP id B04656C67E for ; Thu, 2 Nov 2006 18:26:15 +0100 (CET) Received: by pc51072.physik.uni-regensburg.de (Postfix, from userid 28561) id 883F4507058; Thu, 2 Nov 2006 18:26:08 +0100 (CET) Date: Thu, 2 Nov 2006 18:26:08 +0100 From: Christian Guggenberger To: xfs@oss.sgi.com X-ASG-Orig-Subj: mount failed after xfs_growfs beyond 16 TB Subject: mount failed after xfs_growfs beyond 16 TB Message-ID: <20061102172608.GA27769@pc51072.physik.uni-regensburg.de> Reply-To: christian.guggenberger@physik.uni-regensburg.de Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i X-Barracuda-Spam-Score: 0.50 X-Barracuda-Spam-Status: No, SCORE=0.50 using per-user scores of TAG_LEVEL=3.5 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_RULE7568M X-Barracuda-Spam-Report: Code version 3.02, rules version 3.0.24854 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.50 BSF_RULE7568M BODY: Custom Rule 7568M X-archive-position: 9523 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: christian.guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: xfs Content-Length: 2978 Lines: 78 Hi, a colleague recently tried to grow a 16 TB filesystem (x86, 32bit) on top of lvm2 to 17TB. (I am not even sure if that's supposed work with linux-2.6, 32bit) used kernel seems to be debian sarge's 2.6.8 xfs_growfs seemed to succeed (AFAIK..) however, the fs shut down: XFS internal error XFS_WANT_CORRUPTED_GOTO at line 1583 of file fs/xfs/xfs_alloc.c. Caller 0xf89978a8 [__crc_pm_idle+550816/2056674] xfs_free_ag_extent+0x454/0x78a [xfs] [__crc_pm_idle+555561/2056674] xfs_free_extent+0xea/0x10f [xfs] [__crc_pm_idle+555561/2056674] xfs_free_extent+0xea/0x10f [xfs] [__crc_pm_idle+553757/2056674] xfs_alloc_read_agf+0xbe/0x1e4 [xfs] [__crc_pm_idle+764480/2056674] xfs_growfs_data_private+0xd80/0xec0 [xfs] [pty_write+305/307] pty_write+0x131/0x133 [opost+154/428] opost+0x9a/0x1ac [__crc_pm_idle+765024/2056674] xfs_growfs_data+0x3f/0x5e [xfs] [__crc_pm_idle+972873/2056674] xfs_ioctl+0x256/0x860 [xfs] [tty_write+436/788] tty_write+0x1b4/0x314 [write_chan+0/538] write_chan+0x0/0x21a [__crc_pm_idle+968754/2056674] linvfs_ioctl+0x78/0x101 [xfs] [sys_ioctl+315/675] sys_ioctl+0x13b/0x2a3 [syscall_call+7/11] syscall_call+0x7/0xb xfs_force_shutdown(dm-1,0x8) called from line 1088 of file fs/xfs/xfs_trans.c. Return address = 0xf8a01c3c Filesystem "dm-1": Corruption of in-memory data detected. Shutting down filesystem: dm-1 Please umount the filesystem, and rectify the problem(s) xfs_force_shutdown(dm-1,0x1) called from line 353 of file fs/xfs/xfs_rw.c. Return address = 0xf8a01c3c mounting fails with: XFS: SB sanity check 2 failed Filesystem "dm-1": XFS internal error xfs_mount_validate_sb(4) at line 277 of file fs/xfs/xfs_mount.c. Caller 0xf89e568c [__crc_pm_idle+872883/2056674] xfs_mount_validate_sb+0x21d/0x39a [xfs] [__crc_pm_idle+874509/2056674] xfs_readsb+0xee/0x1f9 [xfs] [__crc_pm_idle+874509/2056674] xfs_readsb+0xee/0x1f9 [xfs] [__crc_pm_idle+908971/2056674] xfs_mount+0x282/0x5d4 [xfs] [__crc_pm_idle+989973/2056674] vfs_mount+0x34/0x38 [xfs] [__crc_pm_idle+989973/2056674] vfs_mount+0x34/0x38 [xfs] [__crc_pm_idle+989534/2056674] linvfs_fill_super+0xa1/0x1ee [xfs] [snprintf+39/43] snprintf+0x27/0x2b [disk_name+169/171] disk_name+0xa9/0xab [sb_set_blocksize+46/93] sb_set_blocksize+0x2e/0x5d [get_sb_bdev+262/313] get_sb_bdev+0x106/0x139 [__crc_pm_idle+989914/2056674] linvfs_get_sb+0x2f/0x36 [xfs] [__crc_pm_idle+989373/2056674] linvfs_fill_super+0x0/0x1ee [xfs] [do_kern_mount+162/354] do_kern_mount+0xa2/0x162 [do_new_mount+115/181] do_new_mount+0x73/0xb5 [do_mount+370/446] do_mount+0x172/0x1be [copy_mount_options+99/188] copy_mount_options+0x63/0xbc [sys_mount+212/344] sys_mount+0xd4/0x158 [syscall_call+7/11] syscall_call+0x7/0xb XFS: SB validate failed XFS: SB sanity check 2 failed and finally, xfs_repair stops at bad primary superblock: inconsistent file geometrie information found candidate secondary superblock... superblock read failed, offset 10093861404672, size 2048, ag 0, rval 29 thanks in advance, - Christian From owner-xfs@oss.sgi.com Thu Nov 2 10:39:59 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 02 Nov 2006 10:40:05 -0800 (PST) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kA2IdwaG023870 for ; Thu, 2 Nov 2006 10:39:59 -0800 X-ASG-Debug-ID: 1162492753-26243-917-0 X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by cuda.sgi.com (Spam Firewall) with ESMTP id 7F998D1BB033 for ; Thu, 2 Nov 2006 10:39:13 -0800 (PST) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id kA2IcdjR009922; Thu, 2 Nov 2006 13:38:39 -0500 Received: from pobox-2.corp.redhat.com (pobox-2.corp.redhat.com [10.11.255.15]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id kA2IcYL8032472; Thu, 2 Nov 2006 13:38:34 -0500 Received: from [10.15.80.10] (neon.msp.redhat.com [10.15.80.10]) by pobox-2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id kA2IcXmw030023; Thu, 2 Nov 2006 13:38:34 -0500 Message-ID: <454A3B28.7010405@sandeen.net> Date: Thu, 02 Nov 2006 12:38:32 -0600 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.7 (X11/20060913) MIME-Version: 1.0 To: christian.guggenberger@physik.uni-regensburg.de CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: mount failed after xfs_growfs beyond 16 TB Subject: Re: mount failed after xfs_growfs beyond 16 TB References: <20061102172608.GA27769@pc51072.physik.uni-regensburg.de> In-Reply-To: <20061102172608.GA27769@pc51072.physik.uni-regensburg.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=3.5 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.02, rules version 3.0.24856 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-archive-position: 9525 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 4040 Lines: 121 Christian Guggenberger wrote: > Hi, > > a colleague recently tried to grow a 16 TB filesystem (x86, 32bit) on > top of lvm2 to 17TB. (I am not even sure if that's supposed work with > linux-2.6, 32bit) If you have CONFIG_LBD enabled (do you?), it should in theory, barring bugs :) > used kernel seems to be debian sarge's 2.6.8 hmm old.... > xfs_growfs seemed to succeed (AFAIK..) trace below looks like not... > however, the fs shut down: > > XFS internal error > XFS_WANT_CORRUPTED_GOTO at line 1583 of file fs/xfs/xfs_alloc.c. Caller > 0xf89978a8 > [__crc_pm_idle+550816/2056674] xfs_free_ag_extent+0x454/0x78a [xfs] > [__crc_pm_idle+555561/2056674] xfs_free_extent+0xea/0x10f [xfs] > [__crc_pm_idle+555561/2056674] xfs_free_extent+0xea/0x10f [xfs] > [__crc_pm_idle+553757/2056674] xfs_alloc_read_agf+0xbe/0x1e4 [xfs] in the growfs thread here > [__crc_pm_idle+764480/2056674] xfs_growfs_data_private+0xd80/0xec0 [xfs] > [pty_write+305/307] pty_write+0x131/0x133 > [opost+154/428] opost+0x9a/0x1ac > [__crc_pm_idle+765024/2056674] xfs_growfs_data+0x3f/0x5e [xfs] > [__crc_pm_idle+972873/2056674] xfs_ioctl+0x256/0x860 [xfs] > [tty_write+436/788] tty_write+0x1b4/0x314 > [write_chan+0/538] write_chan+0x0/0x21a > [__crc_pm_idle+968754/2056674] linvfs_ioctl+0x78/0x101 [xfs] > [sys_ioctl+315/675] sys_ioctl+0x13b/0x2a3 > [syscall_call+7/11] syscall_call+0x7/0xb > xfs_force_shutdown(dm-1,0x8) called > from line 1088 of file fs/xfs/xfs_trans.c. Return address = 0xf8a01c3c > Filesystem "dm-1": Corruption of > in-memory data detected. Shutting down filesystem: dm-1 > Please umount the filesystem, and > rectify the problem(s) > xfs_force_shutdown(dm-1,0x1) called > from line 353 of file fs/xfs/xfs_rw.c. Return address = 0xf8a01c3c > > mounting fails with: > > XFS: SB sanity check 2 failed This is checking: if (unlikely( sbp->sb_dblocks == 0 || sbp->sb_dblocks > (xfs_drfsbno_t)sbp->sb_agcount * sbp->sb_agblocks || sbp->sb_dblocks < (xfs_drfsbno_t)(sbp->sb_agcount - 1) * sbp->sb_agblocks + XFS_MIN_AG_BLOCKS)) { xfs_fs_mount_cmn_err(flags, "SB sanity check 2 failed"); return XFS_ERROR(EFSCORRUPTED); } can you point xfs_db -r /dev/dm-1 and then: xfs_db> sb 0 xfs_db> p let's see what you've got. Also how big does /proc/partitions think your new device is? > Filesystem "dm-1": XFS internal error > xfs_mount_validate_sb(4) at line 277 of file fs/xfs/xfs_mount.c. Caller > 0xf89e568c > [__crc_pm_idle+872883/2056674] xfs_mount_validate_sb+0x21d/0x39a [xfs] > [__crc_pm_idle+874509/2056674] xfs_readsb+0xee/0x1f9 [xfs] > [__crc_pm_idle+874509/2056674] xfs_readsb+0xee/0x1f9 [xfs] > [__crc_pm_idle+908971/2056674] xfs_mount+0x282/0x5d4 [xfs] > [__crc_pm_idle+989973/2056674] vfs_mount+0x34/0x38 [xfs] > [__crc_pm_idle+989973/2056674] vfs_mount+0x34/0x38 [xfs] > [__crc_pm_idle+989534/2056674] linvfs_fill_super+0xa1/0x1ee [xfs] > [snprintf+39/43] snprintf+0x27/0x2b > [disk_name+169/171] disk_name+0xa9/0xab > [sb_set_blocksize+46/93] sb_set_blocksize+0x2e/0x5d > [get_sb_bdev+262/313] get_sb_bdev+0x106/0x139 > [__crc_pm_idle+989914/2056674] linvfs_get_sb+0x2f/0x36 [xfs] > [__crc_pm_idle+989373/2056674] linvfs_fill_super+0x0/0x1ee [xfs] > [do_kern_mount+162/354] do_kern_mount+0xa2/0x162 > [do_new_mount+115/181] do_new_mount+0x73/0xb5 > [do_mount+370/446] do_mount+0x172/0x1be > [copy_mount_options+99/188] copy_mount_options+0x63/0xbc > [sys_mount+212/344] sys_mount+0xd4/0x158 > [syscall_call+7/11] syscall_call+0x7/0xb > XFS: SB validate failed > XFS: SB sanity check 2 failed > > and finally, xfs_repair stops at > > bad primary superblock: inconsistent file geometrie information > > found candidate secondary superblock... > superblock read failed, offset 10093861404672, size 2048, ag 0, rval 29 hmm that offset is about 9.4 terabytes. any kernel messages when this happens? rval 29 is ESPIPE / illegal seek. -Eric > thanks in advance, > > - Christian > > > From owner-xfs@oss.sgi.com Thu Nov 2 13:24:27 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 02 Nov 2006 13:24:34 -0800 (PST) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kA2LOQaG014015 for ; Thu, 2 Nov 2006 13:24:27 -0800 X-ASG-Debug-ID: 1162499093-7718-584-0 X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by cuda.sgi.com (Spam Firewall) with ESMTP id 37B28D1BB00B for ; Thu, 2 Nov 2006 12:24:53 -0800 (PST) Received: by ug-out-1314.google.com with SMTP id q2so203705uge for ; Thu, 02 Nov 2006 12:24:50 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:subject:date:message-id:mime-version:content-type:x-mailer:thread-index:x-mimeole:disposition-notification-to; b=S5Tr40n0VzXEbKOkkycMjw7BF8QbKC9892Tyr5kDCalgIATlIZkCRB22e9QYQ1EOrBr5Hz4oic6GmWlOfZFGxI5B//eoi94Jw/EFAIPsPfeHfR1SSgQ9vxqjTHQqxGAnCN45VwWWb3pKwXzbMFQl3aHZ0JJvPGbq7MbpmUUBXYg= Received: by 10.67.27.3 with SMTP id e3mr1329187ugj.1162498723188; Thu, 02 Nov 2006 12:18:43 -0800 (PST) Received: from home ( [84.94.68.186]) by mx.google.com with ESMTP id q1sm2665537uge.2006.11.02.12.18.40; Thu, 02 Nov 2006 12:18:42 -0800 (PST) From: "Uri Rotshtein" To: X-ASG-Orig-Subj: Adding xfs to kernel 2.4.20 Subject: Adding xfs to kernel 2.4.20 Date: Thu, 2 Nov 2006 22:18:15 +0300 Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acb95DpcKk7+x66/RvCKU7nzmnSqUQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=3.5 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.02, rules version 3.0.24864 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit X-archive-position: 9526 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: rotshtein@gmail.com Precedence: bulk X-list: xfs Content-Length: 142 Lines: 15 Hi, I'm using kernel 2.4.20 with Redhat 9 and would like to try the XFS filesystem. 10x, Uri. [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Thu Nov 2 14:28:04 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 02 Nov 2006 14:28:08 -0800 (PST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kA2MS2aG019617 for ; Thu, 2 Nov 2006 14:28:04 -0800 X-ASG-Debug-ID: 1162506436-22227-286-0 X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by cuda.sgi.com (Spam Firewall) with ESMTP id 329204EC724 for ; Thu, 2 Nov 2006 14:27:16 -0800 (PST) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id kA2MRErb012526; Thu, 2 Nov 2006 17:27:14 -0500 Received: from pobox-2.corp.redhat.com (pobox-2.corp.redhat.com [10.11.255.15]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id kA2MREeT028105; Thu, 2 Nov 2006 17:27:14 -0500 Received: from [10.15.80.10] (neon.msp.redhat.com [10.15.80.10]) by pobox-2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id kA2MRBhi019988; Thu, 2 Nov 2006 17:27:12 -0500 Message-ID: <454A70BE.8010906@sandeen.net> Date: Thu, 02 Nov 2006 16:27:10 -0600 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.7 (X11/20060913) MIME-Version: 1.0 To: Uri Rotshtein CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Adding xfs to kernel 2.4.20 Subject: Re: Adding xfs to kernel 2.4.20 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=3.5 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.02, rules version 3.0.24874 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-archive-position: 9528 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 271 Lines: 16 Uri Rotshtein wrote: > Hi, > > > > I'm using kernel 2.4.20 with Redhat 9 and would like to try the XFS > filesystem. > > you might look at ftp://oss.sgi.com/projects/xfs/testing/RHEL3/ although I'm not sure why you'd want to use such an old codebase :) -eric From owner-xfs@oss.sgi.com Thu Nov 2 16:42:50 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 02 Nov 2006 16:42:54 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kA30gjaG007494 for ; Thu, 2 Nov 2006 16:42:49 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA02613; Fri, 3 Nov 2006 11:41:50 +1100 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 kA30fl7Y23303094; Fri, 3 Nov 2006 11:41:48 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id kA30fgCF22779868; Fri, 3 Nov 2006 11:41:42 +1100 (AEDT) Date: Fri, 3 Nov 2006 11:41:42 +1100 From: David Chinner To: Christian Guggenberger Cc: xfs@oss.sgi.com Subject: Re: mount failed after xfs_growfs beyond 16 TB Message-ID: <20061103004142.GI8394166@melbourne.sgi.com> References: <20061102172608.GA27769@pc51072.physik.uni-regensburg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061102172608.GA27769@pc51072.physik.uni-regensburg.de> User-Agent: Mutt/1.4.2.1i X-archive-position: 9529 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 1586 Lines: 52 On Thu, Nov 02, 2006 at 06:26:08PM +0100, Christian Guggenberger wrote: > Hi, > > a colleague recently tried to grow a 16 TB filesystem (x86, 32bit) on > top of lvm2 to 17TB. (I am not even sure if that's supposed work with > linux-2.6, 32bit) Not supported - any metadata access past 16TB will wrap the 32 bit page cache index for the metadata address space and you'll corrupt the filesystem. > used kernel seems to be debian sarge's 2.6.8 > > xfs_growfs seemed to succeed (AFAIK..) > > however, the fs shut down: > > XFS internal error > XFS_WANT_CORRUPTED_GOTO at line 1583 of file fs/xfs/xfs_alloc.c. Caller > 0xf89978a8 > [__crc_pm_idle+550816/2056674] xfs_free_ag_extent+0x454/0x78a [xfs] > [__crc_pm_idle+555561/2056674] xfs_free_extent+0xea/0x10f [xfs] > [__crc_pm_idle+555561/2056674] xfs_free_extent+0xea/0x10f [xfs] > [__crc_pm_idle+553757/2056674] xfs_alloc_read_agf+0xbe/0x1e4 [xfs] > [__crc_pm_idle+764480/2056674] xfs_growfs_data_private+0xd80/0xec0 [xfs] No, growfs failed trying to extend the data partition and shut down the filesystem. > mounting fails with: > > XFS: SB sanity check 2 failed ..... > and finally, xfs_repair stops at > > bad primary superblock: inconsistent file geometrie information Probably because growfs failed part way through and left inconsistent state behind. > found candidate secondary superblock... > superblock read failed, offset 10093861404672, size 2048, ag 0, rval 29 Does LVM2 even support volumes larger than 16TB on 32 bit machines? Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Thu Nov 2 16:58:22 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 02 Nov 2006 16:58:26 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kA30wIaG009337 for ; Thu, 2 Nov 2006 16:58:20 -0800 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA03056; Fri, 3 Nov 2006 11:57:26 +1100 Date: Fri, 03 Nov 2006 10:58:31 +1000 From: Timothy Shimmin To: peyytmek@gmx.de cc: xfs@oss.sgi.com Subject: Re: Xfs-mailinglist question (xfs mounting problem, hdb1 just freezes) Message-ID: <3B2B6490C980DD2C8B4C9645@timothy-shimmins-power-mac-g5.local> In-Reply-To: <200611012255.46008.peyytmek@gmx.de> References: <200611012255.46008.peyytmek@gmx.de> X-Mailer: Mulberry/4.0.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id kA30wMaG009349 X-archive-position: 9530 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Content-Length: 4619 Lines: 145 Hi there, Sorry about not getting back to you. The inode details you sent me look reasonable to me (AFAICS). However, the inode that we are processing which has problems is probably coming from the log. Basically, during log replay we reinstate metadata such as inodes, inode buffers, and later process an unlinked-list which this inode appears to be on. It's during the truncating (as part of inactivating the inode) that we have problems when looking at its extents. You should be able to see this inode in the log if you use: # xfs_logprint -ti device (or possibly I guess # xfs_logrpint -tibo device - if the inode is in a buffer of inodes) I'd be curious to see this. My thoughts for a plan of action were either: (1) forget the log and do an "xfs_repair -L" to zero it out and repair or (2) somehow try to do a mount which avoids the unlinked list processing (an older kernel (pre May 26) would do this because of a bug in recovery); then unmount, then do a normal "xfs_repair" or (3) we try to stop this particular inode from being processed in the unlinked-list inode processing during mount; unmount; repair and then mount again The simplest is to do option (1). However, it means that any other outstanding metadata changes would be lost. Option (2) might be a goer but you need such a kernel and in that case it won't do any unlinked processing for a group of such inodes (one's hashed to that bucket in the AGI's). I'm unsure on how to stop this unlinked processing otherwise. Option (3) I'm unsure as how to do. Also, there could be more inodes in the same boat which could cause recovery to crash. May be others have suggestions. Regards, Tim. --On 1 November 2006 10:55:43 PM +0000 peyytmek@gmx.de wrote: > Hello, > Thanks for your last answer. Since you didn't answer my email for 2 weeks i > thought you might have deleted it accidently > > Here's the email conversation: > >> > Hello. >> > Thanks for your answer. >> > >> > That's what i have: dmesg print with kernel-2.6.16-gentoo-r3 and an print >> > of xfs_bg. >> > >> >> You could print out the offending inode with xfs_db to show us >> >> what it looks like: $xfs_db -r /dev/hdb1 -c "inode 950759" -c "print". >> > >> > I don't know what you mean with it but i added it anyway. (done with >> > kernel-2.6.18-gentoo if it matters) >> > >> > xfs_db: >> > >> > CLX ~ # xfs_db -r /dev/hdb1 -c "inode 950759" -c "print" >> > core.magic = 0x494e >> > core.mode = 0100644 >> > core.version = 1 >> > core.format = 3 (btree) >> > core.nlinkv1 = 0 >> > core.uid = 1000 >> > core.gid = 100 >> > core.flushiter = 0 >> > core.atime.sec = Sun Aug 27 14:56:52 2006 >> > core.atime.nsec = 657389250 >> > core.mtime.sec = Sun Aug 27 16:29:40 2006 >> > core.mtime.nsec = 080196250 >> > core.ctime.sec = Thu Oct  5 01:17:40 2006 >> > core.ctime.nsec = 976565958 >> > core.size = 32071862 >> > core.nblocks = 7833 >> > core.extsize = 0 >> > core.nextents = 28 >> > core.naextents = 0 >> > core.forkoff = 0 >> > core.aformat = 2 (extents) >> > core.dmevmask = 0 >> > core.dmstate = 0 >> > core.newrtbm = 0 >> > core.prealloc = 0 >> > core.realtime = 0 >> > core.immutable = 0 >> > core.append = 0 >> > core.sync = 0 >> > core.noatime = 0 >> > core.nodump = 0 >> > core.rtinherit = 0 >> > core.projinherit = 0 >> > core.nosymlinks = 0 >> > core.extsz = 0 >> > core.extszinherit = 0 >> > core.gen = 0 >> > next_unlinked = null >> > u.bmbt.level = 1 >> > u.bmbt.numrecs = 1 >> > u.bmbt.keys[1] = [startoff] 1:[0] >> > u.bmbt.ptrs[1] = 1:185933 >> >> And now: >> >> xfs_db -r /dev/hadb1 -c "fsb 185933" -c "type bmapbtd" -c "p" >> >> to look at the 28 extent records. >> >> --Tim > > Here's the content of my last Email > > > Hello, thanks again for your fast answer > Sorry for the double post last time. > here it comes > > > CLX ~ # xfs_db -r /dev/hdb1 -c "fsb 185933" -c "type bmapbtd" -c "p" > magic = 0x424d4150 > level = 0 > numrecs = 27 > leftsib = null > rightsib = null > recs[1-27] = [startoff,startblock,blockcount,extentflag] 1:[0,185637,16,0] 2: > [16,185537,8,0] 3:[24,185718,8,0] 4:[32,185706,8,0] 5:[40,185836,8,0] 6: > [48,185848,16,0] 7:[64,185865,16,0] 8:[80,185882,8,0] 9:[96,185899,16,0] 10: > [112,185916,16,0] 11:[340,185934,2,0] 12:[342,4768704,1320,0] 13: > [1662,4770389,239,0] 14:[1901,4770919,264,0] 15:[2165,4771391,165,0] 16: > [2330,4771860,227,0] 17:[2557,4861204,351,0] 18:[2908,4861800,257,0] 19: > [3165,4862282,349,0] 20:[3514,4862934,230,0] 21:[3744,4863506,383,0] 22: > [4127,4864141,348,0] 23:[4475,4864871,228,0] 24:[4703,4865358,268,0] 25: > [4971,4865882,593,0] 26:[5564,4866818,339,0] 27:[5903,4867729,1928,0] From owner-xfs@oss.sgi.com Thu Nov 2 18:42:36 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 02 Nov 2006 18:42:41 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kA32gXaG021241 for ; Thu, 2 Nov 2006 18:42:34 -0800 Received: from [134.14.55.89] (soarer.melbourne.sgi.com [134.14.55.89]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA06154; Fri, 3 Nov 2006 13:41:41 +1100 Message-ID: <454AAC6B.7010406@sgi.com> Date: Fri, 03 Nov 2006 13:41:47 +1100 From: Vlad Apostolov User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: jgl@johngroves.net CC: linux-xfs@oss.sgi.com, John Groves , Dean Roehrich Subject: Re: XFS dmapi: dm_path_to_handle fails if the path is a directory References: <4547DA70.4040107@Groves.net> <4547EDFD.8020407@sgi.com> <454A94A6.6040907@johngroves.net> In-Reply-To: <454A94A6.6040907@johngroves.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9531 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: vapo@sgi.com Precedence: bulk X-list: xfs Content-Length: 2779 Lines: 66 John Groves wrote: > Thanks for your replies, Vlad, although I don't find anything so far > that helps with my problem (my paths are not long, and my calls to > dm_path_to_handle have been running in production environments for a > couple of years). As far as I can see, dm_path_to_handle does not > work on a directory (?), although it works perfectly on a file. I > will try to dig deeper into this over the next few days, but here is a > somewhat clearer explanation of the behavior I am seeing. > > I have updated to the latest kernel from SGI's CVS server, but the > problem is still there. I am tracing through kernel code, and will be > happy to pull together some test code that demonstrates the problem, > or to post a patch if I figure it out, but this will take a few days. > > The sequence in which I find this problem is: > > 1. Receive a pre-rename event > 2. Use the first handle parameter to resolve the pre-rename parent > directory path (not via dm_handle_to_path -- I had to roll my own > mechanisms for turning handles into paths). > 3. Concatenate the first name parameter to the first parent > directory path, to get the relative path from mount point to actual > file being renamed. > 4. Call dm_path_to_handle on that path, hoping to get the handle of > the file-being-renamed. > > If the renamed-thing is a file, this works. If it's a directory, > dm_path_to_handle fails. > > With my dmapi event handler installed and running, I can reproduce it > by doing the following in the root directory of the filesystem: > > mkdir -p x/y/z > mv x/y x/w > > In the pre-rename event, prior to responding to the event, my handler > correctly determines that x/y is being renamed to x/w, but > dm_path_to_handle does not return the handle of x/y. My post-rename > event handler also correctly resolves the paths, but dm_path_to_handle > does not return the handle of x/w. > > If x/y is a file (rather than a directory) it all works properly. > > Let me know if you can think of anything specific I should look at, or > of a different way of getting the handle of the renamed thingy. Hi John, I did try this on my dmapi filesystem: emu:/mnt/scratch1/dmapi_test # mkdir -p x/y/z emu:/mnt/scratch1/dmapi_test # /home/vapo/isms/xfs-cmds/xfstests/dmapi/src/suite1/cmd/path_to_handle x/y 5d1111a90e4800000e00000003000000d903400000000000 emu:/mnt/scratch1/dmapi_test # mv x/y x/w emu:/mnt/scratch1/dmapi_test # /home/vapo/isms/xfs-cmds/xfstests/dmapi/src/suite1/cmd/path_to_handle x/w 5d1111a90e4800000e00000003000000d903400000000000 emu:/mnt/scratch1/dmapi_test # I also tried path_to_handle with relative path to a directory it worked fine too. When you say dm_path_to_handle fails, what is the error returned? Regards, Vlad From owner-xfs@oss.sgi.com Thu Nov 2 19:00:34 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 02 Nov 2006 19:00:38 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kA330SaG023868 for ; Thu, 2 Nov 2006 19:00:33 -0800 Received: from [134.14.55.89] (soarer.melbourne.sgi.com [134.14.55.89]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA06623; Fri, 3 Nov 2006 13:59:38 +1100 Message-ID: <454AB0A0.7050309@sgi.com> Date: Fri, 03 Nov 2006 13:59:44 +1100 From: Vlad Apostolov User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: John Groves CC: jgl@johngroves.net, linux-xfs@oss.sgi.com, Dean Roehrich Subject: Re: XFS dmapi: dm_path_to_handle fails if the path is a directory References: <4547DA70.4040107@Groves.net> <4547EDFD.8020407@sgi.com> <454A94A6.6040907@johngroves.net> <454AAC6B.7010406@sgi.com> <454AAF31.8050104@Groves.net> In-Reply-To: <454AAF31.8050104@Groves.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9532 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: vapo@sgi.com Precedence: bulk X-list: xfs Content-Length: 1477 Lines: 52 John Groves wrote: > Vlad Apostolov wrote: > >> Hi John, >> >> I did try this on my dmapi filesystem: >> >> emu:/mnt/scratch1/dmapi_test # mkdir -p x/y/z >> emu:/mnt/scratch1/dmapi_test # >> /home/vapo/isms/xfs-cmds/xfstests/dmapi/src/suite1/cmd/path_to_handle >> x/y >> 5d1111a90e4800000e00000003000000d903400000000000 >> emu:/mnt/scratch1/dmapi_test # mv x/y x/w >> emu:/mnt/scratch1/dmapi_test # >> /home/vapo/isms/xfs-cmds/xfstests/dmapi/src/suite1/cmd/path_to_handle >> x/w >> 5d1111a90e4800000e00000003000000d903400000000000 >> emu:/mnt/scratch1/dmapi_test # >> >> I also tried path_to_handle with relative path to a directory it >> worked fine too. When you say >> dm_path_to_handle fails, what is the error returned? >> >> Regards, >> Vlad >> > > Vlad, > > This was my bad -- I need to go back to programming school ;-). > > The function in question was dealing in mount-point-relative paths, > not full paths, and I didn't notice the distinction. Passing a full > path to dm_path_to_handle fixed it. As for thinking it behaved > differently for a directory than for a file -- I've been smoking a > batch of bad crack ;-). Calling dm_path_to_handle also failed with > relative paths to files -- I just didn't notice because it wasn't > fatal on that code path. > > Thanks for responding and looking into it, though. > > Regards, > John > No problems John, Just a note that dm_path_to_handle works fine with relative paths on my machine. Regards, Vlad From owner-xfs@oss.sgi.com Thu Nov 2 19:01:50 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 02 Nov 2006 19:01:54 -0800 (PST) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kA331maG024120 for ; Thu, 2 Nov 2006 19:01:50 -0800 X-ASG-Debug-ID: 1162522861-30622-124-0 X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from n034.sc1.cp.net (smtpout1453.sc1.he.tucows.com [64.97.157.153]) by cuda.sgi.com (Spam Firewall) with ESMTP id 4C77FD1B2073 for ; Thu, 2 Nov 2006 19:01:01 -0800 (PST) Received: from [192.168.2.120] (70.112.81.243) by n034.sc1.cp.net (7.2.069.1) (authenticated as john@groves.net) id 454A86AE00007334; Fri, 3 Nov 2006 02:53:33 +0000 Message-ID: <454AAF31.8050104@Groves.net> Date: Thu, 02 Nov 2006 20:53:37 -0600 From: John Groves User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vlad Apostolov CC: jgl@johngroves.net, linux-xfs@oss.sgi.com, Dean Roehrich X-ASG-Orig-Subj: Re: XFS dmapi: dm_path_to_handle fails if the path is a directory Subject: Re: XFS dmapi: dm_path_to_handle fails if the path is a directory References: <4547DA70.4040107@Groves.net> <4547EDFD.8020407@sgi.com> <454A94A6.6040907@johngroves.net> <454AAC6B.7010406@sgi.com> In-Reply-To: <454AAC6B.7010406@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=3.5 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.02, rules version 3.0.24892 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-archive-position: 9533 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: John@Groves.net Precedence: bulk X-list: xfs Content-Length: 1279 Lines: 41 Vlad Apostolov wrote: > Hi John, > > I did try this on my dmapi filesystem: > > emu:/mnt/scratch1/dmapi_test # mkdir -p x/y/z > emu:/mnt/scratch1/dmapi_test # > /home/vapo/isms/xfs-cmds/xfstests/dmapi/src/suite1/cmd/path_to_handle x/y > 5d1111a90e4800000e00000003000000d903400000000000 > emu:/mnt/scratch1/dmapi_test # mv x/y x/w > emu:/mnt/scratch1/dmapi_test # > /home/vapo/isms/xfs-cmds/xfstests/dmapi/src/suite1/cmd/path_to_handle x/w > 5d1111a90e4800000e00000003000000d903400000000000 > emu:/mnt/scratch1/dmapi_test # > > I also tried path_to_handle with relative path to a directory it > worked fine too. When you say > dm_path_to_handle fails, what is the error returned? > > Regards, > Vlad > Vlad, This was my bad -- I need to go back to programming school ;-). The function in question was dealing in mount-point-relative paths, not full paths, and I didn't notice the distinction. Passing a full path to dm_path_to_handle fixed it. As for thinking it behaved differently for a directory than for a file -- I've been smoking a batch of bad crack ;-). Calling dm_path_to_handle also failed with relative paths to files -- I just didn't notice because it wasn't fatal on that code path. Thanks for responding and looking into it, though. Regards, John From owner-xfs@oss.sgi.com Thu Nov 2 20:41:05 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 02 Nov 2006 20:41:11 -0800 (PST) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kA34f3aG007783 for ; Thu, 2 Nov 2006 20:41:05 -0800 X-ASG-Debug-ID: 1162525317-22063-155-0 X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ruth.realtime.net (mercury.realtime.net [205.238.132.86]) by cuda.sgi.com (Spam Firewall) with ESMTP id EA791D1B7DD9 for ; Thu, 2 Nov 2006 19:41:57 -0800 (PST) Received: from [192.168.2.120] (cpe-70-112-81-243.austin.res.rr.com [70.112.81.243]) by realtime.net (Realtime Communications Advanced E-Mail Services V9.2) with ESMTP id 24509592-1817707 for multiple; Thu, 02 Nov 2006 19:00:20 -0600 Message-ID: <454A94A6.6040907@johngroves.net> Date: Thu, 02 Nov 2006 19:00:22 -0600 From: John Groves Reply-To: jgl@johngroves.net User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com CC: Vlad Apostolov , John Groves , Dean Roehrich X-ASG-Orig-Subj: Re: XFS dmapi: dm_path_to_handle fails if the path is a directory Subject: Re: XFS dmapi: dm_path_to_handle fails if the path is a directory References: <4547DA70.4040107@Groves.net> <4547EDFD.8020407@sgi.com> In-Reply-To: <4547EDFD.8020407@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: jg@bga.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=3.5 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.02, rules version 3.0.24892 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-archive-position: 9535 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jgl@johngroves.net Precedence: bulk X-list: xfs Content-Length: 3219 Lines: 83 Thanks for your replies, Vlad, although I don't find anything so far that helps with my problem (my paths are not long, and my calls to dm_path_to_handle have been running in production environments for a couple of years). As far as I can see, dm_path_to_handle does not work on a directory (?), although it works perfectly on a file. I will try to dig deeper into this over the next few days, but here is a somewhat clearer explanation of the behavior I am seeing. I have updated to the latest kernel from SGI's CVS server, but the problem is still there. I am tracing through kernel code, and will be happy to pull together some test code that demonstrates the problem, or to post a patch if I figure it out, but this will take a few days. The sequence in which I find this problem is: 1. Receive a pre-rename event 2. Use the first handle parameter to resolve the pre-rename parent directory path (not via dm_handle_to_path -- I had to roll my own mechanisms for turning handles into paths). 3. Concatenate the first name parameter to the first parent directory path, to get the relative path from mount point to actual file being renamed. 4. Call dm_path_to_handle on that path, hoping to get the handle of the file-being-renamed. If the renamed-thing is a file, this works. If it's a directory, dm_path_to_handle fails. With my dmapi event handler installed and running, I can reproduce it by doing the following in the root directory of the filesystem: mkdir -p x/y/z mv x/y x/w In the pre-rename event, prior to responding to the event, my handler correctly determines that x/y is being renamed to x/w, but dm_path_to_handle does not return the handle of x/y. My post-rename event handler also correctly resolves the paths, but dm_path_to_handle does not return the handle of x/w. If x/y is a file (rather than a directory) it all works properly. Let me know if you can think of anything specific I should look at, or of a different way of getting the handle of the renamed thingy. Thanks, John Groves Vlad Apostolov wrote: > John Groves wrote: > >> I'm running up against a difficult situation because dm_path_to_handle >> does not return a handle, if the path is to a directory. Is this a >> known issue, or perhaps fixed in a recent version? Or is there >> another way get the handle of a directory by path? When any file type >> is renamed, I (for various reasons) *must* know not just the old & new >> parent handles, but also the handle of the renamed thingy. If the >> thingy is a directory, I'm stuck at the moment. >> >> My test system has dmapi 2.2.1-5, which I don't think is current, but >> I can't seem to get access to the oss.sgi.com server to check. >> >> Any advice or info appreciated. I'm willing to try and submit a >> patch, but I'd appreciate first knowing whether there was a specific >> reason or problem that led to the current behavior. >> >> Thanks, >> John Groves >> > Hi John, > > If your path is longer than 2000 characters dm_path_to_handle used to fail. > This bug was fixed in August 2006. Please update your tree from here: > > http://oss.sgi.com/projects/xfs/download.html > > Regards, > Vlad > > > > From owner-xfs@oss.sgi.com Fri Nov 3 01:32:59 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 03 Nov 2006 01:33:03 -0800 (PST) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kA39WraG017853 for ; Fri, 3 Nov 2006 01:32:59 -0800 X-ASG-Debug-ID: 1162546326-5754-577-0 X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from rrzmta2.rz.uni-regensburg.de (rrzmta2.rz.uni-regensburg.de [132.199.1.17]) by cuda.sgi.com (Spam Firewall) with ESMTP id 15071D1B8CD7 for ; Fri, 3 Nov 2006 01:32:06 -0800 (PST) Received: from rrzmta2.rz.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 960C16CED8; Fri, 3 Nov 2006 10:32:07 +0100 (CET) Received: from pc51072.physik.uni-regensburg.de (pc51072.physik.uni-regensburg.de [132.199.98.129]) by rrzmta2.rz.uni-regensburg.de (Postfix) with ESMTP id 44D196CEAD; Fri, 3 Nov 2006 10:32:07 +0100 (CET) Received: by pc51072.physik.uni-regensburg.de (Postfix, from userid 28561) id EE04F507058; Fri, 3 Nov 2006 10:32:03 +0100 (CET) Date: Fri, 3 Nov 2006 10:32:03 +0100 From: Christian Guggenberger To: Eric Sandeen , dgc@sgi.com Cc: christian.guggenberger@physik.uni-regensburg.de, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: mount failed after xfs_growfs beyond 16 TB Subject: Re: mount failed after xfs_growfs beyond 16 TB Message-ID: <20061103093203.GA18010@pc51072.physik.uni-regensburg.de> Reply-To: christian.guggenberger@physik.uni-regensburg.de References: <20061102172608.GA27769@pc51072.physik.uni-regensburg.de> <454A3B28.7010405@sandeen.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <454A3B28.7010405@sandeen.net> User-Agent: Mutt/1.5.9i X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=3.5 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.02, rules version 3.0.24916 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-archive-position: 9536 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: christian.guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: xfs Content-Length: 2157 Lines: 107 Eric, Dave, > > xfs_db> sb 0 > xfs_db> p > > let's see what you've got. > xfs_db: read failed: Invalid argument xfs_db: data size check failed xfs_db> sb 0 xfs_db> p magicnum = 0x58465342 blocksize = 4096 dblocks = 18446744070056148512 rblocks = 0 rextents = 0 uuid = 27d35a50-724e-440b-ae1a-79f934f7915a logstart = 2147483652 rootino = 128 rbmino = 129 rsumino = 130 rextsize = 16 agblocks = 84976608 agcount = 570 rbmblocks = 0 logblocks = 32768 versionnum = 0x30c4 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 = 27 rextslog = 0 inprogress = 0 imax_pct = 25 icount = 1298880 ifree = 376826 fdblocks = 18446744067363131928 frextents = 0 uquotino = 131 gquotino = null qflags = 0x7 flags = 0 shared_vn = 0 inoalignmt = 2 unit = 0 width = 0 dirblklog = 0 logsectlog = 0 logsectsize = 0 logsunit = 0 features2 = 0 xfs_db> > Also how big does /proc/partitions think your new device is? > it thinks it's 26983133184 blocks, which seems to be correct: --- Logical volume --- LV Name /dev/data/project VG Name data LV UUID 4RIXaW-QxWj-KOr5-CysS-TmLF-Jebu-lPyPOU LV Write Access read/write LV Status available # open 1 LV Size 25.13 TB Current LE 6587679 Segments 4 Allocation inherit Read ahead sectors 0 Block device 254:1 note, the fs was first grown with (originally mounted on /data/projects) xfs_growfs -D 4294966000 /data/projects which succeeded. a further xfs_growfs -D 4300000000 /data/projects shut the fs down. > > found candidate secondary superblock... > > superblock read failed, offset 10093861404672, size 2048, ag 0, rval 29 > > hmm that offset is about 9.4 terabytes. > > any kernel messages when this happens? > > rval 29 is ESPIPE / illegal seek. not that I know of, unfortunately. As Dave already stated that > 16TB is not supported on 32bits - is there any way to step back ? cheers. - Christian From owner-xfs@oss.sgi.com Fri Nov 3 04:35:26 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 03 Nov 2006 04:35:38 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kA3CZJaG012067 for ; Fri, 3 Nov 2006 04:35:24 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id XAA19682; Fri, 3 Nov 2006 23:34:25 +1100 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 kA3CYM7Y23496703; Fri, 3 Nov 2006 23:34:23 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id kA3CYIOe23474843; Fri, 3 Nov 2006 23:34:18 +1100 (AEDT) Date: Fri, 3 Nov 2006 23:34:18 +1100 From: David Chinner To: Christian Guggenberger Cc: Eric Sandeen , dgc@sgi.com, xfs@oss.sgi.com Subject: Re: mount failed after xfs_growfs beyond 16 TB Message-ID: <20061103123418.GP8394166@melbourne.sgi.com> References: <20061102172608.GA27769@pc51072.physik.uni-regensburg.de> <454A3B28.7010405@sandeen.net> <20061103093203.GA18010@pc51072.physik.uni-regensburg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061103093203.GA18010@pc51072.physik.uni-regensburg.de> User-Agent: Mutt/1.4.2.1i X-archive-position: 9537 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 3181 Lines: 130 On Fri, Nov 03, 2006 at 10:32:03AM +0100, Christian Guggenberger wrote: > Eric, Dave, > > > > > xfs_db> sb 0 > > xfs_db> p > > > > let's see what you've got. > > > > xfs_db: read failed: Invalid argument > xfs_db: data size check failed > xfs_db> sb 0 > xfs_db> p > magicnum = 0x58465342 > blocksize = 4096 > dblocks = 18446744070056148512 That looks like an overflow to me ;) > fdblocks = 18446744067363131928 Free space gone kaboom too... > frextents = 0 > uquotino = 131 > gquotino = null > qflags = 0x7 > flags = 0 > shared_vn = 0 > inoalignmt = 2 > unit = 0 > width = 0 > dirblklog = 0 > logsectlog = 0 > logsectsize = 0 > logsunit = 0 > features2 = 0 > xfs_db> > > > Also how big does /proc/partitions think your new device is? > > > it thinks it's 26983133184 blocks, which seems to be correct: > > --- Logical volume --- > LV Name /dev/data/project > VG Name data > LV UUID 4RIXaW-QxWj-KOr5-CysS-TmLF-Jebu-lPyPOU > LV Write Access read/write > LV Status available > # open 1 > LV Size 25.13 TB > Current LE 6587679 > Segments 4 > Allocation inherit > Read ahead sectors 0 > Block device 254:1 > > note, the fs was first grown with (originally mounted on /data/projects) > > xfs_growfs -D 4294966000 /data/projects > which succeeded. Which is just less than 16TB: 0x1ffeffaf0000 > a further > > xfs_growfs -D 4300000000 /data/projects Which is just more than 16TB: 0x2008ccb00000 > shut the fs down. Probably corrupted metadata in the first couple of AGs... > > > found candidate secondary superblock... > > > superblock read failed, offset 10093861404672, size 2048, ag 0, rval 29 > > > > hmm that offset is about 9.4 terabytes. With a size of 25.13TiB in the LVM, 9.4TB is ~(25.13 - 16)TiB That's a 32 bit overflow as well... > As Dave already stated that > 16TB is not supported on 32bits - is there > any way to step back ? xfs_db mojo.... ;) Note - no guarantee this will work - practise on an expendable sparse loopback filessytem image by making a filesystem of slightly less than 16TB then growing it to corrupt it the same way and then fixing it up successfully. Once it's corrupted, unmount and run xfs_db in expert mode. The superblock: blocksize = 4096 dblocks = 18446744070056148512 ... agblocks = 84976608 agcount = 570 An AG is ~43.5GB, so 570 AGs is 24.8TB. It's to big, and we will only shrink by whole AGs. Hence we have to correct agcount and dblocks. So, 404 AGs gives: dblocks = agblocks * agcount = 84976608 * 404 * 512 bytes = 0xFFC853B0000 bytes, which is under 16TiB = 4291318704 blocks Now you need to zero fdblocks, and now you should be able to run xfs_repair to fix it up. Don't be surprised if repair runs out of memory - you'll have to hope Barry gets finished with the memory reduction work he's doing soon or get a 64 bit machine to fix that problem. A 64bit machine wouldn't have the 16TB limit, either ;) Good luck.... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Fri Nov 3 06:55:34 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 03 Nov 2006 06:55:41 -0800 (PST) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kA3EtWaG028004 for ; Fri, 3 Nov 2006 06:55:34 -0800 X-ASG-Debug-ID: 1162565684-4894-99-0 X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com (Spam Firewall) with ESMTP id D9ECCD1B33AE for ; Fri, 3 Nov 2006 06:54:44 -0800 (PST) Received: from [10.0.0.4] (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id C20F818022E2F; Fri, 3 Nov 2006 08:54:43 -0600 (CST) Message-ID: <454B5833.9030008@sandeen.net> Date: Fri, 03 Nov 2006 08:54:43 -0600 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: David Chinner CC: Christian Guggenberger , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: mount failed after xfs_growfs beyond 16 TB Subject: Re: mount failed after xfs_growfs beyond 16 TB References: <20061102172608.GA27769@pc51072.physik.uni-regensburg.de> <20061103004142.GI8394166@melbourne.sgi.com> In-Reply-To: <20061103004142.GI8394166@melbourne.sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=3.5 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.02, rules version 3.0.24940 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-archive-position: 9538 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 1319 Lines: 36 David Chinner wrote: > On Thu, Nov 02, 2006 at 06:26:08PM +0100, Christian Guggenberger wrote: >> Hi, >> >> a colleague recently tried to grow a 16 TB filesystem (x86, 32bit) on >> top of lvm2 to 17TB. (I am not even sure if that's supposed work with >> linux-2.6, 32bit) > > Not supported - any metadata access past 16TB will wrap the 32 bit page cache > index for the metadata address space and you'll corrupt the filesystem. Ohhhh right. I've been in x86_64 land for too long, sorry for the earlier false assertion.... :( xfs guys, if it's not there already (and I don't see it from a quick look..) growfs -really- should refuse (in the kernel) to grow a filesystem past 16T on a 32-bit machine, just as we refuse to mount one. something like this in xfs_growfs_data_private: #if XFS_BIG_BLKNOS /* Limited by ULONG_MAX of page cache index */ if (unlikely( (nb >> (PAGE_SHIFT - sbp->sb_blocklog)) > ULONG_MAX) { #else /* Limited by UINT_MAX of sectors */ if (unlikely( (nb << (sbp->sb_blocklog - BBSHIFT)) > UINT_MAX) { #endif cmn_err(CE_WARN, "new filesystem size too large for this system."); return XFS_ERROR(E2BIG); } and something similar in xfs_growfs_rt ? -Eric From owner-xfs@oss.sgi.com Fri Nov 3 06:58:48 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 03 Nov 2006 06:58:55 -0800 (PST) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kA3EwiaG028538 for ; Fri, 3 Nov 2006 06:58:48 -0800 X-ASG-Debug-ID: 1162565878-10765-48-0 X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ruth.realtime.net (mercury.realtime.net [205.238.132.86]) by cuda.sgi.com (Spam Firewall) with ESMTP id BE293D1AFBEA for ; Fri, 3 Nov 2006 06:57:58 -0800 (PST) Received: from [192.168.2.120] (cpe-70-112-81-243.austin.res.rr.com [70.112.81.243]) by realtime.net (Realtime Communications Advanced E-Mail Services V9.2) with ESMTP id 24628936-1817707 for multiple; Fri, 03 Nov 2006 08:57:36 -0600 Message-ID: <454B58E4.6000802@johngroves.net> Date: Fri, 03 Nov 2006 08:57:40 -0600 From: John Groves Reply-To: jgl@johngroves.net User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vlad Apostolov CC: John Groves , linux-xfs@oss.sgi.com, Dean Roehrich X-ASG-Orig-Subj: Re: XFS dmapi: dm_path_to_handle fails if the path is a directory Subject: Re: XFS dmapi: dm_path_to_handle fails if the path is a directory References: <4547DA70.4040107@Groves.net> <4547EDFD.8020407@sgi.com> <454A94A6.6040907@johngroves.net> <454AAC6B.7010406@sgi.com> <454AAF31.8050104@Groves.net> <454AB0A0.7050309@sgi.com> In-Reply-To: <454AB0A0.7050309@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: jg@bga.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=3.5 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.02, rules version 3.0.24940 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-archive-position: 9539 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jgl@johngroves.net Precedence: bulk X-list: xfs Content-Length: 452 Lines: 18 Vlad Apostolov wrote: > Just a note that dm_path_to_handle works fine with relative paths on my > machine. In your case, could it be applying the "current working directory" from the process context to resolve a full path? Mine is a daemon, and the relative paths are not valid relative to the "cwd" in which the daemon was started. ...just a thought. Otherwise, for the moment I may have to just accept it as weird... Thanks again, John From owner-xfs@oss.sgi.com Fri Nov 3 07:45:40 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 03 Nov 2006 07:45:46 -0800 (PST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kA3FjaaG001958 for ; Fri, 3 Nov 2006 07:45:40 -0800 X-ASG-Debug-ID: 1162568690-11424-544-0 X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from rrzmta2.rz.uni-regensburg.de (rrzmta2.rz.uni-regensburg.de [132.199.1.17]) by cuda.sgi.com (Spam Firewall) with ESMTP id 835F34ED2C1 for ; Fri, 3 Nov 2006 07:44:50 -0800 (PST) Received: from rrzmta2.rz.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id EC4A56CEB1; Fri, 3 Nov 2006 16:44:54 +0100 (CET) Received: from pc51072.physik.uni-regensburg.de (pc51072.physik.uni-regensburg.de [132.199.98.129]) by rrzmta2.rz.uni-regensburg.de (Postfix) with ESMTP id 9868069AEC; Fri, 3 Nov 2006 16:44:54 +0100 (CET) Received: by pc51072.physik.uni-regensburg.de (Postfix, from userid 28561) id 4CDF4507058; Fri, 3 Nov 2006 16:44:48 +0100 (CET) Date: Fri, 3 Nov 2006 16:44:48 +0100 From: Christian Guggenberger To: David Chinner Cc: Christian Guggenberger , Eric Sandeen , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: mount failed after xfs_growfs beyond 16 TB Subject: Re: mount failed after xfs_growfs beyond 16 TB Message-ID: <20061103154448.GA26647@pc51072.physik.uni-regensburg.de> Reply-To: christian.guggenberger@physik.uni-regensburg.de References: <20061102172608.GA27769@pc51072.physik.uni-regensburg.de> <454A3B28.7010405@sandeen.net> <20061103093203.GA18010@pc51072.physik.uni-regensburg.de> <20061103123418.GP8394166@melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061103123418.GP8394166@melbourne.sgi.com> User-Agent: Mutt/1.5.9i X-Barracuda-Spam-Score: 0.50 X-Barracuda-Spam-Status: No, SCORE=0.50 using per-user scores of TAG_LEVEL=3.5 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_RULE7568M X-Barracuda-Spam-Report: Code version 3.02, rules version 3.0.24942 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.50 BSF_RULE7568M BODY: Custom Rule 7568M X-archive-position: 9540 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: christian.guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: xfs Content-Length: 1753 Lines: 84 > > xfs_db mojo.... ;) > > Note - no guarantee this will work - practise on an expendable > sparse loopback filessytem image by making a filesystem of slightly less > than 16TB then growing it to corrupt it the same way and then fixing it up > successfully. > > Once it's corrupted, unmount and run xfs_db in expert mode. > The superblock: > > blocksize = 4096 > dblocks = 18446744070056148512 > ... > agblocks = 84976608 > agcount = 570 > > An AG is ~43.5GB, so 570 AGs is 24.8TB. It's to big, and > we will only shrink by whole AGs. Hence we have to correct > agcount and dblocks. isn't the AG size 'agblocks * blocksize' == ~324 GB here ? got further input on a secondray superblock form the colleague: looks more reasonable, I'd say. Is there a way to manually recover sb0 from sb1 ? (btw, I still hope they get access to an 64bit system with recent xfsprogs and kernel, soon) xfs_db: read failed: Invalid argument xfs_db: data size check failed xfs_db> sb 1 xfs_db> p magicnum = 0x58465342 blocksize = 4096 dblocks = 4294966000 rblocks = 0 rextents = 0 uuid = 27d35a50-724e-440b-ae1a-79f934f7915a logstart = 2147483652 rootino = 128 rbmino = 129 rsumino = 130 rextsize = 16 agblocks = 84976608 agcount = 51 rbmblocks = 0 logblocks = 32768 versionnum = 0x30c4 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 = 27 rextslog = 0 inprogress = 0 imax_pct = 25 icount = 1298880 ifree = 376828 fdblocks = 1601952378 frextents = 0 uquotino = 131 gquotino = null qflags = 0x7 flags = 0 shared_vn = 0 inoalignmt = 2 unit = 0 width = 0 dirblklog = 0 logsectlog = 0 logsectsize = 0 logsunit = 0 features2 = 0 cheers. - Christian From owner-xfs@oss.sgi.com Fri Nov 3 07:55:39 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 03 Nov 2006 07:55:47 -0800 (PST) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kA3FtdaG003056 for ; Fri, 3 Nov 2006 07:55:39 -0800 X-ASG-Debug-ID: 1162569293-21532-120-0 X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com (Spam Firewall) with ESMTP id 486F4D1BD465 for ; Fri, 3 Nov 2006 07:54:53 -0800 (PST) Received: from [10.0.0.4] (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 3B4DA18BCD2B7; Fri, 3 Nov 2006 09:54:52 -0600 (CST) Message-ID: <454B664B.6030701@sandeen.net> Date: Fri, 03 Nov 2006 09:54:51 -0600 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: christian.guggenberger@physik.uni-regensburg.de CC: David Chinner , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: mount failed after xfs_growfs beyond 16 TB Subject: Re: mount failed after xfs_growfs beyond 16 TB References: <20061102172608.GA27769@pc51072.physik.uni-regensburg.de> <454A3B28.7010405@sandeen.net> <20061103093203.GA18010@pc51072.physik.uni-regensburg.de> <20061103123418.GP8394166@melbourne.sgi.com> <20061103154448.GA26647@pc51072.physik.uni-regensburg.de> In-Reply-To: <20061103154448.GA26647@pc51072.physik.uni-regensburg.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=3.5 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.02, rules version 3.0.24944 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-archive-position: 9541 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 933 Lines: 31 Christian Guggenberger wrote: >> xfs_db mojo.... ;) >> >> Note - no guarantee this will work - practise on an expendable >> sparse loopback filessytem image by making a filesystem of slightly less >> than 16TB then growing it to corrupt it the same way and then fixing it up >> successfully. >> >> Once it's corrupted, unmount and run xfs_db in expert mode. >> The superblock: >> >> blocksize = 4096 >> dblocks = 18446744070056148512 >> ... >> agblocks = 84976608 >> agcount = 570 >> >> An AG is ~43.5GB, so 570 AGs is 24.8TB. It's to big, and >> we will only shrink by whole AGs. Hence we have to correct >> agcount and dblocks. > > isn't the AG size 'agblocks * blocksize' == ~324 GB here ? > > got further input on a secondray superblock form the colleague: > looks more reasonable, I'd say. Is there a way to manually recover sb0 > from sb1 ? you can copy it over field-by-field.... not sure if there's an easier way. -Eric From owner-xfs@oss.sgi.com Fri Nov 3 16:18:15 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 03 Nov 2006 16:18:18 -0800 (PST) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kA40IDaG020038 for ; Fri, 3 Nov 2006 16:18:15 -0800 X-ASG-Debug-ID: 1162599447-4960-471-0 X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by cuda.sgi.com (Spam Firewall) with SMTP id 048A7D1B5B61 for ; Fri, 3 Nov 2006 16:17:27 -0800 (PST) Received: (qmail invoked by alias); 04 Nov 2006 00:17:25 -0000 Received: from port-212-202-77-183.dynamic.qsc.de (EHLO clx) [212.202.77.183] by mail.gmx.net (mp043) with SMTP; 04 Nov 2006 01:17:25 +0100 X-Authenticated: #20522298 From: peyytmek@gmx.de To: Timothy Shimmin X-ASG-Orig-Subj: Re: Xfs-mailinglist question (xfs mounting problem, hdb1 just freezes) Subject: Re: Xfs-mailinglist question (xfs mounting problem, hdb1 just freezes) Date: Sat, 4 Nov 2006 02:14:29 +0000 User-Agent: KMail/1.9.1 References: <200611012255.46008.peyytmek@gmx.de> <3B2B6490C980DD2C8B4C9645@timothy-shimmins-power-mac-g5.local> In-Reply-To: <3B2B6490C980DD2C8B4C9645@timothy-shimmins-power-mac-g5.local> Cc: xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Message-Id: <200611040214.29997.peyytmek@gmx.de> X-Y-GMX-Trusted: 0 X-Barracuda-Spam-Score: 0.55 X-Barracuda-Spam-Status: No, SCORE=0.55 using per-user scores of TAG_LEVEL=3.5 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=NO_REAL_NAME X-Barracuda-Spam-Report: Code version 3.02, rules version 3.0.24976 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.55 NO_REAL_NAME From: does not include a real name Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id kA40IFaG020042 X-archive-position: 9545 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: peyytmek@gmx.de Precedence: bulk X-list: xfs Content-Length: 5424 Lines: 160 On Friday 03 November 2006 00:58, you wrote: Hello again Thanks for your email First of all, everytime I do xfs_logprint /dev/hdb1, with -ti or -tibo or mounting the partition with a kernel pre May 26 (kernel-2.16.3-gentoo-r3) or even xfs_repair -L /dev/hdb1 it's always the same. my terminal just freezes There is also nothing in /var/log/messages Well, I'm going to try my hdd in another computer with a different ide-controller. maybe that's the problem althought i doubt it would really work that way out. Bye, D.H. > Hi there, > > Sorry about not getting back to you. > > The inode details you sent me look reasonable to me (AFAICS). > However, the inode that we are processing which has problems > is probably coming from the log. > Basically, during log replay we reinstate metadata such as inodes, > inode buffers, > and later process an unlinked-list which this inode appears to be on. > It's during the truncating (as part of inactivating the inode) that we have > problems when looking at its extents. > > You should be able to see this inode in the log if you use: > # xfs_logprint -ti device > (or possibly I guess > # xfs_logrpint -tibo device - if the inode is in a buffer of inodes) > I'd be curious to see this. > > My thoughts for a plan of action were either: > (1) forget the log and do an "xfs_repair -L" to zero it out and repair > or > (2) somehow try to do a mount which avoids the unlinked list processing > (an older kernel (pre May 26) would do this because of a bug in recovery); > then unmount, then do a normal "xfs_repair" > or > (3) we try to stop this particular inode from being processed in the > unlinked-list inode processing during mount; unmount; repair and then mount > again > > The simplest is to do option (1). However, it means that any other > outstanding metadata changes would be lost. > Option (2) might be a goer but you need such a kernel and in that case it > won't do any unlinked processing for a group of such inodes (one's hashed > to that bucket in the AGI's). I'm unsure on how to stop this unlinked > processing otherwise. > Option (3) I'm unsure as how to do. Also, there could be more inodes in > the same boat which could cause recovery to crash. > > May be others have suggestions. > > Regards, > Tim. > > --On 1 November 2006 10:55:43 PM +0000 peyytmek@gmx.de wrote: > > Hello, > > Thanks for your last answer. Since you didn't answer my email for 2 weeks > > i thought you might have deleted it accidently > > > > Here's the email conversation: > >> > Hello. > >> > Thanks for your answer. > >> > > >> > That's what i have: dmesg print with kernel-2.6.16-gentoo-r3 and an > >> > print of xfs_bg. > >> > > >> >> You could print out the offending inode with xfs_db to show us > >> >> what it looks like: $xfs_db -r /dev/hdb1 -c "inode 950759" -c > >> >> "print". > >> > > >> > I don't know what you mean with it but i added it anyway. (done with > >> > kernel-2.6.18-gentoo if it matters) > >> > > >> > xfs_db: > >> > > >> > CLX ~ # xfs_db -r /dev/hdb1 -c "inode 950759" -c "print" > >> > core.magic = 0x494e > >> > core.mode = 0100644 > >> > core.version = 1 > >> > core.format = 3 (btree) > >> > core.nlinkv1 = 0 > >> > core.uid = 1000 > >> > core.gid = 100 > >> > core.flushiter = 0 > >> > core.atime.sec = Sun Aug 27 14:56:52 2006 > >> > core.atime.nsec = 657389250 > >> > core.mtime.sec = Sun Aug 27 16:29:40 2006 > >> > core.mtime.nsec = 080196250 > >> > core.ctime.sec = Thu Oct  5 01:17:40 2006 > >> > core.ctime.nsec = 976565958 > >> > core.size = 32071862 > >> > core.nblocks = 7833 > >> > core.extsize = 0 > >> > core.nextents = 28 > >> > core.naextents = 0 > >> > core.forkoff = 0 > >> > core.aformat = 2 (extents) > >> > core.dmevmask = 0 > >> > core.dmstate = 0 > >> > core.newrtbm = 0 > >> > core.prealloc = 0 > >> > core.realtime = 0 > >> > core.immutable = 0 > >> > core.append = 0 > >> > core.sync = 0 > >> > core.noatime = 0 > >> > core.nodump = 0 > >> > core.rtinherit = 0 > >> > core.projinherit = 0 > >> > core.nosymlinks = 0 > >> > core.extsz = 0 > >> > core.extszinherit = 0 > >> > core.gen = 0 > >> > next_unlinked = null > >> > u.bmbt.level = 1 > >> > u.bmbt.numrecs = 1 > >> > u.bmbt.keys[1] = [startoff] 1:[0] > >> > u.bmbt.ptrs[1] = 1:185933 > >> > >> And now: > >> > >> xfs_db -r /dev/hadb1 -c "fsb 185933" -c "type bmapbtd" -c "p" > >> > >> to look at the 28 extent records. > >> > >> --Tim > > > > Here's the content of my last Email > > > > > > Hello, thanks again for your fast answer > > Sorry for the double post last time. > > here it comes > > > > > > CLX ~ # xfs_db -r /dev/hdb1 -c "fsb 185933" -c "type bmapbtd" -c "p" > > magic = 0x424d4150 > > level = 0 > > numrecs = 27 > > leftsib = null > > rightsib = null > > recs[1-27] = [startoff,startblock,blockcount,extentflag] > > 1:[0,185637,16,0] 2: [16,185537,8,0] 3:[24,185718,8,0] 4:[32,185706,8,0] > > 5:[40,185836,8,0] 6: [48,185848,16,0] 7:[64,185865,16,0] > > 8:[80,185882,8,0] 9:[96,185899,16,0] 10: [112,185916,16,0] > > 11:[340,185934,2,0] 12:[342,4768704,1320,0] 13: [1662,4770389,239,0] > > 14:[1901,4770919,264,0] 15:[2165,4771391,165,0] 16: [2330,4771860,227,0] > > 17:[2557,4861204,351,0] 18:[2908,4861800,257,0] 19: [3165,4862282,349,0] > > 20:[3514,4862934,230,0] 21:[3744,4863506,383,0] 22: [4127,4864141,348,0] > > 23:[4475,4864871,228,0] 24:[4703,4865358,268,0] 25: [4971,4865882,593,0] > > 26:[5564,4866818,339,0] 27:[5903,4867729,1928,0] From owner-xfs@oss.sgi.com Sat Nov 4 16:49:42 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 04 Nov 2006 16:49:44 -0800 (PST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kA50nfaG023799 for ; Sat, 4 Nov 2006 16:49:42 -0800 X-ASG-Debug-ID: 1162687733-23291-601-0 X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by cuda.sgi.com (Spam Firewall) with SMTP id 7655A5075F7 for ; Sat, 4 Nov 2006 16:48:53 -0800 (PST) Received: (qmail invoked by alias); 05 Nov 2006 00:48:51 -0000 Received: from port-212-202-77-183.dynamic.qsc.de (EHLO clx) [212.202.77.183] by mail.gmx.net (mp019) with SMTP; 05 Nov 2006 01:48:51 +0100 X-Authenticated: #20522298 From: peyytmek@gmx.de To: Timothy Shimmin X-ASG-Orig-Subj: Re: Xfs-mailinglist question (xfs mounting problem, hdb1 just freezes) Subject: Re: Xfs-mailinglist question (xfs mounting problem, hdb1 just freezes) Date: Sun, 5 Nov 2006 00:48:43 +0000 User-Agent: KMail/1.9.1 References: <200611012255.46008.peyytmek@gmx.de> <3B2B6490C980DD2C8B4C9645@timothy-shimmins-power-mac-g5.local> <200611040214.29997.peyytmek@gmx.de> In-Reply-To: <200611040214.29997.peyytmek@gmx.de> Cc: xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Message-Id: <200611050048.43868.peyytmek@gmx.de> X-Y-GMX-Trusted: 0 X-Barracuda-Spam-Score: 0.55 X-Barracuda-Spam-Status: No, SCORE=0.55 using per-user scores of TAG_LEVEL=3.5 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=NO_REAL_NAME X-Barracuda-Spam-Report: Code version 3.02, rules version 3.0.25074 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.55 NO_REAL_NAME From: does not include a real name Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id kA50ngaG023805 X-archive-position: 9547 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: peyytmek@gmx.de Precedence: bulk X-list: xfs Content-Length: 6059 Lines: 178 On Saturday 04 November 2006 02:14, you wrote: Hi Well. I kinda managed to recover my data I used another computer for it and just plugged and xfs_repair /dev/hdb1 now it works just fine. Althought I have no idea what caused all the freezing if i accessed /dev/hdb1 on my server Thanks for help. Bye D.H. > On Friday 03 November 2006 00:58, you wrote: > > Hello again > Thanks for your email > > First of all, everytime I do xfs_logprint /dev/hdb1, with -ti or -tibo > or mounting the partition with a kernel pre May 26 > (kernel-2.16.3-gentoo-r3) or even xfs_repair -L /dev/hdb1 it's always the > same. my terminal just freezes > > There is also nothing in /var/log/messages > > Well, I'm going to try my hdd in another computer with a different > ide-controller. maybe that's the problem althought i doubt it would really > work that way out. > > Bye, > D.H. > > > Hi there, > > > > Sorry about not getting back to you. > > > > The inode details you sent me look reasonable to me (AFAICS). > > However, the inode that we are processing which has problems > > is probably coming from the log. > > Basically, during log replay we reinstate metadata such as inodes, > > inode buffers, > > and later process an unlinked-list which this inode appears to be on. > > It's during the truncating (as part of inactivating the inode) that we > > have problems when looking at its extents. > > > > You should be able to see this inode in the log if you use: > > # xfs_logprint -ti device > > (or possibly I guess > > # xfs_logrpint -tibo device - if the inode is in a buffer of inodes) > > I'd be curious to see this. > > > > My thoughts for a plan of action were either: > > (1) forget the log and do an "xfs_repair -L" to zero it out and repair > > or > > (2) somehow try to do a mount which avoids the unlinked list processing > > (an older kernel (pre May 26) would do this because of a bug in > > recovery); then unmount, then do a normal "xfs_repair" > > or > > (3) we try to stop this particular inode from being processed in the > > unlinked-list inode processing during mount; unmount; repair and then > > mount again > > > > The simplest is to do option (1). However, it means that any other > > outstanding metadata changes would be lost. > > Option (2) might be a goer but you need such a kernel and in that case it > > won't do any unlinked processing for a group of such inodes (one's hashed > > to that bucket in the AGI's). I'm unsure on how to stop this unlinked > > processing otherwise. > > Option (3) I'm unsure as how to do. Also, there could be more inodes in > > the same boat which could cause recovery to crash. > > > > May be others have suggestions. > > > > Regards, > > Tim. > > > > --On 1 November 2006 10:55:43 PM +0000 peyytmek@gmx.de wrote: > > > Hello, > > > Thanks for your last answer. Since you didn't answer my email for 2 > > > weeks i thought you might have deleted it accidently > > > > > > Here's the email conversation: > > >> > Hello. > > >> > Thanks for your answer. > > >> > > > >> > That's what i have: dmesg print with kernel-2.6.16-gentoo-r3 and an > > >> > print of xfs_bg. > > >> > > > >> >> You could print out the offending inode with xfs_db to show us > > >> >> what it looks like: $xfs_db -r /dev/hdb1 -c "inode 950759" -c > > >> >> "print". > > >> > > > >> > I don't know what you mean with it but i added it anyway. (done with > > >> > kernel-2.6.18-gentoo if it matters) > > >> > > > >> > xfs_db: > > >> > > > >> > CLX ~ # xfs_db -r /dev/hdb1 -c "inode 950759" -c "print" > > >> > core.magic = 0x494e > > >> > core.mode = 0100644 > > >> > core.version = 1 > > >> > core.format = 3 (btree) > > >> > core.nlinkv1 = 0 > > >> > core.uid = 1000 > > >> > core.gid = 100 > > >> > core.flushiter = 0 > > >> > core.atime.sec = Sun Aug 27 14:56:52 2006 > > >> > core.atime.nsec = 657389250 > > >> > core.mtime.sec = Sun Aug 27 16:29:40 2006 > > >> > core.mtime.nsec = 080196250 > > >> > core.ctime.sec = Thu Oct  5 01:17:40 2006 > > >> > core.ctime.nsec = 976565958 > > >> > core.size = 32071862 > > >> > core.nblocks = 7833 > > >> > core.extsize = 0 > > >> > core.nextents = 28 > > >> > core.naextents = 0 > > >> > core.forkoff = 0 > > >> > core.aformat = 2 (extents) > > >> > core.dmevmask = 0 > > >> > core.dmstate = 0 > > >> > core.newrtbm = 0 > > >> > core.prealloc = 0 > > >> > core.realtime = 0 > > >> > core.immutable = 0 > > >> > core.append = 0 > > >> > core.sync = 0 > > >> > core.noatime = 0 > > >> > core.nodump = 0 > > >> > core.rtinherit = 0 > > >> > core.projinherit = 0 > > >> > core.nosymlinks = 0 > > >> > core.extsz = 0 > > >> > core.extszinherit = 0 > > >> > core.gen = 0 > > >> > next_unlinked = null > > >> > u.bmbt.level = 1 > > >> > u.bmbt.numrecs = 1 > > >> > u.bmbt.keys[1] = [startoff] 1:[0] > > >> > u.bmbt.ptrs[1] = 1:185933 > > >> > > >> And now: > > >> > > >> xfs_db -r /dev/hadb1 -c "fsb 185933" -c "type bmapbtd" -c "p" > > >> > > >> to look at the 28 extent records. > > >> > > >> --Tim > > > > > > Here's the content of my last Email > > > > > > > > > Hello, thanks again for your fast answer > > > Sorry for the double post last time. > > > here it comes > > > > > > > > > CLX ~ # xfs_db -r /dev/hdb1 -c "fsb 185933" -c "type bmapbtd" -c "p" > > > magic = 0x424d4150 > > > level = 0 > > > numrecs = 27 > > > leftsib = null > > > rightsib = null > > > recs[1-27] = [startoff,startblock,blockcount,extentflag] > > > 1:[0,185637,16,0] 2: [16,185537,8,0] 3:[24,185718,8,0] > > > 4:[32,185706,8,0] 5:[40,185836,8,0] 6: [48,185848,16,0] > > > 7:[64,185865,16,0] > > > 8:[80,185882,8,0] 9:[96,185899,16,0] 10: [112,185916,16,0] > > > 11:[340,185934,2,0] 12:[342,4768704,1320,0] 13: [1662,4770389,239,0] > > > 14:[1901,4770919,264,0] 15:[2165,4771391,165,0] 16: > > > [2330,4771860,227,0] 17:[2557,4861204,351,0] 18:[2908,4861800,257,0] > > > 19: [3165,4862282,349,0] 20:[3514,4862934,230,0] > > > 21:[3744,4863506,383,0] 22: [4127,4864141,348,0] > > > 23:[4475,4864871,228,0] 24:[4703,4865358,268,0] 25: > > > [4971,4865882,593,0] 26:[5564,4866818,339,0] 27:[5903,4867729,1928,0] From owner-xfs@oss.sgi.com Sun Nov 5 14:38:04 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 05 Nov 2006 14:38:08 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kA5Mc0aG007297 for ; Sun, 5 Nov 2006 14:38:03 -0800 Received: from [134.14.55.89] (soarer.melbourne.sgi.com [134.14.55.89]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA20766; Mon, 6 Nov 2006 09:37:05 +1100 Message-ID: <454E6795.1040900@sgi.com> Date: Mon, 06 Nov 2006 09:37:09 +1100 From: Vlad Apostolov User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: jgl@johngroves.net CC: John Groves , linux-xfs@oss.sgi.com, Dean Roehrich Subject: Re: XFS dmapi: dm_path_to_handle fails if the path is a directory References: <4547DA70.4040107@Groves.net> <4547EDFD.8020407@sgi.com> <454A94A6.6040907@johngroves.net> <454AAC6B.7010406@sgi.com> <454AAF31.8050104@Groves.net> <454AB0A0.7050309@sgi.com> <454B58E4.6000802@johngroves.net> In-Reply-To: <454B58E4.6000802@johngroves.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9549 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: vapo@sgi.com Precedence: bulk X-list: xfs Content-Length: 1374 Lines: 44 John Groves wrote: > > > Vlad Apostolov wrote: > >> Just a note that dm_path_to_handle works fine with relative paths on >> my machine. > > In your case, could it be applying the "current working directory" > from the process context to resolve a full path? Mine is a daemon, > and the relative paths are not valid relative to the "cwd" in which > the daemon was started. > > ...just a thought. Otherwise, for the moment I may have to just > accept it as weird... > > Thanks again, > John I am using xfs-cmds/xfstests/dmapi/src/suite1/cmd/path_to_handle and the relative path passed as an argument is directly given to dm_path_to_handle(). The current working directory I can't really explain why it doesn't work in your case. Here is an example of a directory path to handle I get: emu:/home/vapo/isms/xfs-cmds/xfstests/dmapi/src/suite1/cmd # ./path_to_handle /mnt/scratch1/dmapi 5d1111a90e4800000e0000006e0000008300000000000000 emu:/home/vapo/isms/xfs-cmds/xfstests/dmapi/src/suite1/cmd # ./path_to_handle ../../../../../../../../../mnt/scratch1/dmapi 5d1111a90e4800000e0000006e0000008300000000000000 emu:/home/vapo/isms/xfs-cmds/xfstests/dmapi/src/suite1/cmd # cd / emu:/ # /home/vapo/isms/xfs-cmds/xfstests/dmapi/src/suite1/cmd/path_to_handle ../../../../../../../../../mnt/scratch1/dmapi 5d1111a90e4800000e0000006e0000008300000000000000 Regards, Vlad From owner-xfs@oss.sgi.com Sun Nov 5 17:15:09 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 05 Nov 2006 17:15:12 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kA61F6aG024803 for ; Sun, 5 Nov 2006 17:15:08 -0800 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA24098; Mon, 6 Nov 2006 12:14:06 +1100 Date: Mon, 06 Nov 2006 11:15:22 +1000 From: Timothy Shimmin To: Eric Sandeen cc: David Chinner , Christian Guggenberger , xfs@oss.sgi.com Subject: Re: mount failed after xfs_growfs beyond 16 TB Message-ID: In-Reply-To: <454B5833.9030008@sandeen.net> References: <20061102172608.GA27769@pc51072.physik.uni-regensburg.de> <20061103004142.GI8394166@melbourne.sgi.com> <454B5833.9030008@sandeen.net> X-Mailer: Mulberry/4.0.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-archive-position: 9552 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Content-Length: 1664 Lines: 48 Good idea, Eric. I've created a pv. I noticed this was taken from xfs_mount_validate_sb() for the dblocks test. I guess it would be nice to abstract this test in a macro for use in multiple places. Cheers, Tim. --On 3 November 2006 8:54:43 AM -0600 Eric Sandeen wrote: > David Chinner wrote: >> On Thu, Nov 02, 2006 at 06:26:08PM +0100, Christian Guggenberger wrote: >>> Hi, >>> >>> a colleague recently tried to grow a 16 TB filesystem (x86, 32bit) on >>> top of lvm2 to 17TB. (I am not even sure if that's supposed work with >>> linux-2.6, 32bit) >> >> Not supported - any metadata access past 16TB will wrap the 32 bit page cache >> index for the metadata address space and you'll corrupt the filesystem. > > > Ohhhh right. I've been in x86_64 land for too long, sorry for the earlier false assertion.... :( > > xfs guys, if it's not there already (and I don't see it from a quick look..) growfs -really- > should refuse (in the kernel) to grow a filesystem past 16T on a 32-bit machine, just as we > refuse to mount one. something like this in xfs_growfs_data_private: > ># if XFS_BIG_BLKNOS /* Limited by ULONG_MAX of page cache index */ > if (unlikely( > (nb >> (PAGE_SHIFT - sbp->sb_blocklog)) > ULONG_MAX) { ># else /* Limited by UINT_MAX of sectors */ > if (unlikely( > (nb << (sbp->sb_blocklog - BBSHIFT)) > UINT_MAX) { ># endif > cmn_err(CE_WARN, > "new filesystem size too large for this system."); > return XFS_ERROR(E2BIG); > } > > and something similar in xfs_growfs_rt ? > > -Eric > From owner-xfs@oss.sgi.com Sun Nov 5 19:26:01 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 05 Nov 2006 19:26:05 -0800 (PST) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kA63Q0aG001490 for ; Sun, 5 Nov 2006 19:26:01 -0800 X-ASG-Debug-ID: 1162783514-12542-499-0 X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com (Spam Firewall) with ESMTP id C6FA7D1BD719 for ; Sun, 5 Nov 2006 19:25:14 -0800 (PST) Received: from [10.0.0.4] (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id F037B18BCD2B7; Sun, 5 Nov 2006 21:25:13 -0600 (CST) Message-ID: <454EAB19.6060901@sandeen.net> Date: Sun, 05 Nov 2006 21:25:13 -0600 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Timothy Shimmin CC: David Chinner , Christian Guggenberger , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: mount failed after xfs_growfs beyond 16 TB Subject: Re: mount failed after xfs_growfs beyond 16 TB References: <20061102172608.GA27769@pc51072.physik.uni-regensburg.de> <20061103004142.GI8394166@melbourne.sgi.com> <454B5833.9030008@sandeen.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=3.5 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.02, rules version 3.0.25180 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-archive-position: 9553 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 408 Lines: 20 Timothy Shimmin wrote: > Good idea, Eric. > I've created a pv. > I noticed this was taken from xfs_mount_validate_sb() for the dblocks test. yep > I guess it would be nice to abstract this test in a macro for use in > multiple places. yep, it'd just need to be refactored a bit to support data only & rt only (for growfs), while mount wants to check both at the same time. -Eric > > Cheers, > Tim. From owner-xfs@oss.sgi.com Mon Nov 6 02:41:06 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 06 Nov 2006 02:41:11 -0800 (PST) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kA6Af6aG018301 for ; Mon, 6 Nov 2006 02:41:06 -0800 X-ASG-Debug-ID: 1162805334-9227-533-0 X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from server1.spsn.net (server1.spsn.net [195.234.231.102]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6CB08D1BDEE0 for ; Mon, 6 Nov 2006 01:28:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by server1.spsn.net (Postfix) with ESMTP id E4F8EACC01A for ; Mon, 6 Nov 2006 10:28:47 +0100 (CET) Received: from server1.spsn.net ([127.0.0.1]) by localhost (server1.spsn.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82ck1zPyNP9p for ; Mon, 6 Nov 2006 10:28:47 +0100 (CET) Received: by server1.spsn.net (Postfix, from userid 102) id CC7D3ACC01C; Mon, 6 Nov 2006 10:28:47 +0100 (CET) Received: from saschatest.adtech.de (unknown [213.200.64.124]) by server1.spsn.net (Postfix) with ESMTP id 506E5ACC01A for ; Mon, 6 Nov 2006 10:28:47 +0100 (CET) From: Sascha Nitsch To: xfs@oss.sgi.com X-ASG-Orig-Subj: Weird performance decrease Subject: Weird performance decrease Date: Mon, 6 Nov 2006 10:28:08 +0100 User-Agent: KMail/1.9.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200611061028.08963.sgi@linuxhowtos.org> X-Bogosity: Spam, tests=bogofilter, spamicity=1.000000, version=1.1.1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=3.5 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.02, rules version 3.0.25204 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-archive-position: 9554 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sgi@linuxhowtos.org Precedence: bulk X-list: xfs Content-Length: 2184 Lines: 62 Hi, I'm observing a rather strange behaviour of the filesystem cache algorithm. I have a server running the following app scenario: A filesystem tree with a depth of 7 directories and 4 character directory names. In the deepest directories are files. filesize from 100 bytes to 5kb. Filesystem is XFS. The app creates dirs in the tree and reads/writes files into the deepest dirs in the tree. CPU: Dual Xeon 3.0 Ghz w/HT 512KB cache each, 2GB RAM, SCSI-HDD 15k RPM The first while, all is fine and extremely fast. After a while the buffer size is about 3.5 MB and cache size about 618 MB. Until that moment ~445000 directories and ~106000 files have been created Thats where the weird behaviour starts. The buffer size drops to ~200 kb and cache size starts decreasing fast. This results in a drastic performace drop in my app. (avg. read/write times increase from 0.3ms to 4ms) not a constant increase, a jumping increase. During the next while it constantly gets slower (19ms and more). After running a while (with still reducing cache size) the buffer size stays at ~700kb and cache about 400 MB. Performane is terrible. Way slower than starting up with no cache. restarting the app makes no change, neither remounting the partition. cmd to create the fs: mkfs.xfs -b size=512 -i maxpct=0 -l version=2 -n size=16k /dev/sdc mounting with mount /dev/sdc /data I'm open for suggestion on mkfs calls, mount options and kernel tuning via procfs. I have a testcase to reproduce the problem. It happens after ~45 minutes. xfs_info /data/ meta-data=/data isize=256 agcount=16, agsize=8960921 blks = sectsz=512 data = bsize=512 blocks=143374736, imaxpct=0 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=16384 log =internal bsize=512 blocks=65536, version=2 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 kernel: a 2.6.9-34.0.2.ELsmp #1 SMP Mon Jul 17 21:41:41 CDT 2006 i686 i686 i386 GNU/Linux filesystem usage is < 1% From owner-xfs@oss.sgi.com Mon Nov 6 03:32:59 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 06 Nov 2006 03:33:04 -0800 (PST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kA6BWwaG027725 for ; Mon, 6 Nov 2006 03:32:59 -0800 X-ASG-Debug-ID: 1162812730-2823-298-0 X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from server1.spsn.net (server1.spsn.net [195.234.231.102]) by cuda.sgi.com (Spam Firewall) with ESMTP id F0BDD50CAF0 for ; Mon, 6 Nov 2006 03:32:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by server1.spsn.net (Postfix) with ESMTP id B6015ACC01C; Mon, 6 Nov 2006 12:32:06 +0100 (CET) Received: from server1.spsn.net ([127.0.0.1]) by localhost (server1.spsn.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9nU5uYRtLM72; Mon, 6 Nov 2006 12:32:06 +0100 (CET) Received: by server1.spsn.net (Postfix, from userid 102) id 94B19ACC039; Mon, 6 Nov 2006 12:32:06 +0100 (CET) Received: from saschatest.adtech.de (unknown [213.200.64.124]) by server1.spsn.net (Postfix) with ESMTP id 8218DACC01C; Mon, 6 Nov 2006 12:32:05 +0100 (CET) From: Sascha Nitsch To: Ruben Rubio X-ASG-Orig-Subj: Re: Weird performance decrease Subject: Re: Weird performance decrease Date: Mon, 6 Nov 2006 12:31:26 +0100 User-Agent: KMail/1.9.5 References: <200611061028.08963.sgi@linuxhowtos.org> <454F16E4.6050907@rentalia.com> In-Reply-To: <454F16E4.6050907@rentalia.com> Cc: xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Message-Id: <200611061231.26623.sgi@linuxhowtos.org> X-Bogosity: Spam, tests=bogofilter, spamicity=1.000000, version=1.1.1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=3.5 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.02, rules version 3.0.25214 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id kA6BWxaG027729 X-archive-position: 9555 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sgi@linuxhowtos.org Precedence: bulk X-list: xfs Content-Length: 4073 Lines: 104 On Monday 06 November 2006 12:05, you wrote: > I have seen that there is performance problems when there is some files > in a directory and data is being added in the files. > > Are the files franmented? > Go to a directory where the files are listed, and > xfs_bmap -v * | less > > Check out the results. The files themself are not fragmentented. They only get (re)written at once. No appends. But a couple of the directories have extends. Examples: 0354: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL 0: [0..7]: 8964012..8964019 1 (3091..3098) 8 1: [8..15]: 9013089..9013096 1 (52168..52175) 8 00f0: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL 0: [0..7]: 80648721..80648728 9 (432..439) 8 1: [8..15]: 80654561..80654568 9 (6272..6279) 8 2: [16..23]: 80662073..80662080 9 (13784..13791) 8 3: [24..31]: 80669473..80669480 9 (21184..21191) 8 4: [32..39]: 80677185..80677192 9 (28896..28903) 8 5: [40..47]: 80685105..80685112 9 (36816..36823) 8 6: [48..55]: 80692545..80692552 9 (44256..44263) 8 7: [56..63]: 80700001..80700008 9 (51712..51719) 8 8: [64..71]: 80708272..80708279 9 (59983..59990) 8 9: [72..79]: 80716819..80716826 9 (68530..68537) 8 some up to 123 (tested via some checks in random picked directories). Would increasing the directory size help to avoid those extends? I'm quite new when it comes to internal stuff of xfs, just used it "as is" and was happy. Sascha > Sascha Nitsch escribió: > > Hi, > > > > I'm observing a rather strange behaviour of the filesystem cache > > algorithm. > > > > I have a server running the following app scenario: > > > > A filesystem tree with a depth of 7 directories and 4 character directory > > names. > > In the deepest directories are files. > > filesize from 100 bytes to 5kb. > > Filesystem is XFS. > > > > The app creates dirs in the tree and reads/writes files into the deepest > > dirs in the tree. > > > > CPU: Dual Xeon 3.0 Ghz w/HT 512KB cache each, 2GB RAM, SCSI-HDD 15k RPM > > > > The first while, all is fine and extremely fast. After a while the buffer > > size is about 3.5 MB > > and cache size about 618 MB. > > Until that moment ~445000 directories and ~106000 files have been created > > > > Thats where the weird behaviour starts. > > > > The buffer size drops to ~200 kb and cache size starts decreasing fast. > > This results in a drastic performace drop in my app. > > (avg. read/write times increase from 0.3ms to 4ms) > > not a constant increase, a jumping increase. During the next while it > > constantly gets slower (19ms and more). > > > > After running a while (with still reducing cache size) the buffer size > > stays at > > ~700kb and cache about 400 MB. Performane is terrible. Way slower than > > starting up with no cache. > > > > restarting the app makes no change, neither remounting the partition. > > > > cmd to create the fs: > > mkfs.xfs -b size=512 -i maxpct=0 -l version=2 -n size=16k /dev/sdc > > mounting with > > mount /dev/sdc /data > > > > I'm open for suggestion on mkfs calls, mount options and kernel tuning > > via procfs. > > I have a testcase to reproduce the problem. It happens after ~45 minutes. > > > > xfs_info /data/ > > meta-data=/data isize=256 agcount=16, agsize=8960921 > > blks = sectsz=512 > > data = bsize=512 blocks=143374736, imaxpct=0 > > = sunit=0 swidth=0 blks, unwritten=1 > > naming =version 2 bsize=16384 > > log =internal bsize=512 blocks=65536, version=2 > > = sectsz=512 sunit=0 blks > > realtime =none extsz=65536 blocks=0, rtextents=0 > > > > kernel: > > a 2.6.9-34.0.2.ELsmp #1 SMP Mon Jul 17 21:41:41 CDT 2006 i686 i686 i386 > > GNU/Linux > > > > filesystem usage is < 1% From owner-xfs@oss.sgi.com Mon Nov 6 04:34:47 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 06 Nov 2006 04:34:57 -0800 (PST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kA6CYjaG006698 for ; Mon, 6 Nov 2006 04:34:46 -0800 X-ASG-Debug-ID: 1162811523-28682-557-0 X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.rentalia.net (mail.rentalia.com [213.192.209.8]) by cuda.sgi.com (Spam Firewall) with ESMTP id 2168650C79C for ; Mon, 6 Nov 2006 03:12:03 -0800 (PST) Received: (qmail 27720 invoked by uid 514); 6 Nov 2006 12:05:20 +0100 Received: from 62.37.216.226 by rigodon (envelope-from , uid 512) with qmail-scanner-1.25-st-qms (clamdscan: 0.88/1284. spamassassin: 3.0.2. perlscan: 1.25-st-qms. Clear:RC:0(62.37.216.226):SA:0(-2.4/5.0):. Processed in 6.089067 secs); 06 Nov 2006 11:05:20 -0000 X-Antivirus-MYDOMAIN-Mail-From: ruben@rentalia.com via rigodon X-Antivirus-MYDOMAIN: 1.25-st-qms (Clear:RC:0(62.37.216.226):SA:0(-2.4/5.0):. Processed in 6.089067 secs Process 27671) Received: from 226.pool62-37-216.dynamic.uni2.es (HELO ?192.168.2.28?) (ruben@rentalia.com@62.37.216.226) by mail.rentalia.net with SMTP; 6 Nov 2006 12:05:13 +0100 Message-ID: <454F16E4.6050907@rentalia.com> Date: Mon, 06 Nov 2006 12:05:08 +0100 From: Ruben Rubio User-Agent: Thunderbird 1.5.0.7 (X11/20060922) MIME-Version: 1.0 To: Sascha Nitsch CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Weird performance decrease Subject: Re: Weird performance decrease References: <200611061028.08963.sgi@linuxhowtos.org> In-Reply-To: <200611061028.08963.sgi@linuxhowtos.org> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Barracuda-Spam-Score: 1.00 X-Barracuda-Spam-Status: No, SCORE=1.00 using per-user scores of TAG_LEVEL=3.5 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=URI_NOVOWEL X-Barracuda-Spam-Report: Code version 3.02, rules version 3.0.25210 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 1.00 URI_NOVOWEL URI: URI hostname has long non-vowel sequence X-archive-position: 9556 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: ruben@rentalia.com Precedence: bulk X-list: xfs Content-Length: 2893 Lines: 89 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have seen that there is performance problems when there is some files in a directory and data is being added in the files. Are the files franmented? Go to a directory where the files are listed, and xfs_bmap -v * | less Check out the results. Sascha Nitsch escribió: > Hi, > > I'm observing a rather strange behaviour of the filesystem cache algorithm. > > I have a server running the following app scenario: > > A filesystem tree with a depth of 7 directories and 4 character directory > names. > In the deepest directories are files. > filesize from 100 bytes to 5kb. > Filesystem is XFS. > > The app creates dirs in the tree and reads/writes files into the deepest dirs > in the tree. > > CPU: Dual Xeon 3.0 Ghz w/HT 512KB cache each, 2GB RAM, SCSI-HDD 15k RPM > > The first while, all is fine and extremely fast. After a while the buffer size > is about 3.5 MB > and cache size about 618 MB. > Until that moment ~445000 directories and ~106000 files have been created > > Thats where the weird behaviour starts. > > The buffer size drops to ~200 kb and cache size starts decreasing fast. > This results in a drastic performace drop in my app. > (avg. read/write times increase from 0.3ms to 4ms) > not a constant increase, a jumping increase. During the next while it > constantly gets slower (19ms and more). > > After running a while (with still reducing cache size) the buffer size stays > at > ~700kb and cache about 400 MB. Performane is terrible. Way slower than > starting up with no cache. > > restarting the app makes no change, neither remounting the partition. > > cmd to create the fs: > mkfs.xfs -b size=512 -i maxpct=0 -l version=2 -n size=16k /dev/sdc > mounting with > mount /dev/sdc /data > > I'm open for suggestion on mkfs calls, mount options and kernel tuning via > procfs. > I have a testcase to reproduce the problem. It happens after ~45 minutes. > > xfs_info /data/ > meta-data=/data isize=256 agcount=16, agsize=8960921 blks > = sectsz=512 > data = bsize=512 blocks=143374736, imaxpct=0 > = sunit=0 swidth=0 blks, unwritten=1 > naming =version 2 bsize=16384 > log =internal bsize=512 blocks=65536, version=2 > = sectsz=512 sunit=0 blks > realtime =none extsz=65536 blocks=0, rtextents=0 > > kernel: > a 2.6.9-34.0.2.ELsmp #1 SMP Mon Jul 17 21:41:41 CDT 2006 i686 i686 i386 > GNU/Linux > > filesystem usage is < 1% > > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFTxbjIo1XmbAXRboRAuFBAKCDFC+FKGmIPEC7m2qPwntgAQO2pgCeJvZ1 fC5bypzpHkU7KMOwtwxObQI= =mIEc -----END PGP SIGNATURE----- From owner-xfs@oss.sgi.com Mon Nov 6 05:43:00 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 06 Nov 2006 05:43:09 -0800 (PST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kA6DgwaG013782 for ; Mon, 6 Nov 2006 05:42:59 -0800 X-ASG-Debug-ID: 1162820529-23404-394-0 X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from rrzmta2.rz.uni-regensburg.de (rrzmta2.rz.uni-regensburg.de [132.199.1.17]) by cuda.sgi.com (Spam Firewall) with ESMTP id 2A494508757 for ; Mon, 6 Nov 2006 05:42:09 -0800 (PST) Received: from rrzmta2.rz.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 002436A533; Mon, 6 Nov 2006 14:41:53 +0100 (CET) Received: from pc51072.physik.uni-regensburg.de (pc51072.physik.uni-regensburg.de [132.199.98.129]) by rrzmta2.rz.uni-regensburg.de (Postfix) with ESMTP id C5E6E6B0C3; Mon, 6 Nov 2006 14:41:53 +0100 (CET) Received: by pc51072.physik.uni-regensburg.de (Postfix, from userid 28561) id 87861507058; Mon, 6 Nov 2006 14:41:48 +0100 (CET) Date: Mon, 6 Nov 2006 14:41:48 +0100 From: Christian Guggenberger To: Christian Guggenberger Cc: David Chinner , Eric Sandeen , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: mount failed after xfs_growfs beyond 16 TB Subject: Re: mount failed after xfs_growfs beyond 16 TB Message-ID: <20061106134148.GA25180@pc51072.physik.uni-regensburg.de> Reply-To: christian.guggenberger@physik.uni-regensburg.de References: <20061102172608.GA27769@pc51072.physik.uni-regensburg.de> <454A3B28.7010405@sandeen.net> <20061103093203.GA18010@pc51072.physik.uni-regensburg.de> <20061103123418.GP8394166@melbourne.sgi.com> <20061103154448.GA26647@pc51072.physik.uni-regensburg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061103154448.GA26647@pc51072.physik.uni-regensburg.de> User-Agent: Mutt/1.5.9i X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=3.5 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.02, rules version 3.0.25222 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-archive-position: 9557 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: christian.guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: xfs Content-Length: 619 Lines: 23 On Fri, Nov 03, 2006 at 04:44:48PM +0100, Christian Guggenberger wrote: > > > > xfs_db mojo.... ;) > > > > Note - no guarantee this will work - practise on an expendable > > sparse loopback filessytem image by making a filesystem of slightly less > > than 16TB then growing it to corrupt it the same way and then fixing it up > > successfully. > > ... > > (btw, I still hope they get access to an 64bit system with recent > xfsprogs and kernel, soon) > for your info - with recent xfsprogs (2.8.11) repair (on a 32bit system) succeeded. No xfs_db magic needed. thanks again for your help, cheers. - Christian From owner-xfs@oss.sgi.com Mon Nov 6 15:40:14 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 06 Nov 2006 15:40:22 -0800 (PST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kA6NeBaG021842 for ; Mon, 6 Nov 2006 15:40:14 -0800 X-ASG-Debug-ID: 1162856365-7214-534-0 X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ext.agami.com (64.221.212.177.ptr.us.xo.net [64.221.212.177]) by cuda.sgi.com (Spam Firewall) with ESMTP id 7700B50E119 for ; Mon, 6 Nov 2006 15:39:25 -0800 (PST) Received: from agami.com ([192.168.168.115]) by ext.agami.com (8.12.5/8.12.5) with ESMTP id kA6NdIoV008664 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 6 Nov 2006 15:39:20 -0800 Received: from [10.123.4.231] (ind-1.agami.com [10.123.4.231]) (authenticated bits=0) by agami.com (8.12.11/8.12.11) with ESMTP id kA6NdD7d002436; Mon, 6 Nov 2006 15:39:13 -0800 Message-ID: <454FC5C3.8080803@agami.com> Date: Mon, 06 Nov 2006 15:31:15 -0800 From: Shailendra Tripathi User-Agent: Thunderbird 1.5.0.7 (X11/20060909) MIME-Version: 1.0 To: Sascha Nitsch CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Weird performance decrease Subject: Re: Weird performance decrease References: <200611061028.08963.sgi@linuxhowtos.org> In-Reply-To: <200611061028.08963.sgi@linuxhowtos.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.36 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=3.5 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.02, rules version 3.0.25246 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-archive-position: 9560 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: stripathi@agami.com Precedence: bulk X-list: xfs Content-Length: 2961 Lines: 86 Hi Sascha, Did you notice the iostat -x on the device ? Please verify the turnaround time of the device when you are getting the slowdown. For example, if %b is closer towards 100, perhaps you are maxing out on the disk I/O ops per sec. Since you have only one disk, once I/O becomes random, the disk wouldn't be able to do more than 200-250 disk ops per sec. # iostat -x sda 1 extended device statistics device mgr/s mgw/s r/s w/s kr/s kw/s size queue wait svc_t %b sda 3 7 3.5 18.5 157.0 112.9 12.3 0.2 9.7 1.7 4 Regards, Shailendra Sascha Nitsch wrote: > Hi, > > I'm observing a rather strange behaviour of the filesystem cache algorithm. > > I have a server running the following app scenario: > > A filesystem tree with a depth of 7 directories and 4 character directory > names. > In the deepest directories are files. > filesize from 100 bytes to 5kb. > Filesystem is XFS. > > The app creates dirs in the tree and reads/writes files into the deepest dirs > in the tree. > > CPU: Dual Xeon 3.0 Ghz w/HT 512KB cache each, 2GB RAM, SCSI-HDD 15k RPM > > The first while, all is fine and extremely fast. After a while the buffer size > is about 3.5 MB > and cache size about 618 MB. > Until that moment ~445000 directories and ~106000 files have been created > > Thats where the weird behaviour starts. > > The buffer size drops to ~200 kb and cache size starts decreasing fast. > This results in a drastic performace drop in my app. > (avg. read/write times increase from 0.3ms to 4ms) > not a constant increase, a jumping increase. During the next while it > constantly gets slower (19ms and more). > > After running a while (with still reducing cache size) the buffer size stays > at > ~700kb and cache about 400 MB. Performane is terrible. Way slower than > starting up with no cache. > > restarting the app makes no change, neither remounting the partition. > > cmd to create the fs: > mkfs.xfs -b size=512 -i maxpct=0 -l version=2 -n size=16k /dev/sdc > mounting with > mount /dev/sdc /data > > I'm open for suggestion on mkfs calls, mount options and kernel tuning via > procfs. > I have a testcase to reproduce the problem. It happens after ~45 minutes. > > xfs_info /data/ > meta-data=/data isize=256 agcount=16, agsize=8960921 blks > = sectsz=512 > data = bsize=512 blocks=143374736, imaxpct=0 > = sunit=0 swidth=0 blks, unwritten=1 > naming =version 2 bsize=16384 > log =internal bsize=512 blocks=65536, version=2 > = sectsz=512 sunit=0 blks > realtime =none extsz=65536 blocks=0, rtextents=0 > > kernel: > a 2.6.9-34.0.2.ELsmp #1 SMP Mon Jul 17 21:41:41 CDT 2006 i686 i686 i386 > GNU/Linux > > filesystem usage is < 1% > > > From owner-xfs@oss.sgi.com Tue Nov 7 00:18:48 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 07 Nov 2006 00:18:56 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kA78IjaG012195 for ; Tue, 7 Nov 2006 00:18:47 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA07474; Tue, 7 Nov 2006 19:17:54 +1100 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 kA78Hp7Y26816335; Tue, 7 Nov 2006 19:17:52 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id kA78HmgF26131385; Tue, 7 Nov 2006 19:17:48 +1100 (AEDT) Date: Tue, 7 Nov 2006 19:17:48 +1100 From: David Chinner To: Christian Guggenberger Cc: David Chinner , Eric Sandeen , xfs@oss.sgi.com Subject: Re: mount failed after xfs_growfs beyond 16 TB Message-ID: <20061107081748.GA8394166@melbourne.sgi.com> References: <20061102172608.GA27769@pc51072.physik.uni-regensburg.de> <454A3B28.7010405@sandeen.net> <20061103093203.GA18010@pc51072.physik.uni-regensburg.de> <20061103123418.GP8394166@melbourne.sgi.com> <20061103154448.GA26647@pc51072.physik.uni-regensburg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061103154448.GA26647@pc51072.physik.uni-regensburg.de> User-Agent: Mutt/1.4.2.1i X-archive-position: 9566 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 776 Lines: 31 On Fri, Nov 03, 2006 at 04:44:48PM +0100, Christian Guggenberger wrote: > > The superblock: > > > > blocksize = 4096 > > dblocks = 18446744070056148512 > > ... > > agblocks = 84976608 > > agcount = 570 > > > > An AG is ~43.5GB, so 570 AGs is 24.8TB. It's to big, and > > we will only shrink by whole AGs. Hence we have to correct > > agcount and dblocks. > > isn't the AG size 'agblocks * blocksize' == ~324 GB here ? Yes, you are right - I was thinking 512 byte blocks which then gave the right size that you grew to. Otherwise 570*324GB gives 200TB, which is somewhat larger than you apparently tried to grow to... Sorry for the misdirection, but I'm glad to see that you got it fixed. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Tue Nov 7 02:46:36 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 07 Nov 2006 02:46:41 -0800 (PST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kA7AkYaG030004 for ; Tue, 7 Nov 2006 02:46:36 -0800 X-ASG-Debug-ID: 1162896347-13353-584-0 X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from server1.spsn.net (server1.spsn.net [195.234.231.102]) by cuda.sgi.com (Spam Firewall) with ESMTP id 5125550F14E for ; Tue, 7 Nov 2006 02:45:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by server1.spsn.net (Postfix) with ESMTP id E3DB5A9C0F1; Tue, 7 Nov 2006 11:45:17 +0100 (CET) Received: from server1.spsn.net ([127.0.0.1]) by localhost (server1.spsn.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UzU+ANvZPH6k; Tue, 7 Nov 2006 11:45:17 +0100 (CET) Received: by server1.spsn.net (Postfix, from userid 102) id C0B8DA9C15F; Tue, 7 Nov 2006 11:45:17 +0100 (CET) Received: from saschatest.adtech.de (unknown [213.200.64.124]) by server1.spsn.net (Postfix) with ESMTP id 48E91A9C0F1; Tue, 7 Nov 2006 11:45:17 +0100 (CET) From: Sascha Nitsch To: Shailendra Tripathi X-ASG-Orig-Subj: Re: Weird performance decrease Subject: Re: Weird performance decrease Date: Tue, 7 Nov 2006 11:44:32 +0100 User-Agent: KMail/1.9.5 References: <200611061028.08963.sgi@linuxhowtos.org> <454FC5C3.8080803@agami.com> In-Reply-To: <454FC5C3.8080803@agami.com> Cc: xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200611071144.32925.sgi@linuxhowtos.org> X-Bogosity: Spam, tests=bogofilter, spamicity=1.000000, version=1.1.1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=3.5 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.02, rules version 3.0.25301 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-archive-position: 9569 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sgi@linuxhowtos.org Precedence: bulk X-list: xfs Content-Length: 4477 Lines: 111 On Tuesday 07 November 2006 00:31, you wrote: > Hi Sascha, > Did you notice the iostat -x on the device ? Please > verify the turnaround time of the device when you are getting the slowdown. > > For example, if %b is closer towards 100, perhaps you are maxing out on > the disk I/O ops per sec. > Since you have only one disk, once I/O becomes random, the disk wouldn't > be able to do more than 200-250 disk ops per sec. > > # iostat -x sda 1 > extended device statistics > device mgr/s mgw/s r/s w/s kr/s kw/s size queue wait > svc_t %b > sda 3 7 3.5 18.5 157.0 112.9 12.3 0.2 9.7 > 1.7 4 > > > Regards, > Shailendra Hi Shailendra, here are some measurements: == startup (very high performance) == top: Cpu0 : 0.2% us, 0.0% sy, 0.0% ni, 99.8% id, 0.0% wa, 0.0% hi, 0.0% si Cpu1 : 0.0% us, 0.0% sy, 0.0% ni, 100.0% id, 0.0% wa, 0.0% hi, 0.0% si Cpu2 : 0.0% us, 0.0% sy, 0.0% ni, 100.0% id, 0.0% wa, 0.0% hi, 0.0% si Cpu3 : 0.0% us, 0.0% sy, 0.0% ni, 100.0% id, 0.0% wa, 0.0% hi, 0.0% si Mem: 2074432k total, 133784k used, 1940648k free, 15652k buffers Swap: 2618488k total, 160k used, 2618328k free, 53508k cached iostat -x Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await sv