From owner-freebsd-geom@FreeBSD.ORG Mon Dec 9 08:27:24 2013 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B7248623 for ; Mon, 9 Dec 2013 08:27:24 +0000 (UTC) Received: from work.netasq.com (gwlille.netasq.com [91.212.116.1]) by mx1.freebsd.org (Postfix) with ESMTP id 3EA021084 for ; Mon, 9 Dec 2013 08:27:23 +0000 (UTC) Received: from work.netasq.com (localhost [127.0.0.1]) by work.netasq.com (Postfix) with ESMTP id 315BA27065AD; Mon, 9 Dec 2013 09:27:17 +0100 (CET) Received: from [10.200.5.1] (unknown [10.2.200.254]) by work.netasq.com (Postfix) with ESMTPSA id E0C3D27063C9; Mon, 9 Dec 2013 09:27:16 +0100 (CET) Message-ID: <52A57EF9.5050905@netasq.com> Date: Mon, 09 Dec 2013 09:27:37 +0100 From: Paolo Pinto User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: geom_uzip, panic: bio_length in mdstart_vnode() References: <529F2748.2060900@netasq.com> <20131204162029.GV59496@kib.kiev.ua> In-Reply-To: <20131204162029.GV59496@kib.kiev.ua> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040509050209030501020602" Cc: nicolas dumont , freebsd-geom@freebsd.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 08:27:24 -0000 This is a cryptographically signed message in MIME format. --------------ms040509050209030501020602 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Konstantin, Thanks for the workaround, it works for me; the assertion doesn't trigger anymore. On 12/04/2013 05:20 PM, Konstantin Belousov wrote: > On Wed, Dec 04, 2013 at 01:59:52PM +0100, Paolo Pinto wrote: >> Hi list! >> >> My kernel is compiled with option INVARIANTS and I get a reproducible >> kernel panic when trying to read data from a GEOM based compressed >> memory disk: >> >> Unread portion of the kernel message buffer: >> panic: bio_length 140288 >> cpuid =3D 3 >> KDB: stack backtrace: >> #0 0xffffffff80909726 at kdb_backtrace+0x66 >> #1 0xffffffff808d0fa8 at panic+0x1d8 >> #2 0xffffffff80595949 at mdstart_vnode+0x619 >=20 > The issue is that geom_uzip creates bios which are larger than MAXPHYS.= >=20 > As a workaround, the following patch should be enough. It only fires > assert when md really uses pbuf, and since geom_uzip knows nothing > about unmapped bio, the assertion must not trigger. >=20 > diff --git a/sys/dev/md/md.c b/sys/dev/md/md.c > index 8ae51d1..639677e 100644 > --- a/sys/dev/md/md.c > +++ b/sys/dev/md/md.c > @@ -746,12 +746,12 @@ mdstart_vnode(struct md_s *sc, struct bio *bp) > return (error); > } > =20 > - KASSERT(bp->bio_length <=3D MAXPHYS, ("bio_length %jd", > - (uintmax_t)bp->bio_length)); > if ((bp->bio_flags & BIO_UNMAPPED) =3D=3D 0) { > pb =3D NULL; > aiov.iov_base =3D bp->bio_data; > } else { > + KASSERT(bp->bio_length <=3D MAXPHYS, ("bio_length %jd", > + (uintmax_t)bp->bio_length)); > pb =3D getpbuf(&md_vnode_pbuf_freecnt); > pmap_qenter((vm_offset_t)pb->b_data, bp->bio_ma, bp->bio_ma_n); > aiov.iov_base =3D (void *)((vm_offset_t)pb->b_data + >=20 --=20 Paolo Pinto R&D System Engineer NETASQ - We secure IT --------------ms040509050209030501020602 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEnTCC BJkwggOBoAMCAQICCnDGsUgWa/KQbFgwDQYJKoZIhvcNAQEFBQAwgZExCzAJBgNVBAYTAkZS MQ0wCwYDVQQIEwROb3JkMRowGAYDVQQHExFWaWxsZW5ldXZlIGQnQXNjcTEuMCwGA1UEChMl TkVUQVNRIC0gU2VjdXJlIEludGVybmV0IENvbm5lY3Rpdml0eTEnMCUGA1UECxMeTkVUQVNR IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTEzMDgxMzE0NDUzM1oXDTE0MDgxMzE0NDUz M1owgc4xCzAJBgNVBAYTAkZSMQ0wCwYDVQQIEwROb3JkMRowGAYDVQQHExFWaWxsZW5ldXZl IGQnQXNjcTEuMCwGA1UEChMlTkVUQVNRIC0gU2VjdXJlIEludGVybmV0IENvbm5lY3Rpdml0 eTEnMCUGA1UECxMeTkVUQVNRIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MRQwEgYDVQQDEwtQ YW9sbyBQSU5UTzElMCMGCSqGSIb3DQEJARYWcGFvbG8ucGludG9AbmV0YXNxLmNvbTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJfH5PlgbBG9sAsYW+VgBDysPWJOjsMJFaOq iyCsBGgZUS6n0McSqWQMGaX+lGgiuVLkmxNxnLq8kZkARq4VbT25IaRdgbE0yPmFgYLd+9RK RNUBfGD6S0++7pebb7CXDrplhofj8fL+oLjOU27MdG/ZkWqV6Y0kTH9XPPrMSdSNqUSAcy5O iq7GwoTYwYlzhHILmXlVvjLZ1Ev9bJP053JomE1e7BuXjOETiPe1ymMvMNTCEjEXrmhpGmNV GIpxOKbokkngGpECQpicXf+okbHFFyEiINaNFFYlpDGHl8XXADvcEyxC7SyrIxgwpSL95VXp 3WeBNzRB+XUlFXNLnSUCAwEAAaOBszCBsDAdBgNVHQ4EFgQUwDeJ4UTO9EshTMwEjMVUgs6Y KcowHwYDVR0jBBgwFoAUJyrrHdlE2joXc2oJICDJJaj5f7IwCQYDVR0TBAIwADAOBgNVHQ8B Af8EBAMCA+gwIQYDVR0RBBowGIEWcGFvbG8ucGludG9AbmV0YXNxLmNvbTARBglghkgBhvhC AQEEBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMA0GCSqGSIb3DQEBBQUA A4IBAQCEKfnRno7B0wOD+ZpUhK24j5uuvPTP4ObfFqbK/yRPJZOZpMr9OgJg9g+uhgL268EX MqMmE5GbhDQq2uD70dS3f7irlssd9zjRQwdtH10c7J/NxTek3oMK+jDHFJMtaLwYyG/bfFPN TV/z3LBh+XHIYzpgtE8LCz8q1LyPay6acw364LmQRlUNRjVy9VYPQ8aFTMIterRSuy5kUP3w kga4WFan0uyLfGiTm5p21lyTExooMKFerEEdGdB/ctLfWbBcOaS8xTNzuhlwfINETBfqrhOQ 56ozRyAF6mElm0FFi4au/NPTX5sD/XrMITugeEub180NtKIP8ZeoQabp/j7ZMYIEATCCA/0C AQEwgaAwgZExCzAJBgNVBAYTAkZSMQ0wCwYDVQQIEwROb3JkMRowGAYDVQQHExFWaWxsZW5l dXZlIGQnQXNjcTEuMCwGA1UEChMlTkVUQVNRIC0gU2VjdXJlIEludGVybmV0IENvbm5lY3Rp dml0eTEnMCUGA1UECxMeTkVUQVNRIENlcnRpZmljYXRpb24gQXV0aG9yaXR5AgpwxrFIFmvy kGxYMAkGBSsOAwIaBQCgggI1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTEzMTIwOTA4MjczN1owIwYJKoZIhvcNAQkEMRYEFKB9YI7Trr688WNcZ1zez9xc fJ2KMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN AwICASgwgbEGCSsGAQQBgjcQBDGBozCBoDCBkTELMAkGA1UEBhMCRlIxDTALBgNVBAgTBE5v cmQxGjAYBgNVBAcTEVZpbGxlbmV1dmUgZCdBc2NxMS4wLAYDVQQKEyVORVRBU1EgLSBTZWN1 cmUgSW50ZXJuZXQgQ29ubmVjdGl2aXR5MScwJQYDVQQLEx5ORVRBU1EgQ2VydGlmaWNhdGlv biBBdXRob3JpdHkCCnDGsUgWa/KQbFgwgbMGCyqGSIb3DQEJEAILMYGjoIGgMIGRMQswCQYD VQQGEwJGUjENMAsGA1UECBMETm9yZDEaMBgGA1UEBxMRVmlsbGVuZXV2ZSBkJ0FzY3ExLjAs BgNVBAoTJU5FVEFTUSAtIFNlY3VyZSBJbnRlcm5ldCBDb25uZWN0aXZpdHkxJzAlBgNVBAsT Hk5FVEFTUSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIKcMaxSBZr8pBsWDANBgkqhkiG9w0B AQEFAASCAQBIMn69fX+0oFNqZfiz6yBqfE7nyrKiWqn6qotXbFMioEYbMD7I0lnvfs7K1tqX Q9wznTa/l701RatU4B671uwT84RPzGdlsNCURfojbInT0CcHlvhbFORNAzGLik4brhufFz/E 7mlggTu8QZOGzFBxmUzNOrrIPUW45hZtJdYhE7pGNTPc1gcmO3Kn8kNf21Wqihmqgu+FuXLy t0wfKKP7FHNkvRhez/RAflRLWiAGFILdv7+czLmESHNwJEKRMkMd61bpIzTp8sxxLY1c28pC lHCHcUi2skjK2nI/Levhi6+XmBntfWDLUWwJPBmwG5RvCM67tnA5lHseuklu6QwgAAAAAAAA --------------ms040509050209030501020602-- From owner-freebsd-geom@FreeBSD.ORG Mon Dec 9 11:06:46 2013 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 523DD19E for ; Mon, 9 Dec 2013 11:06:46 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3D2B51E76 for ; Mon, 9 Dec 2013 11:06:46 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id rB9B6k1G070995 for ; Mon, 9 Dec 2013 11:06:46 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id rB9B6jbf070993 for freebsd-geom@FreeBSD.org; Mon, 9 Dec 2013 11:06:45 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 9 Dec 2013 11:06:45 GMT Message-Id: <201312091106.rB9B6jbf070993@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.17 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 11:06:46 -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/183866 geom [geom] graid cannot remove loader detected BIOS RAIDS o kern/183803 geom [geom] FreeBSD 10 Beta 2 geom module does not understa o kern/181704 geom [geom] ggatec crash the system when I write something o kern/179889 geom [geli] geli stopped work after updating RELEASE 9.* so o kern/178684 geom gpart(8) cannot get my GEOM tree o kern/178359 geom [geom] [patch] geom_eli: support external metadata 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 bin/161807 geom [patch] add option for explicitly specifying metadata 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 bin/154570 geom [patch] gvinum(8) can't be built as part of the kernel 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/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. 80 problems total. From owner-freebsd-geom@FreeBSD.ORG Tue Dec 10 22:39:07 2013 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ED56F10D for ; Tue, 10 Dec 2013 22:39:07 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AC0821725 for ; Tue, 10 Dec 2013 22:39:07 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id rBAMd6Le070021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Dec 2013 14:39:07 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id rBAMd6rY070020; Tue, 10 Dec 2013 14:39:06 -0800 (PST) (envelope-from jmg) Date: Tue, 10 Dec 2013 14:39:06 -0800 From: John-Mark Gurney To: Konstantin Belousov Subject: Re: geom_uzip, panic: bio_length in mdstart_vnode() Message-ID: <20131210223906.GY55638@funkthat.com> Mail-Followup-To: Konstantin Belousov , Paolo Pinto , nicolas dumont , freebsd-geom@freebsd.org References: <529F2748.2060900@netasq.com> <20131204162029.GV59496@kib.kiev.ua> <20131205020742.GU55638@funkthat.com> <20131205082556.GA59496@kib.kiev.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131205082556.GA59496@kib.kiev.ua> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Tue, 10 Dec 2013 14:39:07 -0800 (PST) Cc: nicolas dumont , Paolo Pinto , freebsd-geom@freebsd.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 22:39:08 -0000 Konstantin Belousov wrote this message on Thu, Dec 05, 2013 at 10:25 +0200: > On Wed, Dec 04, 2013 at 06:07:43PM -0800, John-Mark Gurney wrote: > > Konstantin Belousov wrote this message on Wed, Dec 04, 2013 at 18:20 +0200: > > > On Wed, Dec 04, 2013 at 01:59:52PM +0100, Paolo Pinto wrote: > > > > Hi list! > > > > > > > > My kernel is compiled with option INVARIANTS and I get a reproducible > > > > kernel panic when trying to read data from a GEOM based compressed > > > > memory disk: > > > > > > > > Unread portion of the kernel message buffer: > > > > panic: bio_length 140288 > > > > cpuid = 3 > > > > KDB: stack backtrace: > > > > #0 0xffffffff80909726 at kdb_backtrace+0x66 > > > > #1 0xffffffff808d0fa8 at panic+0x1d8 > > > > #2 0xffffffff80595949 at mdstart_vnode+0x619 > > > > > > The issue is that geom_uzip creates bios which are larger than MAXPHYS. > > > > Shouldn't geom_uzip be fixed to honor MAXPHYS? > By all means, fix it. Can one of you at least open a bug report so it's tracked? I see that a commit happened, but no bug was opened to track that this issue needs to be fixed... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-geom@FreeBSD.ORG Thu Dec 12 00:16:13 2013 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BC32D87B for ; Thu, 12 Dec 2013 00:16:13 +0000 (UTC) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7AE4A1768 for ; Thu, 12 Dec 2013 00:16:13 +0000 (UTC) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 3841928427 for ; Thu, 12 Dec 2013 01:16:11 +0100 (CET) Received: from [192.168.1.2] (ip-89-177-49-222.net.upcbroadband.cz [89.177.49.222]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 32D1C28422 for ; Thu, 12 Dec 2013 01:16:10 +0100 (CET) Message-ID: <52A90049.7050001@quip.cz> Date: Thu, 12 Dec 2013 01:16:09 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.19) Gecko/20110420 Lightning/1.0b1 SeaMonkey/2.0.14 MIME-Version: 1.0 To: freebsd-geom@FreeBSD.org Subject: Is TRIM working with gmirror? Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 00:16:13 -0000 Is TRIM working on gmirror? I have FreeBSD 8.4-RELEASE-p1 amd64 GENERIC machine with 2x SSDs: ATA-9 SATA 3.x device They are partitioned with gpart GPT scheme: ada2p2 + ada3p2 There is gmirror gm1ssdp2 on top of these two partitions: mirror/gm1ssdp2 COMPLETE ada2p2 (ACTIVE) ada3p2 (ACTIVE) SSD it-self has support for TRIM # camcontrol identify ada2 pass2: ATA-9 SATA 3.x device pass2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) protocol ATA/ATAPI-9 SATA 3.x device model Samsung SSD 840 PRO Series firmware revision DXM05B0Q serial number S1ANNSAD760349A WWN 50025385a00b57ec cylinders 16383 heads 16 sectors/track 63 sector size logical 512, physical 512, offset 0 LBA supported 250069680 sectors LBA48 supported 250069680 sectors PIO supported PIO4 DMA supported WDMA2 UDMA6 media RPM non-rotating Feature Support Enabled Value Vendor read ahead yes yes write cache yes yes flush cache yes yes overlap no Tagged Command Queuing (TCQ) no no Native Command Queuing (NCQ) yes 32 tags SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management no no automatic acoustic management no no media status notification no no power-up in Standby no no write-read-verify yes no 0/0x0 unload no no free-fall no no data set management (TRIM) yes But there is a WARNING at boot: WARNING: /ssd_db: TRIM flag on fs but disk does not confirm that it supports TRIM The filesystem is classic UFS2. Is TRIM supported throught gmirror, or not? Miroslav Lachman From owner-freebsd-geom@FreeBSD.ORG Thu Dec 12 21:41:34 2013 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B660C5FA for ; Thu, 12 Dec 2013 21:41:34 +0000 (UTC) Received: from nm15-vm6.bullet.mail.ne1.yahoo.com (nm15-vm6.bullet.mail.ne1.yahoo.com [98.138.91.108]) by mx1.freebsd.org (Postfix) with SMTP id 6356B1AF5 for ; Thu, 12 Dec 2013 21:41:34 +0000 (UTC) Received: from [98.138.100.114] by nm15.bullet.mail.ne1.yahoo.com with NNFMP; 12 Dec 2013 21:39:26 -0000 Received: from [98.138.84.46] by tm105.bullet.mail.ne1.yahoo.com with NNFMP; 12 Dec 2013 21:39:26 -0000 Received: from [127.0.0.1] by smtp114.mail.ne1.yahoo.com with NNFMP; 12 Dec 2013 21:39:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1386884366; bh=5a5VsmV9xm8VpD0gyvNcvCKGgjHJYQbIPp+tpxqi7DU=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding; b=55IWLmsL+84lLxoo5dPJIoFrBcycvGWVTbhd/pHsxliiAXnACD/qrwDTirb6mkMRjavsRmm2qH1/Sl7/XAZ3Z5WzgVEPaI0TjVx48Dl6mPYrEWG0C+j9HpMu6g+kLAHup/O7EvacBBGBmnDHv+RKZz96aI6rkNtNWWLg8vafzW4= X-Yahoo-Newman-Id: 630232.75672.bm@smtp114.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: ZtJv02QVM1lLzOd36yrMtf37BgIX6h4RvBBtfJhSzQogGym XitzGSb.eA3kpacRqc9y4duKZTBIkU5UYTLVa3jjF6AuerkOwr3MFFBJ_2w7 J2zfCdyDaZY.mAl2lYr_ITitKgOBLj_.bVaOGovo9Uyr.FztjOWIdGQsK3C2 kRweVhyL3BL5o44cGTwhldnqNByDCNPU7i7ozI0wDRFF.2gkvJkg0bjfcbtB iF19wQ5zFPzu2Yr7qfN_WgoEMlI6EdZN7TEA3q9ABBgF5YOpaEW1HukDnWAg 7GeruTmYq.MVPIzTIYxxhjwKVj4YuQIpdaR.hRXR6jzIa8wJjCNCm8MTFkKQ cPOAXjwGZQaaWr08QKOwl5A9yc7S9ibFdm31D0_n00xMW06B4tptnzhHJbjE pTGksFEagW7E3FA0X_edhxDu1IXCWB_wu433bwPoo7XKfU28zL7w9O9KAyQn Gw9yl4g_k4ohQEahfJ2APmxXht52TOocE2WAFOk6M6lXP52.r16V.S0F7P6T hcSHqVQneIiZjagFNO4w3rzFPe1w6Qio40FPMjA-- X-Yahoo-SMTP: BFIo0uKswBBDNsNK7WmZMLoODEM1fg-- X-Rocket-Received: from localhost.localdomain (x254a61cc@95.111.167.41 with plain [98.138.105.21]) by smtp114.mail.ne1.yahoo.com with SMTP; 12 Dec 2013 13:39:26 -0800 PST Message-ID: <52AA2D0A.1000006@yahoo.com> Date: Thu, 12 Dec 2013 23:39:22 +0200 From: x254a61cc User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: freebsd-geom@freebsd.org Subject: g_topology_unlock and g_write_data Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 21:41:34 -0000 Hi everyone, why in the function "g_eli_read_metadata" (sys/geom/eli/g_eli.c) before reading data we call 'g_topology_unlock()', but in the "g_eli_ctl_configure" (sys/geom/eli/g_eli_ctl.c) we don't call 'g_topology_unlock()'?