From owner-freebsd-geom@FreeBSD.ORG Mon Aug 1 11:07:07 2011 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4A4C106566B for ; Mon, 1 Aug 2011 11:07:07 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B350C8FC13 for ; Mon, 1 Aug 2011 11:07:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p71B77r2014567 for ; Mon, 1 Aug 2011 11:07:07 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p71B77bJ014565 for freebsd-geom@FreeBSD.org; Mon, 1 Aug 2011 11:07:07 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 1 Aug 2011 11:07:07 GMT Message-Id: <201108011107.p71B77bJ014565@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 Cc: Subject: Current problem reports assigned to freebsd-geom@FreeBSD.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 11:07:07 -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/159091 geom [geom] GEOM fails to scan nested partitions to create 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] ABI change without version bump in 8.2 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/144905 geom [geom][geom_part] panic in gpart_ctlreq when unpluggin 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/134922 geom [gmirror] [panic] kernel panic when use fdisk on disk 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 f kern/128276 geom [gmirror] machine lock up when gmirror module is used 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/114532 geom [geom] GEOM_MIRROR shows up in kldstat even if compile f kern/113957 geom [gmirror] gmirror is intermittently reporting a degrad 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. 61 problems total. From owner-freebsd-geom@FreeBSD.ORG Wed Aug 3 12:59:17 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2EEAF106564A for ; Wed, 3 Aug 2011 12:59:17 +0000 (UTC) (envelope-from stephane.lapie@darkbsd.org) Received: from quasar.darkbsd.org (shinigami.darkbsd.org [82.227.96.182]) by mx1.freebsd.org (Postfix) with ESMTP id BCD688FC0C for ; Wed, 3 Aug 2011 12:59:16 +0000 (UTC) Received: from quasar.darkbsd.org (localhost [127.0.0.1]) by quasar.darkbsd.org (Postfix) with ESMTP id DE8646F2E for ; Wed, 3 Aug 2011 14:43:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=darkbsd.org; h=message-id :date:from:mime-version:to:subject:content-type; s=selector1; bh=0OVnKtlLDikOmSEBq5MFo9jl7ws=; b=P4T6ddKcORpTFdlIE4JaHlBgz1be OxQOcQYejPIQgfOzn/9NWNbVtuxk0O706AxWFBSVoVM5OgXadNvF/+e5bgHFjolm P2TptERN8PQ2tUumODOTq0q03joZsqEFLsWelP/WY2ctnHaFsCfG6pIobpmEzKrw 2uHbhcQe2av3uQA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=darkbsd.org; h=message-id :date:from:mime-version:to:subject:content-type; q=dns; s= selector1; b=kWPh30bGGyJSh4AN8hxm7dKS7aGIahbtnicaCSDEGKjXRi++fhh mXXZrtgJbzBpkO5+Q0oSv8Vc7ZyN+tff+wB6io0RzQjqjWvYCxc6JfSQB5bMBMfX eVxvdNSsP4z1s5YpNKxnjuQ6425zxoMkGBeB1Wm0Gb3fzX2slxO4SdjY= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=darkbsd.org; h= content-type:content-type:subject:subject:mime-version :user-agent:from:from:date:date:message-id:received:received; s= selector1; t=1312375411; bh=/rdeODrwSqgmzJe2eWspmwCxkdYgnOW0xOZA Rpvq/Ww=; b=eIHn7xQEnWFHXcJx0fCE2mgNsf9FsCDrtyoPfcp084hMQBIMCFuW QWZGnsq2gIEkfu1PjLhl3XPD1Jxx6bd4MBASXr10Xq/2U9Rr1eeq+jXNfAnNpEe4 +M9qTzN+vbdiMlSsQOpc6k4glOiHYodeZbT5WXlwDq2fu/afI5maVdo= Received: from quasar.darkbsd.org ([127.0.0.1]) by quasar.darkbsd.org (quasar.darkbsd.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id hg0yk4yQc2Gc for ; Wed, 3 Aug 2011 14:43:31 +0200 (CEST) Received: from [192.168.166.168] (unknown [210.188.173.246]) (Authenticated sender: darksoul) by quasar.darkbsd.org (Postfix) with ESMTPSA id BB65E6F27 for ; Wed, 3 Aug 2011 14:43:30 +0200 (CEST) Message-ID: <4E394269.3090208@darkbsd.org> Date: Wed, 03 Aug 2011 21:43:21 +0900 From: Stephane LAPIE User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-geom@freebsd.org X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0ECBDA10BF951DFFC811471E" Subject: Poor interaction between gmultipath(8), ZFS and isp(4) X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 12:59:17 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0ECBDA10BF951DFFC811471E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello list, (Not 100% sure the bug is in GEOM_MULTIPATH or in another driver.) I am running a FreeBSD 8.2-RELEASE server with ZFSv15, with the following hardware : http://www.darkbsd.org/~darksoul/server_dmesg.txt I have a dual fibre-channel controller (isp(4) driver), and I am accessing 16 RAID0 logical drives on a Promise vTrak E630fD (1 volume / physical disk) Since both controllers are plugged to the same storage unit with no LUN masking, both controllers end up seeing the same devices. Which is what made me combine these devices using geom_multipath. Here is my zpool structure : config: NAME STATE READ WRITE CKSUM data ONLINE 0 0 0 raidz1 ONLINE 0 0 0 multipath/disk0 ONLINE 0 0 0 multipath/disk1 ONLINE 0 0 0 multipath/disk2 ONLINE 0 0 0 multipath/disk3 ONLINE 0 0 0 multipath/disk4 ONLINE 0 0 0 multipath/disk5 ONLINE 0 0 0 multipath/disk6 ONLINE 0 0 0 multipath/disk7 ONLINE 0 0 0 raidz1 ONLINE 0 0 0 multipath/disk8 ONLINE 0 0 0 multipath/disk9 ONLINE 0 0 0 multipath/disk10 ONLINE 0 0 0 multipath/disk11 ONLINE 0 0 0 multipath/disk12 ONLINE 0 0 0 multipath/disk13 ONLINE 0 0 0 multipath/disk14 ONLINE 0 0 0 multipath/disk15 ONLINE 0 0 0 errors: No known data errors Using gmultipath, I eventually want to have disk{1,3,5,7,9,11,13,15} use the second controller, while the rest uses the first. The idea was that if anyone removed the fiber, it would switch everything over to the remaining fiber. For the sake of testing, I put every multipath device on the same controller, isp1. Here is the kernel log fragment I could acquire from my test (removing a fiber on which transfers are actively running), however since I don't have serial console access, I couldn't acquire the relevant kernel panic trace (it simply mentions a kernel trap during a page fault in g_mp_kt in the last readable section displayed, but I reckon it's like every CPU raises the panic message) http://www.darkbsd.org/~darksoul/server_lastlog_before_kernelpanic.txt After that, I get the aforementioned kernel panic. I can consistently reproduce it, and will try to acquire serial console output to get more detailed kernel panic trace, but it feels like everything is occuring at the same time without proper locking, or confirming relevant structures are still allocated. This looks like a race condition between isp(4) loopdown provoking da(4) destruction, and gmultipath(8) failover. (Therefore having g_mp_kt accessing a da(4) structure that is being destroyed, or already destroyed, and accessing unallocated memory) Maybe this is similar to this issue : http://freebsd.1045724.n5.nabble.com/Kernel-panic-with-gmultipath-td42047= 00.html Could this be tuned so that : 1) initially, on isp(4) loopdown -> da(4) devices depending on it return SCSI errors, provoking clean failover of gmultipath 2) afterwards, on isp(4) timeout -> da(4) devices are destroyed Is this a case for using the following boot hints ? - "hint.isp.0.loop_down_limit" and "hint.isp.0.gone_device_time" (though I am not quite sure what the difference is between the two ... Which one does the actual deallocation of underlying devices ?) Thanks in advance for your time, --=20 Stephane LAPIE, EPITA SRS, Promo 2005 "Even when they have digital readouts, I can't understand them." --MegaTokyo --------------enig0ECBDA10BF951DFFC811471E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk45QmoACgkQ24Ql8u6TF2NSHACeNHa2ug7j6x8GqobfuVdcskox /EQAoM+YGH7HhcuA+Bpo9rc70Uhz76Q/ =F/5b -----END PGP SIGNATURE----- --------------enig0ECBDA10BF951DFFC811471E-- From owner-freebsd-geom@FreeBSD.ORG Wed Aug 3 14:43:27 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9DFBE106564A for ; Wed, 3 Aug 2011 14:43:27 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id 6A83D8FC15 for ; Wed, 3 Aug 2011 14:43:27 +0000 (UTC) Received: from [192.168.135.105] (c-24-7-47-62.hsd1.ca.comcast.net [24.7.47.62]) (authenticated bits=0) by ns1.feral.com (8.14.4/8.14.4) with ESMTP id p73EEYY0010431 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 3 Aug 2011 07:14:35 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4E3957C6.1000406@feral.com> Date: Wed, 03 Aug 2011 07:14:30 -0700 From: Matthew Jacob Organization: Feral Software User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: freebsd-geom@freebsd.org References: <4E394269.3090208@darkbsd.org> In-Reply-To: <4E394269.3090208@darkbsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (ns1.feral.com [192.67.166.1]); Wed, 03 Aug 2011 07:14:35 -0700 (PDT) Subject: Re: Poor interaction between gmultipath(8), ZFS and isp(4) X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 14:43:27 -0000 Known problem. Or rather, one of a long set of known problems. Most of these were addressed at Panasas under RELENG_7, but I have not had the time to redo them for RELENG_8 and later. Nor was I really happy with a lot of the results. At least from my perspective, due to work commitments, I'm unlikely to get to this very soon. Regrets. On 8/3/2011 5:43 AM, Stephane LAPIE wrote: > Hello list, > > (Not 100% sure the bug is in GEOM_MULTIPATH or in another driver.) > > I am running a FreeBSD 8.2-RELEASE server with ZFSv15, with the > following hardware : > > http://www.darkbsd.org/~darksoul/server_dmesg.txt > > I have a dual fibre-channel controller (isp(4) driver), and I am > accessing 16 RAID0 logical drives on a Promise vTrak E630fD (1 volume / > physical disk) > > Since both controllers are plugged to the same storage unit with no LUN > masking, both controllers end up seeing the same devices. Which is what > made me combine these devices using geom_multipath. > > Here is my zpool structure : > config: > > NAME STATE READ WRITE CKSUM > data ONLINE 0 0 0 > raidz1 ONLINE 0 0 0 > multipath/disk0 ONLINE 0 0 0 > multipath/disk1 ONLINE 0 0 0 > multipath/disk2 ONLINE 0 0 0 > multipath/disk3 ONLINE 0 0 0 > multipath/disk4 ONLINE 0 0 0 > multipath/disk5 ONLINE 0 0 0 > multipath/disk6 ONLINE 0 0 0 > multipath/disk7 ONLINE 0 0 0 > raidz1 ONLINE 0 0 0 > multipath/disk8 ONLINE 0 0 0 > multipath/disk9 ONLINE 0 0 0 > multipath/disk10 ONLINE 0 0 0 > multipath/disk11 ONLINE 0 0 0 > multipath/disk12 ONLINE 0 0 0 > multipath/disk13 ONLINE 0 0 0 > multipath/disk14 ONLINE 0 0 0 > multipath/disk15 ONLINE 0 0 0 > > errors: No known data errors > > > Using gmultipath, I eventually want to have disk{1,3,5,7,9,11,13,15} use > the second controller, while the rest uses the first. The idea was that > if anyone removed the fiber, it would switch everything over to the > remaining fiber. > > For the sake of testing, I put every multipath device on the same > controller, isp1. > > Here is the kernel log fragment I could acquire from my test (removing a > fiber on which transfers are actively running), however since I don't > have serial console access, I couldn't acquire the relevant kernel panic > trace (it simply mentions a kernel trap during a page fault in g_mp_kt > in the last readable section displayed, but I reckon it's like every CPU > raises the panic message) > > http://www.darkbsd.org/~darksoul/server_lastlog_before_kernelpanic.txt > > After that, I get the aforementioned kernel panic. I can consistently > reproduce it, and will try to acquire serial console output to get more > detailed kernel panic trace, but it feels like everything is occuring at > the same time without proper locking, or confirming relevant structures > are still allocated. This looks like a race condition between isp(4) > loopdown provoking da(4) destruction, and gmultipath(8) failover. > (Therefore having g_mp_kt accessing a da(4) structure that is being > destroyed, or already destroyed, and accessing unallocated memory) > > Maybe this is similar to this issue : > http://freebsd.1045724.n5.nabble.com/Kernel-panic-with-gmultipath-td4204700.html > > > Could this be tuned so that : > 1) initially, on isp(4) loopdown -> da(4) devices depending on it return > SCSI errors, provoking clean failover of gmultipath > 2) afterwards, on isp(4) timeout -> da(4) devices are destroyed > > Is this a case for using the following boot hints ? > - "hint.isp.0.loop_down_limit" and "hint.isp.0.gone_device_time" (though > I am not quite sure what the difference is between the two ... Which one > does the actual deallocation of underlying devices ?) > > Thanks in advance for your time, From owner-freebsd-geom@FreeBSD.ORG Thu Aug 4 10:17:11 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8FC58106564A for ; Thu, 4 Aug 2011 10:17:11 +0000 (UTC) (envelope-from dmitry.zamaruyev@zoral.com.ua) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 050468FC08 for ; Thu, 4 Aug 2011 10:17:10 +0000 (UTC) Received: from ghost.kharkov.zoral.com.ua ([10.3.1.250]) (authenticated bits=0) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p74A0LAE004927 for ; Thu, 4 Aug 2011 13:00:21 +0300 (EEST) (envelope-from dmitry.zamaruyev@zoral.com.ua) Date: Thu, 4 Aug 2011 13:00:14 +0300 From: Dmitry Zamaruyev To: freebsd-geom@freebsd.org Message-ID: <20110804130014.0df63364@ghost.kharkov.zoral.com.ua> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-102.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS,USER_IN_WHITELIST autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Subject: SSD and gmirror X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 10:17:11 -0000 Hello list, I'm looking for clarification regarding gmirror/geom behavior in current 8-STABLE. I want to use couple of SSD drives in mirror RAID configuration with UFS on top. I know that UFS now supports TRIM (BIO_DELETE) on plain disks. But will gmirror propagate BIO_DELETE event to lower driver, so both SSDs will get trimmed when UFS issue this command? -- Best regards, Dmitry Zamaruev From owner-freebsd-geom@FreeBSD.ORG Thu Aug 4 10:44:09 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F01E0106566B for ; Thu, 4 Aug 2011 10:44:09 +0000 (UTC) (envelope-from prvs=11971cf4bd=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 767B08FC08 for ; Thu, 4 Aug 2011 10:44:09 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Thu, 04 Aug 2011 11:32:24 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Thu, 04 Aug 2011 11:32:24 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50014462984.msg for ; Thu, 04 Aug 2011 11:32:24 +0100 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=11971cf4bd=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-geom@freebsd.org Message-ID: From: "Steven Hartland" To: "Dmitry Zamaruyev" , References: <20110804130014.0df63364@ghost.kharkov.zoral.com.ua> Date: Thu, 4 Aug 2011 11:33:01 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 Cc: Subject: Re: SSD and gmirror X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 10:44:10 -0000 Be aware that you need to be using ata or another driver which supports this for it to work even on a standard disk. ----- Original Message ----- From: "Dmitry Zamaruyev" > Hello list, > > I'm looking for clarification regarding gmirror/geom behavior in > current 8-STABLE. > I want to use couple of SSD drives in mirror RAID configuration with > UFS on top. I know that UFS now supports TRIM (BIO_DELETE) on plain > disks. > But will gmirror propagate BIO_DELETE event to lower driver, so both > SSDs will get trimmed when UFS issue this command? ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-geom@FreeBSD.ORG Thu Aug 4 10:52:29 2011 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D0A7106564A for ; Thu, 4 Aug 2011 10:52:29 +0000 (UTC) (envelope-from dmitry.zamaruyev@zoral.com.ua) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id E1DB28FC17 for ; Thu, 4 Aug 2011 10:52:28 +0000 (UTC) Received: from ghost.kharkov.zoral.com.ua ([10.3.1.250]) (authenticated bits=0) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p74AqPol009455; Thu, 4 Aug 2011 13:52:25 +0300 (EEST) (envelope-from dmitry.zamaruyev@zoral.com.ua) Date: Thu, 4 Aug 2011 13:52:18 +0300 From: Dmitry Zamaruyev To: "Steven Hartland" , Message-ID: <20110804135218.5b75211f@ghost.kharkov.zoral.com.ua> In-Reply-To: References: <20110804130014.0df63364@ghost.kharkov.zoral.com.ua> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-103.3 required=5.0 tests=ALL_TRUSTED,BAYES_00, DNS_FROM_OPENWHOIS,USER_IN_WHITELIST autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Subject: Re: SSD and gmirror X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 10:52:29 -0000 SSD will be attached to Intel ESB2 chip, that using standard ata/ahci drivers (I guess): atapci1: port 0x18a0-0x18a7,0x1874-0x18= 77,0x1878-0x187f,0x1870-0x1873,0x1880-0x189f mem 0xd8500800-0xd8500bff irq = 19 at device 31.2 on pci0=20 atapci1: AHCI called from vendor specific driver=20 atapci1: AHCI v1.10 controller with 6 3Gbps ports, PM supported =D0=92 Thu, 4 Aug 2011 11:33:01 +0100 "Steven Hartland" =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > Be aware that you need to be using ata or another driver which > supports this for it to work even on a standard disk. >=20 > ----- Original Message -----=20 > From: "Dmitry Zamaruyev" >=20 >=20 > > Hello list, > >=20 > > I'm looking for clarification regarding gmirror/geom behavior in > > current 8-STABLE. > > I want to use couple of SSD drives in mirror RAID configuration with > > UFS on top. I know that UFS now supports TRIM (BIO_DELETE) on plain > > disks. > > But will gmirror propagate BIO_DELETE event to lower driver, so both > > SSDs will get trimmed when UFS issue this command? >=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > This e.mail is private and confidential between Multiplay (UK) Ltd. > and the person or entity to whom it is addressed. In the event of > misdirection, the recipient is prohibited from using, copying, > printing or otherwise disseminating it or any information contained > in it.=20 >=20 > In the event of misdirection, illegible or incomplete transmission > please telephone +44 845 868 1337 or return the E.mail to > postmaster@multiplay.co.uk. >=20 --=20 Best regards, Dmitry Zamaruyev, System administrator.