From owner-freebsd-geom@FreeBSD.ORG Mon Apr 15 11:06:43 2013 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CD2CE95E for ; Mon, 15 Apr 2013 11:06:43 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id B126479A for ; Mon, 15 Apr 2013 11:06:43 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r3FB6h4v015089 for ; Mon, 15 Apr 2013 11:06:43 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r3FB6hBF015087 for freebsd-geom@FreeBSD.org; Mon, 15 Apr 2013 11:06:43 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 15 Apr 2013 11:06:43 GMT Message-Id: <201304151106.r3FB6hBF015087@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-geom@FreeBSD.org Subject: Current problem reports assigned to freebsd-geom@FreeBSD.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 11:06:43 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/176744 geom [geom] [patch] BIO_FLUSH not recorded by devstats o kern/170038 geom [geom] geom_mirror always starts degraded after reboot o kern/169539 geom [geom] [patch] fix ability to run gmirror on MSI MegaR a bin/169077 geom bsdinstall(8) does not use partition labels in /etc/fs f kern/165745 geom [geom] geom_multipath page fault on removed drive o kern/165428 geom [glabel][patch] Add xfs support to glabel o kern/164254 geom [geom] gjournal not stopping on GPT partitions o kern/164252 geom [geom] gjournal overflow o kern/164143 geom [geom] Partition table not recognized after upgrade R8 a kern/163020 geom [geli] [patch] enable the Camellia-XTS on GEOM ELI o kern/162690 geom [geom] gpart label changes only take effect after a re o kern/162010 geom [geli] panic: Provider's error should be set (error=0) o kern/161979 geom [geom] glabel doesn't update after newfs, and glabel s o kern/161752 geom [geom] glabel(8) doesn't get gpt label change o bin/161677 geom gpart(8) Probably bug in gptboot o kern/160409 geom [geli] failed to attach provider f kern/159595 geom [geom] [panic] panic on gmirror unload in vbox [regres f kern/159414 geom [isp] isp(4)+gmultipath(8) : removing active fiber pat p kern/158398 geom [headers] [patch] includes o kern/158197 geom [geom] geom_cache with size>1000 leads to panics o kern/157879 geom [libgeom] [regression] ABI change without version bump o kern/157863 geom [geli] kbdmux prevents geli passwords from being enter o kern/157739 geom [geom] GPT labels with geom_multipath o kern/157724 geom [geom] gpart(8) 'add' command must preserve gap for sc o kern/157723 geom [geom] GEOM should not process 'c' (raw) partitions fo o kern/157108 geom [gjournal] dumpon(8) fails on gjournal providers o kern/155994 geom [geom] Long "Suspend time" when reading large files fr o kern/154226 geom [geom] GEOM label does not change when you modify them o kern/150858 geom [geom] [geom_label] [patch] glabel(8) is not compatibl o kern/150626 geom [geom] [gjournal] gjournal(8) destroys label o kern/150555 geom [geom] gjournal unusable on GPT partitions o kern/150334 geom [geom] [udf] [patch] geom label does not support UDF o kern/149762 geom volume labels with rogue characters o bin/149215 geom [panic] [geom_part] gpart(8): Delete linux's slice via o kern/147667 geom [gmirror] Booting with one component of a gmirror, the o kern/145818 geom [geom] geom_stat_open showing cached information for n o kern/145042 geom [geom] System stops booting after printing message "GE o kern/143455 geom gstripe(8) in RELENG_8 (31st Jan 2010) broken o kern/142563 geom [geom] [hang] ioctl freeze in zpool o kern/141740 geom [geom] gjournal(8): g_journal_destroy concurrent error o kern/140352 geom [geom] gjournal + glabel not working o kern/135898 geom [geom] Severe filesystem corruption - large files or l o kern/134113 geom [geli] Problem setting secondary GELI key o kern/133931 geom [geli] [request] intentionally wrong password to destr o bin/132845 geom [geom] [patch] ggated(8) does not close files opened a o bin/131415 geom [geli] keystrokes are unregulary sent to Geli when typ o kern/131353 geom [geom] gjournal(8) kernel lock o kern/129674 geom [geom] gjournal root did not mount on boot o kern/129645 geom gjournal(8): GEOM_JOURNAL causes system to fail to boo o kern/129245 geom [geom] gcache is more suitable for suffix based provid o kern/127420 geom [geom] [gjournal] [panic] Journal overflow on gmirrore o kern/124973 geom [gjournal] [patch] boot order affects geom_journal con o kern/124969 geom gvinum(8): gvinum raid5 plex does not detect missing s o kern/123962 geom [panic] [gjournal] gjournal (455Gb data, 8Gb journal), o kern/123122 geom [geom] GEOM / gjournal kernel lock o kern/122738 geom [geom] gmirror list "losts consumers" after gmirror de o kern/122067 geom [geom] [panic] Geom crashed during boot o kern/121364 geom [gmirror] Removing all providers create a "zombie" mir o kern/120091 geom [geom] [geli] [gjournal] geli does not prompt for pass o kern/115856 geom [geli] ZFS thought it was degraded when it should have o kern/115547 geom [geom] [patch] [request] let GEOM Eli get password fro o kern/113837 geom [geom] unable to access 1024 sector size storage o kern/113419 geom [geom] geom fox multipathing not failing back o kern/107707 geom [geom] [patch] [request] add new class geom_xbox360 to o kern/94632 geom [geom] Kernel output resets input while GELI asks for o kern/90582 geom [geom] [panic] Restore cause panic string (ffs_blkfree o bin/90093 geom fdisk(8) incapable of altering in-core geometry o kern/87544 geom [gbde] mmaping large files on a gbde filesystem deadlo o bin/86388 geom [geom] [geom_part] periodic(8) daily should backup gpa o kern/84556 geom [geom] [panic] GBDE-encrypted swap causes panic at shu o kern/79251 geom [2TB] newfs fails on 2.6TB gbde device o kern/79035 geom [vinum] gvinum unable to create a striped set of mirro o bin/78131 geom gbde(8) "destroy" not working. 73 problems total. From owner-freebsd-geom@FreeBSD.ORG Mon Apr 15 18:39:58 2013 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 27851A85; Mon, 15 Apr 2013 18:39:58 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id E825212D1; Mon, 15 Apr 2013 18:39:54 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 15D891E0; Mon, 15 Apr 2013 20:36:14 +0200 (CEST) Date: Mon, 15 Apr 2013 20:42:03 +0200 From: Pawel Jakub Dawidek To: Alexander Motin Subject: Re: devstat overhead VS precision Message-ID: <20130415184203.GA1839@garage.freebsd.pl> References: <51692C95.3010901@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jRHKVT23PllUwdXP" Content-Disposition: inline In-Reply-To: <51692C95.3010901@FreeBSD.org> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@FreeBSD.org, freebsd-geom@FreeBSD.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 18:39:58 -0000 --jRHKVT23PllUwdXP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Apr 13, 2013 at 12:59:49PM +0300, Alexander Motin wrote: > Hi. >=20 > It is long known that collecting disk and GEOM statistics may cause=20 > significant processing overhead under high IOPS. On my recent high-IOPS= =20 > benchmarks performance difference was reaching three times! Last time=20 > situation improved a lot by more active use of TSC, but there are still= =20 > many systems where TSCs are not synchronized. I propose to switch that=20 > statistics from using binuptime() to getbinuptime() to solve the problem= =20 > globally. >=20 > From one side getbinuptime() resolution is limited by 1ms, but since=20 > time is usually averaged over the many I/Os, additional sub-millisecond= =20 > precision will come from sampling. Since most of tools now show request= =20 > processing times up to 0.1ms, that precision should be sufficient. I=20 > believe real disk performance is more important that n-th digit in some= =20 > statistics. >=20 > The following patch does the change and makes disk performance=20 > irrelevant to the timecounter performance: > http://people.freebsd.org/~mav/devstat_time.patch >=20 > Are there any objections against it? No objections here, but I wonder if you were able to compare the results somehow before and after the change so we have some hard numbers to show that we don't lose much by applying the change. On a mostly unrelated note when two threads (T0 and T1) call get*time() on two different cores, but T0 does that a bit earlier is it possible that T0 can get later time than T1? --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com --jRHKVT23PllUwdXP Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlFsSfsACgkQForvXbEpPzSVlgCgtgrIp5Wpi0WYlOFXuCZr8BZY x6IAoOUXv9oinJ61u126VKsqgPeUmWGM =noxd -----END PGP SIGNATURE----- --jRHKVT23PllUwdXP-- From owner-freebsd-geom@FreeBSD.ORG Mon Apr 15 19:13:36 2013 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BE39E603; Mon, 15 Apr 2013 19:13:36 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ea0-x22d.google.com (mail-ea0-x22d.google.com [IPv6:2a00:1450:4013:c01::22d]) by mx1.freebsd.org (Postfix) with ESMTP id 04E35153D; Mon, 15 Apr 2013 19:13:35 +0000 (UTC) Received: by mail-ea0-f173.google.com with SMTP id k11so2433517eaj.32 for ; Mon, 15 Apr 2013 12:13:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=dL9CFkwr3uaohHKnHkOWW2VUUtAo0Mt/3ByA90QWg5A=; b=UUIAVJT6Skg4Lcx3ZeTkzaaKLDoXvPDz9cfCD0px8LrHCxTTkB4YbHr6Wjv6ZnxWaz BsV6TsNHyZtT2vwlbxUZfxxm4TBpmF4M7KoDZma9qm1z8TYD/7yqmARMrwJm66AM5Dg/ /DLTK+0Pe1JNInQXUSj7xNlYhhS29LXvqDKdQgl8P16xcXlZfRf0EqlfhAIyBPMTIFOJ 3YMVauUHtyGLu/m+qv1ufz/r0xROkjtKspgWfmoFWb4CPaxpyslPD+W776r7vc7U6rh7 U1Pm6XZp3NB8p6xxCyT5awByXMQ6xtvYZ70MY+Z/k6VeG39ZxcoC6eR5S9TiAVcZWkpq r8oA== X-Received: by 10.14.149.141 with SMTP id x13mr32974188eej.31.1366053214378; Mon, 15 Apr 2013 12:13:34 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id u44sm28373499eel.7.2013.04.15.12.13.32 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Apr 2013 12:13:33 -0700 (PDT) Sender: Alexander Motin Message-ID: <516C515A.9090602@FreeBSD.org> Date: Mon, 15 Apr 2013 22:13:30 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130413 Thunderbird/17.0.5 MIME-Version: 1.0 To: Pawel Jakub Dawidek Subject: Re: devstat overhead VS precision References: <51692C95.3010901@FreeBSD.org> <20130415184203.GA1839@garage.freebsd.pl> In-Reply-To: <20130415184203.GA1839@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, freebsd-geom@FreeBSD.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 19:13:36 -0000 On 15.04.2013 21:42, Pawel Jakub Dawidek wrote: > On Sat, Apr 13, 2013 at 12:59:49PM +0300, Alexander Motin wrote: >> Hi. >> >> It is long known that collecting disk and GEOM statistics may cause >> significant processing overhead under high IOPS. On my recent high-IOPS >> benchmarks performance difference was reaching three times! Last time >> situation improved a lot by more active use of TSC, but there are still >> many systems where TSCs are not synchronized. I propose to switch that >> statistics from using binuptime() to getbinuptime() to solve the problem >> globally. >> >> From one side getbinuptime() resolution is limited by 1ms, but since >> time is usually averaged over the many I/Os, additional sub-millisecond >> precision will come from sampling. Since most of tools now show request >> processing times up to 0.1ms, that precision should be sufficient. I >> believe real disk performance is more important that n-th digit in some >> statistics. >> >> The following patch does the change and makes disk performance >> irrelevant to the timecounter performance: >> http://people.freebsd.org/~mav/devstat_time.patch >> >> Are there any objections against it? > > No objections here, but I wonder if you were able to compare the results > somehow before and after the change so we have some hard numbers to show > that we don't lose much by applying the change. I haven't tested it statistically, but I haven't noticed any visual difference in gstat output with its 0.1ms displayed resolution. > On a mostly unrelated note when two threads (T0 and T1) call get*time() > on two different cores, but T0 does that a bit earlier is it possible > that T0 can get later time than T1? There is no any locking or memory barriers in get*time(), so CPU is free to do some prefetching and out-of-order execution, slightly blurring "a bit earlier" concept. Except such close cases I believe it should not happen. -- Alexander Motin From owner-freebsd-geom@FreeBSD.ORG Mon Apr 15 19:18:19 2013 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6A1AB754; Mon, 15 Apr 2013 19:18:19 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id D4451157B; Mon, 15 Apr 2013 19:18:18 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r3FJIFng018857; Mon, 15 Apr 2013 22:18:15 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.2 kib.kiev.ua r3FJIFng018857 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r3FJIFrR018856; Mon, 15 Apr 2013 22:18:15 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 15 Apr 2013 22:18:15 +0300 From: Konstantin Belousov To: Pawel Jakub Dawidek Subject: Re: devstat overhead VS precision Message-ID: <20130415191815.GR2930@kib.kiev.ua> References: <51692C95.3010901@FreeBSD.org> <20130415184203.GA1839@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6cExhHXXDEBW2NKZ" Content-Disposition: inline In-Reply-To: <20130415184203.GA1839@garage.freebsd.pl> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-hackers@FreeBSD.org, Alexander Motin , freebsd-geom@FreeBSD.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 19:18:19 -0000 --6cExhHXXDEBW2NKZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Apr 15, 2013 at 08:42:03PM +0200, Pawel Jakub Dawidek wrote: > On a mostly unrelated note when two threads (T0 and T1) call get*time() > on two different cores, but T0 does that a bit earlier is it possible > that T0 can get later time than T1? Define earlier first. If you have taken sufficient measures to prevent preemption and interruption, e.g. by entering spinlock before the fragment that calls get*, then no, it is impossible, at least not with any x86 timekeeping hardware we use. On the other hand, if interrupts are allowed, all bets are off. --6cExhHXXDEBW2NKZ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRbFJ2AAoJEJDCuSvBvK1B23MQAJEv7S5Z6HpuFZZEPrvvoFAJ uoYC+eIVzmQ0tcf6BsCjhd0/hqwjzF34be8wtaAvJdzBoMgJ44RJci2bCl0NHM6L Onwt6L8o4Tdx5gc6LzrERH78aCrpIBtOrg5y/oOr+9ecv4EKLuCm8xQf4SDQyY4F qcteyKQOaWDyZkRZQ7FMH9FpRPHQ+1yVEWsyxoqLck4hASoE87/ogieWPr2/4RGg jMzH8UFgdmnv3FgMZc+9ksHcZZctoOZt613O+LyVX6/vQwHubeefXcRbuGxnbE2h 1LAIlzIUWwm2H6LkWrqBM6TABu17vb1YPRgGtg8hE7Gfktd7QT31IZ3NL5IO9DRE 9esF9Ya32zrCcFOXZb/TkmC9RsdcjCwQHhK/VR1rUe6ZP3C5sq1yTWwMFG2GtXIv zdMrqOlJO69Cw3efrMcPBtRY0U5b48KtOmLqK/ntuRjo7I1np4c+tXEdRpRgSJy3 +aVBJHijtId4jahvwN2+DswXw8gxhYRs692IuR+P5VSg+d5Il/NSve8RFj0SfCO1 SP4eY+MfDBbxQOoxGTjDVNNK9uRKRDAF/6Hx0zB/nvySXLDBMG9whmVXj4pYSFfL dF310fGGxKiUGZ1vr/ESAPB220TNg1O0PS1nb0r9caJHWj+FK/7b4FdrCZi5Dspy p7uuueUvPU+Ja9a5IF/V =XPWU -----END PGP SIGNATURE----- --6cExhHXXDEBW2NKZ-- From owner-freebsd-geom@FreeBSD.ORG Mon Apr 15 19:35:22 2013 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5F446D7D; Mon, 15 Apr 2013 19:35:22 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id 2B1981625; Mon, 15 Apr 2013 19:35:21 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 7AA01229; Mon, 15 Apr 2013 21:31:41 +0200 (CEST) Date: Mon, 15 Apr 2013 21:37:30 +0200 From: Pawel Jakub Dawidek To: Konstantin Belousov Subject: Re: devstat overhead VS precision Message-ID: <20130415193730.GB1839@garage.freebsd.pl> References: <51692C95.3010901@FreeBSD.org> <20130415184203.GA1839@garage.freebsd.pl> <20130415191815.GR2930@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4SFOXa2GPu3tIq4H" Content-Disposition: inline In-Reply-To: <20130415191815.GR2930@kib.kiev.ua> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@FreeBSD.org, Alexander Motin , freebsd-geom@FreeBSD.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 19:35:22 -0000 --4SFOXa2GPu3tIq4H Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 15, 2013 at 10:18:15PM +0300, Konstantin Belousov wrote: > On Mon, Apr 15, 2013 at 08:42:03PM +0200, Pawel Jakub Dawidek wrote: > > On a mostly unrelated note when two threads (T0 and T1) call get*time() > > on two different cores, but T0 does that a bit earlier is it possible > > that T0 can get later time than T1? >=20 > Define earlier first. >=20 > If you have taken sufficient measures to prevent preemption and interrupt= ion, > e.g. by entering spinlock before the fragment that calls get*, then no, > it is impossible, at least not with any x86 timekeeping hardware we use. >=20 > On the other hand, if interrupts are allowed, all bets are off. So if we consider only one thread, it is not possible for it to obtain time t0, be scheduled to different CPU and obtain t1 where t1 < t0? --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com --4SFOXa2GPu3tIq4H Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlFsVvoACgkQForvXbEpPzQzzQCeOMrSkgTMbYMjl8If37USSBdT c7wAn1w8SL3vUVYHUMHseuDWom7+klgb =/CA5 -----END PGP SIGNATURE----- --4SFOXa2GPu3tIq4H-- From owner-freebsd-geom@FreeBSD.ORG Mon Apr 15 19:39:17 2013 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 18DA7EC3; Mon, 15 Apr 2013 19:39:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 9DAD5164D; Mon, 15 Apr 2013 19:39:16 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r3FJdD1Y022713; Mon, 15 Apr 2013 22:39:13 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.2 kib.kiev.ua r3FJdD1Y022713 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r3FJdD2n022712; Mon, 15 Apr 2013 22:39:13 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 15 Apr 2013 22:39:12 +0300 From: Konstantin Belousov To: Pawel Jakub Dawidek Subject: Re: devstat overhead VS precision Message-ID: <20130415193912.GS2930@kib.kiev.ua> References: <51692C95.3010901@FreeBSD.org> <20130415184203.GA1839@garage.freebsd.pl> <20130415191815.GR2930@kib.kiev.ua> <20130415193730.GB1839@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qxmd2aOE9n9J83EO" Content-Disposition: inline In-Reply-To: <20130415193730.GB1839@garage.freebsd.pl> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-hackers@FreeBSD.org, Alexander Motin , freebsd-geom@FreeBSD.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 19:39:17 -0000 --qxmd2aOE9n9J83EO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 15, 2013 at 09:37:30PM +0200, Pawel Jakub Dawidek wrote: > On Mon, Apr 15, 2013 at 10:18:15PM +0300, Konstantin Belousov wrote: > > On Mon, Apr 15, 2013 at 08:42:03PM +0200, Pawel Jakub Dawidek wrote: > > > On a mostly unrelated note when two threads (T0 and T1) call get*time= () > > > on two different cores, but T0 does that a bit earlier is it possible > > > that T0 can get later time than T1? > >=20 > > Define earlier first. > >=20 > > If you have taken sufficient measures to prevent preemption and interru= ption, > > e.g. by entering spinlock before the fragment that calls get*, then no, > > it is impossible, at least not with any x86 timekeeping hardware we use. > >=20 > > On the other hand, if interrupts are allowed, all bets are off. >=20 > So if we consider only one thread, it is not possible for it to obtain > time t0, be scheduled to different CPU and obtain t1 where t1 < t0? Yes, I believe this scenario is also not possible. The context switching ensures that thread's view on the global memory is consistent. At least it is so on x86, and I think it must be the same on all other architectures. Otherwise the compiler emited code would not work. --qxmd2aOE9n9J83EO Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRbFdgAAoJEJDCuSvBvK1BHHwP/3jWyITU2jLV7rr4PL9byXPW 5It47gDGungmtlGIiPj7s5t9Apq4DvZ9G7kBNvR/1FjATVPbXa9TPvo6t8qqGrEm 7CIq72pt6B0BcxwBLD3cLDU6qQfm5hMu5VkJqKFGg/LpWzKkHOvGt2ostDEY5N79 WQldd1wJsRp25SsFChsb/z9RXBKIcCJvc3ukUxTQAblaIIoQ3dThUpVv+pN5/pl/ yj2URn44dQTJkNNQw4mUN72PHf66wFeYpw3I2U8Lr1LMdl/2PGuM4gbancjeGSp3 md7EoKrGll6/8lH58X4aVgHDjbqD7/ccDCn8yNok2FwaDSyiuUqUPyYTGIiCExgm Ni+71fyyL9wFd79n93ovC6LrqwaB8Lvn8fOydGp8ZPIRDRl0d+dEbhD8FUaaCaUk wl0TmhOZVarWJBstiOunWHlVeLkltcSdfV9X8gyp0ThFJZfM9nbgPdMdawRaIQ+v H1lWbXBhAFA+kwwM2zZSf1YiOvUGVbjf/Y0XSR6i6rSmhjJl2QA9BYX/Gr60I1Fg hQr9JlBsLOCZbqNX7f4KdjucVOjKLsdDyk10on4pGYIQXHCmNO28bhNiKxiqYMkP aYervPFifouuO9LvcGkQqD1XIJH4mQfSKLQtkTpKd44Sf1avoqHFu37SYp3+Fu51 eq5VSCa48ydDx69Wujek =KrTY -----END PGP SIGNATURE----- --qxmd2aOE9n9J83EO-- From owner-freebsd-geom@FreeBSD.ORG Mon Apr 15 20:43:15 2013 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id F3E1ABC1; Mon, 15 Apr 2013 20:43:14 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 825BA1AA1; Mon, 15 Apr 2013 20:43:14 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id EF36E89FBE; Mon, 15 Apr 2013 20:43:06 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.6/8.14.6) with ESMTP id r3FKh6bm038497; Mon, 15 Apr 2013 20:43:06 GMT (envelope-from phk@phk.freebsd.dk) To: Alexander Motin Subject: Re: devstat overhead VS precision In-reply-to: <516C515A.9090602@FreeBSD.org> From: "Poul-Henning Kamp" References: <51692C95.3010901@FreeBSD.org> <20130415184203.GA1839@garage.freebsd.pl> <516C515A.9090602@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 Date: Mon, 15 Apr 2013 20:43:06 +0000 Message-ID: <38496.1366058586@critter.freebsd.dk> Cc: freebsd-hackers@FreeBSD.org, Pawel Jakub Dawidek , freebsd-geom@FreeBSD.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 20:43:15 -0000 In message <516C515A.9090602@FreeBSD.org>, Alexander Motin writes: >>> I propose to switch that >>> statistics from using binuptime() to getbinuptime() to solve the problem >>> globally. >> No objections here, but I wonder if you were able to compare the results >> somehow before and after the change so we have some hard numbers to show >> that we don't lose much by applying the change. > >I haven't tested it statistically, but I haven't noticed any visual >difference in gstat output with its 0.1ms displayed resolution. I have tested it statistically, back when I wrote GEOM: It leads to very significant statistical bias. Just about the only thing in devstat that has any predictive power with respect to filesystem performance, is the latency, which measures how long time it takes to satisfy each I/O request. If you run gstat(8), this is the "ms/*" numbers: milliseconds per this or that. The rest of what's in devstat, with the exception of the queue-length ("L(q)") has almost no predictive power, and is IMO, practically pointless. In particular the %busy is totally misleading and I deeply regret that I didn't fight to kill it back then. If you switch to getbinuptime(), the latency measurements will only be precise if the I/O operations take much longer than the timecounter update period, which is not guaranteed to be 1000 Hz btw. For measuring how much USB-sticks suck, that will work fine. For tuning anything on a non-ridiculous SSD device or modern harddisks, it will be useless because of the bias you introduce is *not* one which averages out over many operations. The fundamental problem is that on a busy system, getbinuptime() does not get called at random times, it will be heavily affected by the I/O traffic, because of the interrupts, the bus-traffic itself, the cache-effects of I/O transfers and the context-switches by the processes causing the I/O. So yes, you can switch to getbinuptime(), but the only statistical responsible way to do so, would be to supress latency measurements on all I/O operations which complete in less than 5-10 timecounter interrupts. Apart from some practical issues implementing it, the numbers that came out would be pretty useless. The right idea is probably to bucketize the latencies, so that rather than having to keep track of devstat in real time to find out, you could get a histogram at any time showing past performance something like: Latency distribution: <5msec: 92.12 % <10msec: 0.17 % <20msec: 1.34 % <50msec: 6.37 % >50msec: 0.00 % Doing that with getbinuptime() would be statistically defensible provided the top bucket is "<5msec" and it would very clearly tell people if they have I/O trouble or not, which IMO is what people want to know. The cost 20 64bit counters in struct devstat (N|R|W|E)*5*8 = 160 bytes, but since devstat is already 288 bytes, that isn't a major catastropy. The ability to measure latency precisly should be retained, but it could be made a sysctl enabled debugging facility. The %busy crap should be killed, all it does is confuse people. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-geom@FreeBSD.ORG Mon Apr 15 21:31:46 2013 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7A15C728; Mon, 15 Apr 2013 21:31:46 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ea0-x231.google.com (mail-ea0-x231.google.com [IPv6:2a00:1450:4013:c01::231]) by mx1.freebsd.org (Postfix) with ESMTP id B26011C41; Mon, 15 Apr 2013 21:31:45 +0000 (UTC) Received: by mail-ea0-f177.google.com with SMTP id q14so2361957eaj.36 for ; Mon, 15 Apr 2013 14:31:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=BoWe5YrinTteFVc3UIVKwBJa1JITwjJq9jtj6xumihU=; b=KwA3cHtWWVKJ+weGpzCUC+TnXIlwAmN3qFJhQUzHubwX7r/xFwGxjdnvr02cqVkVxc DhI+FsQwQhJsF6Mzks4q2/UMRFkLmY4wHV6UkiqQv2mQsTN9If7fGzF0aMHfd2N7jo3w V42FUnFKj4o7qnB73GKc9ptA97wdPDlj9nZX45bzLAvZrCaXzOEqrucNQm64BuvYOXRs z7epN5WS3q4wUICOxkHvqhyqxdGdcfbEwhPbHbFCXtnvtRKa5gfR/c0GLcp8iXSIW0S/ rJ2ss6ZI9ZUmKBoFxNEckwKtG53QyO+Ev5O6Od+oP2AQsbl1UlL8RIUC22GQLyIDQTD4 hRaQ== X-Received: by 10.15.99.201 with SMTP id bl49mr66026891eeb.43.1366061504877; Mon, 15 Apr 2013 14:31:44 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id b47sm9445124eez.2.2013.04.15.14.31.42 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 15 Apr 2013 14:31:43 -0700 (PDT) Sender: Alexander Motin Message-ID: <516C71BC.4000902@FreeBSD.org> Date: Tue, 16 Apr 2013 00:31:40 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130413 Thunderbird/17.0.5 MIME-Version: 1.0 To: Poul-Henning Kamp Subject: Re: devstat overhead VS precision References: <51692C95.3010901@FreeBSD.org> <20130415184203.GA1839@garage.freebsd.pl> <516C515A.9090602@FreeBSD.org> <38496.1366058586@critter.freebsd.dk> In-Reply-To: <38496.1366058586@critter.freebsd.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, Pawel Jakub Dawidek , freebsd-geom@FreeBSD.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 21:31:46 -0000 On 15.04.2013 23:43, Poul-Henning Kamp wrote: > In message <516C515A.9090602@FreeBSD.org>, Alexander Motin writes: > >>>> I propose to switch that >>>> statistics from using binuptime() to getbinuptime() to solve the problem >>>> globally. > >>> No objections here, but I wonder if you were able to compare the results >>> somehow before and after the change so we have some hard numbers to show >>> that we don't lose much by applying the change. >> >> I haven't tested it statistically, but I haven't noticed any visual >> difference in gstat output with its 0.1ms displayed resolution. > > I have tested it statistically, back when I wrote GEOM: It leads > to very significant statistical bias. > > Just about the only thing in devstat that has any predictive power > with respect to filesystem performance, is the latency, which measures > how long time it takes to satisfy each I/O request. > > If you run gstat(8), this is the "ms/*" numbers: milliseconds per > this or that. > > The rest of what's in devstat, with the exception of the queue-length > ("L(q)") has almost no predictive power, and is IMO, practically > pointless. In particular the %busy is totally misleading and I > deeply regret that I didn't fight to kill it back then. > > If you switch to getbinuptime(), the latency measurements will only > be precise if the I/O operations take much longer than the timecounter > update period, which is not guaranteed to be 1000 Hz btw. > > For measuring how much USB-sticks suck, that will work fine. > > For tuning anything on a non-ridiculous SSD device or modern > harddisks, it will be useless because of the bias you introduce is > *not* one which averages out over many operations. Could you please explain why? Unless disk I/O somehow aliased to hardclock(), each of them should get random error from 0 to max(1ms, 1s/HZ). With large number of I/Os that error should be hidden when calculating average time. I am not talking about microseconds, but I think fraction of millisecond should be realistic to get. > The fundamental problem is that on a busy system, getbinuptime() > does not get called at random times, it will be heavily affected > by the I/O traffic, because of the interrupts, the bus-traffic > itself, the cache-effects of I/O transfers and the context-switches > by the processes causing the I/O. I'm sorry, but I am not sure I understand above paragraphs. Do you want to say that in some realistic conditions (not counting entering debugger with disabled interrupts, etc) hardclock() can be delayed more then some significant percent of its period and that depends of I/O traffic itself? Or you want to say that disk I/Os somehow aliased with hardclock(), making impossible to hide error by averaging? > So yes, you can switch to getbinuptime(), but the only statistical > responsible way to do so, would be to supress latency measurements > on all I/O operations which complete in less than 5-10 timecounter > interrupts. Sure, getbinuptime() won't allow to answer how many requests completed within 0.5ms, but present API doesn't allow to calculate that any way, providing only total/average times. And why "_5-10_ timecounter interrupts"? > Apart from some practical issues implementing it, the numbers > that came out would be pretty useless. > > The right idea is probably to bucketize the latencies, so that > rather than having to keep track of devstat in real time to find > out, you could get a histogram at any time showing past > performance something like: > > Latency distribution: > > <5msec: 92.12 % > <10msec: 0.17 % > <20msec: 1.34 % > <50msec: 6.37 % > >50msec: 0.00 % > > Doing that with getbinuptime() would be statistically defensible > provided the top bucket is "<5msec" and it would very clearly tell > people if they have I/O trouble or not, which IMO is what people > want to know. > > The cost 20 64bit counters in struct devstat (N|R|W|E)*5*8 = 160 > bytes, but since devstat is already 288 bytes, that isn't a major > catastropy. I agree that such functionality could be interesting. The only worry is which buckets should be there. For modern HDDs above buckets could be fine. For high-end SSD it may go about microseconds then milliseconds. I have doubt that 5 buckets will be universal enough, unless separated by factor of 5-10. > The ability to measure latency precisly should be retained, but it > could be made a sysctl enabled debugging facility. > > The %busy crap should be killed, all it does is confuse people. I agree that it heavily lies, especially for cached writes, but at least it allows to make some very basic estimates. The value has valid explanation and the only problem is that users are misinterpreting it. -- Alexander Motin From owner-freebsd-geom@FreeBSD.ORG Tue Apr 16 06:24:15 2013 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5B9E13BE; Tue, 16 Apr 2013 06:24:15 +0000 (UTC) (envelope-from phk@freebsd.org) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 244FCEF8; Tue, 16 Apr 2013 06:24:14 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id F205389FBE; Tue, 16 Apr 2013 06:24:13 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.6/8.14.6) with ESMTP id r3G6OD8N040153; Tue, 16 Apr 2013 06:24:13 GMT (envelope-from phk@freebsd.org) To: Alexander Motin Subject: Re: devstat overhead VS precision In-reply-to: <516C71BC.4000902@FreeBSD.org> From: "Poul-Henning Kamp" References: <51692C95.3010901@FreeBSD.org> <20130415184203.GA1839@garage.freebsd.pl> <516C515A.9090602@FreeBSD.org> <38496.1366058586@critter.freebsd.dk> <516C71BC.4000902@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 Date: Tue, 16 Apr 2013 06:24:13 +0000 Message-ID: <40152.1366093453@critter.freebsd.dk> Cc: freebsd-hackers@FreeBSD.org, Pawel Jakub Dawidek , freebsd-geom@FreeBSD.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 06:24:15 -0000 In message <516C71BC.4000902@FreeBSD.org>, Alexander Motin writes: >On 15.04.2013 23:43, Poul-Henning Kamp wrote: >> In message <516C515A.9090602@FreeBSD.org>, Alexander Motin writes: >> >> For tuning anything on a non-ridiculous SSD device or modern >> harddisks, it will be useless because of the bias you introduce is >> *not* one which averages out over many operations. > >Could you please explain why? > >> The fundamental problem is that on a busy system, getbinuptime() >> does not get called at random times, it will be heavily affected >> by the I/O traffic, because of the interrupts, the bus-traffic >> itself, the cache-effects of I/O transfers and the context-switches >> by the processes causing the I/O. > >I'm sorry, but I am not sure I understand above paragraphs. That was the exact explanation you asked for, and I'm not sure I can find a better way to explain it, but I'll try: Your assumption that the error will cancel out, implicitly assumes that the timestamp returned from getbinuptime() is updated at times which are totally independent from the I/O traffic you are trying to measure the latency of. That is not the case. The interrupt which updates getbinuptime()'s cached timestamp is affected a lot by the I/O traffic, for the various reasons I mention above. >Sure, getbinuptime() won't allow to answer how many requests completed >within 0.5ms, but present API doesn't allow to calculate that any way, >providing only total/average times. And why "_5-10_ timecounter interrupts"? A: Yes it actually does, a userland application running on a dedicated CPU core can poll the shared memory devstat structure at a very high rate and get very useful information about short latencies. Most people don't do that, becuase they don't care about the difference between 0.5 and 0.45 milliseconds. B: To get the systematic bias down to 10-20% of the measured interval. >> Latency distribution: >> >> <5msec: 92.12 % >> <10msec: 0.17 % >> <20msec: 1.34 % >> <50msec: 6.37 % >> >50msec: 0.00 % >> >I agree that such functionality could be interesting. The only worry is >which buckets should be there. For modern HDDs above buckets could be >fine. For high-end SSD it may go about microseconds then milliseconds. I >have doubt that 5 buckets will be universal enough, unless separated by >factor of 5-10. Remember what people use this for: Answering the question "Does my disk subsystem suck, and if so, how much" Buckets like the ones proposed will tell you that. >> The %busy crap should be killed, all it does is confuse people. > >I agree that it heavily lies, especially for cached writes, but at least >it allows to make some very basic estimates. For rotating disks: It always lies. For SSD: It almost always lies. Kill it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-geom@FreeBSD.ORG Tue Apr 16 22:44:49 2013 Return-Path: Delivered-To: geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 87ADB81D; Tue, 16 Apr 2013 22:44:49 +0000 (UTC) (envelope-from Cy.Schubert@komquats.com) Received: from smtp-out-02.shaw.ca (smtp-out-02.shaw.ca [64.59.136.138]) by mx1.freebsd.org (Postfix) with ESMTP id 497851CB7; Tue, 16 Apr 2013 22:44:49 +0000 (UTC) X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=3f4U5fHrZLLPCzJ96ldNbjtja1zQ0ih230F6vdsLr5s= c=1 sm=1 a=QrugwKR0C_UA:10 a=wAGQQ9Az6v0A:10 a=BLceEmwcHowA:10 a=ICAaq7hcmGcA:10 a=8nJEP1OIZ-IA:10 a=IbtKDeXwb2+SRU442/pi3A==:17 a=vaJtXVxTAAAA:8 a=BWvPGDcYAAAA:8 a=6I5d2MoRAAAA:8 a=sq_fSE3xARbxezGG6UEA:9 a=wPNLvfGTeEIA:10 a=V7tsTZBp22UA:10 a=SV7veod9ZcQA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Received: from unknown (HELO spqr.komquats.com) ([96.50.7.119]) by smtp-out-02.shaw.ca with ESMTP; 16 Apr 2013 16:45:46 -0600 Received: from slippy.cwsent.com (slippy8 [10.2.2.6]) by spqr.komquats.com (Postfix) with ESMTP id A0D3580; Tue, 16 Apr 2013 15:44:46 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.14.6/8.14.6) with ESMTP id r3GMiiNc004099; Tue, 16 Apr 2013 15:44:45 -0700 (PDT) (envelope-from Cy.Schubert@komquats.com) Message-Id: <201304162244.r3GMiiNc004099@slippy.cwsent.com> X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.5 From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.komquats.com/ To: "Ilya A. Arkhipov" Subject: Re: Stack Overflow in GEOM In-Reply-To: Message from "Ilya A. Arkhipov" of "Tue, 16 Apr 2013 22:01:16 +0400." <1257671366135276@web6f.yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Apr 2013 15:44:44 -0700 Cc: geom@freebsd.org, current@freebsd.org, ivoras@freebsd.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Cy Schubert List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 22:44:49 -0000 In message <1257671366135276=40web6f.yandex.ru>, =22Ilya A. Arkhipov=22 w= rites: > 16.04.2013, 21:56, =22Cy Schubert=22 : > > Has anyone see this before? Just updated my CURRENT partitions on my > > testbed and laptop. The laptop just boots but I've managed to capture= this > > on my testbed (attached to a serial port on another system). > > > > This is HEAD from yesterday (Apr 15) morning (PDT). The partition bei= ng > > booted is ada0s1d. On my laptop it's ada0s3a. KSTACK_PAGES is 4. Is t= here a > > way to quickly display that kern.kstack_pages from DDB? > > > > ada0 at ata0 bus 0 scbus0 target 0 lun 0 > > ada0: ATA-7 device > > ada0: 100.000MB/s transfers (UDMA5, PIO 8192bytes) > > ada0: 76351MB (156368016 512 byte sectors: 16H 63S/T 16383C) > > ada0: Previously was known as ad0 > > ada1 at ata0 bus 0 scbus0 target 1 lun 0 > > ada1: ATA-7 device > > ada1: 133.000MB/s transfers (UDMA6, PIO 8192bytes) > > ada1: 117246MB (240121728 512 byte sectors: 16H 63S/T 16383C) > > ada1: Previously was known as ad1 > > ada2 at ata2 bus 0 scbus2 target 0 lun 0 > > ada2: ATA-8 SATA 2.x device > > ada2: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes) > > ada2: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) > > ada2: Previously was known as ad4 > > ada3 at ata3 bus 0 scbus3 target 0 lun 0 > > ada3: ATA-7 SATA 2.x device > > ada3: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes) > > ada3: 305245MB (625142448 512 byte sectors: 16H 63S/T 16383C) > > ada3: Previously was known as ad6 > > SMP: AP CPU =231 Launched=21 > > panic: stack overflow detected; backtrace may be corrupted > > cpuid =3D 1 > > KDB: enter: panic > > =5B thread pid 13 tid 100009 =5D > > Stopped at =9A=9A=9A=9A=9Akdb_enter+0x3d: movl =9A=9A=9A=240,kdb_why > > db> bt > > Tracing pid 13 tid 100009 td 0x872d6000 > > kdb_enter(80ca7886,80ca7886,80ca9523,86edcae0,1,...) at > > kdb_enter+0x3d/frame 0x86edca98 > > panic(80ca9523,86edcb70,80713dd2,86edcbd8,86edcafc,...) at > > panic+0x141/frame 0x86edcad4 > > __stack_chk_init(86edcbd8,86edcafc,86edcaf8,86edcafc,64,...) at > > __stack_chk_init/frame 0x86edcae0 > > g_label_disk_ident_taste(87b7dc80,86edcbd8,80,0,0,...) at > > g_label_disk_ident_taste+0x102/frame 0x86edcb70 > > g_label_taste(80d26b88,872ff500,0,872ff480,872d6000,...) at > > g_label_taste+0x3ca/frame 0x86edcc6c > > g_new_provider_event(872ff500,0,25c,80c9798e,0,...) at > > g_new_provider_event+0xb1/frame 0x86edcc88 > > g_run_events(0,86edcd08,222db60d,83725616,b10094f2,...) at > > g_run_events+0x19f/frame 0x86edccc4 > > fork_exit(8070d140,0,86edcd08) at fork_exit+0xa3/frame 0x86edccf4 > > fork_trampoline() at fork_trampoline+0x8/frame 0x86edccf4 > > --- trap 0, eip =3D 0, esp =3D 0x86edcd40, ebp =3D 0 --- > > db> > > > > I've been poking at this off and on last night. Any ideas? > > > > -- > > Cheers, > > Cy Schubert > > FreeBSD UNIX: =9A =9A=9AWeb: =9Ahttp://www.FreeBSD.= org > > > > _______________________________________________ > > freebsd-current=40freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to =22freebsd-current-unsubscribe=40fre= ebsd.org=22 >=20 > Hi, >=20 > It should be related with: http://docs.freebsd.org/cgi/getmsg.cgi?fetch= =3D30160 > 3+0+current/svn-src-head >=20 > Author: ivoras > Date: Mon Apr 15 16:09:24 2013 > New Revision: 249508 > URL: http://svnweb.freebsd.org/changeset/base/249508 >=20 > Log: > Introduce glabel labels based on GEOM ident attributes. In this initi= al > implementation, error on the side of conservatism and only create lab= els > for GEOMs of classes DISK and MULTIPATH. >=20 > Discussed with: trasz > Approved by: silence from freebsd-geom=40 You were correct. Backing out r249508 in my tree resolves the panic on bo= th=20 hosts. --=20 Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org From owner-freebsd-geom@FreeBSD.ORG Tue Apr 16 23:02:41 2013 Return-Path: Delivered-To: geom@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E0CC0C1B; Tue, 16 Apr 2013 23:02:41 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-ve0-f179.google.com (mail-ve0-f179.google.com [209.85.128.179]) by mx1.freebsd.org (Postfix) with ESMTP id 914E11D53; Tue, 16 Apr 2013 23:02:41 +0000 (UTC) Received: by mail-ve0-f179.google.com with SMTP id oz10so950176veb.10 for ; Tue, 16 Apr 2013 16:02:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=8HaVuAmCmwXbwfbZyGW8e1cP4dCdthnwrStxm65jDsA=; b=X4c2/v+Ko1+3O98ea0VUmfad+rw/+v8Rl6I5Fbix0OUg2T3AlGKdkzVL6IW3jnqfNk HIAZpm+fK/iljvBEkxJO7/zvp6s3EkaiNCSypcJfOdfM+i4deWzW7TJOXka0Qoe179od Clg8CklEyDmcLwXzvw9nR6GimSd3Y2GTdxOF3ewyeI22ANdUgERWvdSTY7tuVCs+FaOu 6Hgrv1LfQLffezQ5dEL26P76yunOiHT6UBj8QFy343A4EwiwRBW+rhgi+vs90tx/2c24 Uyi0qcLk90Jgm46RJOX6XkSo+ehnShrSScgIKnYDiMkF4F8J3vjYs2NfWVg9GBBmB0ru WneQ== X-Received: by 10.52.99.67 with SMTP id eo3mr2709367vdb.21.1366153355385; Tue, 16 Apr 2013 16:02:35 -0700 (PDT) MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.58.34.162 with HTTP; Tue, 16 Apr 2013 16:01:55 -0700 (PDT) In-Reply-To: <201304162244.r3GMiiNc004099@slippy.cwsent.com> References: <1257671366135276@web6f.yandex.ru> <201304162244.r3GMiiNc004099@slippy.cwsent.com> From: Ivan Voras Date: Wed, 17 Apr 2013 01:01:55 +0200 X-Google-Sender-Auth: swoaGJ_yorVsAmQ0TLeQf1EYCY4 Message-ID: Subject: Re: Stack Overflow in GEOM To: Cy Schubert Content-Type: text/plain; charset=UTF-8 Cc: geom@freebsd.org, "Ilya A. Arkhipov" , current@freebsd.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 23:02:41 -0000 On 17 April 2013 00:44, Cy Schubert wrote: > You were correct. Backing out r249508 in my tree resolves the panic on both > hosts. Hi, Sorry about that - should be fixed by http://svnweb.freebsd.org/base?view=revision&revision=249564 . From owner-freebsd-geom@FreeBSD.ORG Wed Apr 17 00:16:10 2013 Return-Path: Delivered-To: geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 107FD8C1; Wed, 17 Apr 2013 00:16:10 +0000 (UTC) (envelope-from Cy.Schubert@komquats.com) Received: from smtp-out-05.shaw.ca (smtp-out-05.shaw.ca [64.59.134.13]) by mx1.freebsd.org (Postfix) with ESMTP id BD6071F7F; Wed, 17 Apr 2013 00:16:09 +0000 (UTC) X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=7/EMZfWbaVtDMdTqnk9efwidrOfQb3DZMdpNhNw5Oc4= c=1 sm=1 a=QrugwKR0C_UA:10 a=wAGQQ9Az6v0A:10 a=BLceEmwcHowA:10 a=ICAaq7hcmGcA:10 a=kj9zAlcOel0A:10 a=IbtKDeXwb2+SRU442/pi3A==:17 a=BWvPGDcYAAAA:8 a=6I5d2MoRAAAA:8 a=i5LUQIlrN4e3-3zU_18A:9 a=CjuIK1q_8ugA:10 a=V7tsTZBp22UA:10 a=SV7veod9ZcQA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Received: from unknown (HELO spqr.komquats.com) ([96.50.7.119]) by smtp-out-05.shaw.ca with ESMTP; 16 Apr 2013 18:16:53 -0600 Received: from slippy.cwsent.com (slippy8 [10.2.2.6]) by spqr.komquats.com (Postfix) with ESMTP id 99CD480; Tue, 16 Apr 2013 17:16:02 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.14.6/8.14.6) with ESMTP id r3H0G2PN002625; Tue, 16 Apr 2013 17:16:02 -0700 (PDT) (envelope-from Cy.Schubert@komquats.com) Message-Id: <201304170016.r3H0G2PN002625@slippy.cwsent.com> X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.5 From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.komquats.com/ To: Ivan Voras Subject: Re: Stack Overflow in GEOM In-Reply-To: Message from Ivan Voras of "Wed, 17 Apr 2013 01:01:55 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 16 Apr 2013 17:16:02 -0700 Cc: Cy Schubert , geom@freebsd.org, "Ilya A. Arkhipov" , current@freebsd.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Cy Schubert List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 00:16:10 -0000 In message , Ivan Voras writes: > On 17 April 2013 00:44, Cy Schubert wrote: > > > You were correct. Backing out r249508 in my tree resolves the panic on both > > hosts. > > Hi, > > Sorry about that - should be fixed by > http://svnweb.freebsd.org/base?view=revision&revision=249564 . > hey, no prob. Fetching it now. Thanks. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org From owner-freebsd-geom@FreeBSD.ORG Thu Apr 18 06:24:45 2013 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E392092C for ; Thu, 18 Apr 2013 06:24:45 +0000 (UTC) (envelope-from healthclubprosperitytips61@yahoo.com) Received: from nm9-vm4.bullet.mail.ne1.yahoo.com (nm9-vm4.bullet.mail.ne1.yahoo.com [98.138.91.169]) by mx1.freebsd.org (Postfix) with ESMTP id B6216DBC for ; Thu, 18 Apr 2013 06:24:45 +0000 (UTC) Received: from [98.138.90.52] by nm9.bullet.mail.ne1.yahoo.com with NNFMP; 18 Apr 2013 06:22:59 -0000 Received: from [98.138.226.133] by tm5.bullet.mail.ne1.yahoo.com with NNFMP; 18 Apr 2013 06:22:59 -0000 Received: from [127.0.0.1] by smtp220.mail.ne1.yahoo.com with NNFMP; 18 Apr 2013 06:22:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1366266179; bh=qeb+34G13cCfNmhMEmkA4i1EBWd71thv4Vv67XGj4/E=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Return-Path:MIME-Version:From:Reply-To:To:Subject:Content-Type:Content-Transfer-Encoding:X-Mailer:Date:Message-ID; b=s0Vm595EGvXK7Tt2+vXQjmMjm2MrhUFZKDJnzPwRHigUVpQbYeZtNFpn6nxKPjAK/mcMus9e8V1aVHaU51zRNH0iJqLHtOj3oS+SA8dcJbZSUvIFZXiEIvRmAweFDZ5849v2hV6ECtE4ughPwowMTMggTCd5yffgk3CaO9w7I10= X-Yahoo-Newman-Id: 345405.6943.bm@smtp220.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: zqxt2M0VM1lgeU3v7fnJYKWyqFWTl6rvJltatGdKJRD7pYs wbgjCFBNPP8nm9fD1SsILyVbtAQMfMq.TLBsXZmSb02XkB820IEJRUytLgrH _Cr3E0I08VQCxILS6a0mXDnKorHhRIXm2KJnxUlyP50KlRybB70FVwch4PJl _TZkyvKmzqc4OYCD9O.2WpRF3Krjvz5x1G9aTUxlv8ICfMSIfkVbQpIMMDS3 _9w3vN7xxdV90ATgOzN5.NYDGtTZRsWEbJogzLDIVXYcrswDgJgDPN5l..qo fwNVTQj.u.NaZ7UlFhmZhca2PMuK3VcNn_VCffZqBe31aaWODcrqvj6N.0Pw MhAqdd6gqq7Z6GMJoQoW3Lf.d2tPo2E5ngpwAlraVJcAQNeAPV9wFYAgu5ii lFdr1sBJwtsV5ufxF029DcIrKa79Tm5wzrc5S0foMudpeFRaTljYN0H8OO9. DDfuAMW28vIkodtvfxvOSu5vsm933Ibc.J8VELMvfEqAfgXIchu2lZnXeYFM hNfSZ5YWcAA3mTLo- X-Yahoo-SMTP: WKO.P2qswBAQigtSgMiUBNMPY4s_Yv9IH1A8yneiyIQ_5gJCzK0. X-Rocket-Received: from 50.117.80.165 (healthclubprosperitytips61@74.115.0.205 with login) by smtp220.mail.ne1.yahoo.com with SMTP; 17 Apr 2013 23:22:59 -0700 PDT From: "healthclubprosperitytips61" To: freebsd-geom@freebsd.org Subject: Health Club Business Tips X-Mailer: Smart_Send_2_0_138 Date: Thu, 18 Apr 2013 14:22:56 +0800 Message-ID: <1722313413441741824543@CHERRY-PC> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252" X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: healthclubprosperitytips61@yahoo.com List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 06:24:46 -0000 [1]www.healthclubrev.com HEALTH CLUB MARKETING TIP OF THE MONTH: ATTENTION, INTEREST, DESIRE AND ACTION (AIDA) ATTENTION: This is best accomplished with an offer the consumer has never seen before. INTEREST: Focus on the emotional hook in your health club marketing campaign that will create interest and make the consumer want to buy your health club products and your health club services. DESIRE: Consumers buy health club products and health club services for emotional reasons not logical reasons. ACTION: Make sure your health club marketing has a definitive call to action as to why the consumer must take action today. Click on the link below to learn about MMC®'s CASH promotion and how we have raised $250,000 in immediate cash and added more than 500 new members, in just 45 days for numerous Health Clubs. [2]http://www.healthclubrev.com/CASH_PROMOTION.html MMC®'s site has free videos on how to increase revenue (immediate cash, monthly receivables and member retention), capture the difficult to reach market, engage the de-conditioned and the health and fitness conscience prospect, increase revenue in your profit centers e.g. pro-shop, food and beverage, guest fees, personal training and so much more, absolutely free. "I would like to express my appreciation to MMC and all the staff. As a Health Club owner for twenty years, and operating one of the largest Gold's Gym, I did have some initial reservations regarding your Company and the amount of revenue that you indicated were possible with your promotion. I am happy to say that the promotion was a great success and also that the revenues you predicted were very accurate. We were able to add an additional 1200 plus members in a short time. Impact upon the current members was very minimal." Gold's Gym and Racquet club Randy Musloki Owner "The MMC program not only assisted with putting cash in hand but also afforded our staff new insight into sales and membership techniques that will be useful well past the end of the program." Yorktown Racquet, Fitness and Sport Complex Joseph D. Glitz Owner/President Dear Chuck, We have seven hundred (700) new members, money in the bank and a staff that can't wait until the next promotion. I just wanted to take a moment to personally thank you and let you know just how satisfied we were with MMC and you. North Shore Athletic Club JoAnn C. Ribaudo Owner Dear Chuck, I wanted to write you and let you know how satisfied we were with you and Mulligan Marketing. What great couple of months it has been at the club. Now only did your company deliver a "turn-key" promotion, the entire campaign was run with little or no effort on my part, which allowed me to concentrate on my day to day business of running the club. The promotion raised almost $400,000, nearly twice what we projected. In addition, not only did your on-site training have an immediate impact on my sales staff, the techniques you taught them and the materials that you distributed will benefit them for the long term. Your professionalism and enthusiasm throughout the campaign has truly made it a pleasurable experience. It is refreshing to work with someone as honest as you who truly deliver results. The Auburn Club Jennifer Nabbo Wishing you good health and prosperity, Chuck Thompson Founder/President MMC® 904-307-6736 Cell 904-448-5727 Office 877-620-8135 Toll Free If you wish not to receive these free tips on growing your health club and your health and fitness career, simply click on the unsubscribe button below to be taken off our list. [3][Unsubscribe] Notice: It is not our intention to "spam" any person or company. We have received your email through a legitimate avenue. We have been in business for more than 20 plus years and have collected opt-in emails from all of our internal resources i.e. employees, sales consultants, co-op marketing partners, etc. We have never done e-marketing over the past twenty plus years because we never offered anything of value on our site (with the exception of product information), until now. We are simply making an attempt to connect and re-connect with our clients, prospects and associates of past and present and make them aware of our new educational site and domain. We do realize some of you may have forgotten us or don't remember (or know) how we received your email (as we can't remember every email either) and for that we apologize in advance. Please be patient with us. If you do not wish to receive further communication from us please reply with the word "REMOVE" or "UNSUBSCRIBE" in the subject field and we will make every effort to eliminate you from all of our data bases immediately. Also, please make sure you reply from the original e-mail address this message was addressed to, or, include that address in the removal request. Please excuse any inconvenience. References 1. http://www.healthclubrev.com/ 2. http://www.healthclubrev.com/CASH_PROMOTION.html 3. mailto:?subject=Unsubscribe