From owner-freebsd-geom@FreeBSD.ORG Mon Feb 24 07:03:15 2014 Return-Path: Delivered-To: freebsd-geom@smarthost.ysv.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 90B7C33D; Mon, 24 Feb 2014 07:03:15 +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 61B0C1AF2; Mon, 24 Feb 2014 07:03:15 +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 s1O73FZh038343; Mon, 24 Feb 2014 07:03:15 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s1O73FZC038342; Mon, 24 Feb 2014 07:03:15 GMT (envelope-from linimon) Date: Mon, 24 Feb 2014 07:03:15 GMT Message-Id: <201402240703.s1O73FZC038342@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-geom@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/186816: [geom] After adding a disk in the disk pool is lost geom disk 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, 24 Feb 2014 07:03:15 -0000 Old Synopsis: After adding a disk in the disk pool is lost geom disk New Synopsis: [geom] After adding a disk in the disk pool is lost geom disk Responsible-Changed-From-To: freebsd-bugs->freebsd-geom Responsible-Changed-By: linimon Responsible-Changed-When: Mon Feb 24 07:02:45 UTC 2014 Responsible-Changed-Why: reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=186816 From owner-freebsd-geom@FreeBSD.ORG Mon Feb 24 09:58:53 2014 Return-Path: Delivered-To: freebsd-geom@smarthost.ysv.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 0BC9239D; Mon, 24 Feb 2014 09:58:53 +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 D41CC1DEB; Mon, 24 Feb 2014 09:58:52 +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 s1O9wqft005253; Mon, 24 Feb 2014 09:58:52 GMT (envelope-from ae@freefall.freebsd.org) Received: (from ae@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s1O9wpdM005252; Mon, 24 Feb 2014 09:58:51 GMT (envelope-from ae) Date: Mon, 24 Feb 2014 09:58:51 GMT Message-Id: <201402240958.s1O9wpdM005252@freefall.freebsd.org> To: admin@support.od.ua, ae@FreeBSD.org, freebsd-geom@FreeBSD.org From: ae@FreeBSD.org Subject: Re: bin/186814: gpart(8) when cloning does not transfer label name 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, 24 Feb 2014 09:58:53 -0000 Synopsis: gpart(8) when cloning does not transfer label name State-Changed-From-To: open->closed State-Changed-By: ae State-Changed-When: Mon Feb 24 09:57:54 UTC 2014 State-Changed-Why: Not a bug. Use gpart restore -l to restore labels. http://www.freebsd.org/cgi/query-pr.cgi?pr=186814 From owner-freebsd-geom@FreeBSD.ORG Mon Feb 24 11:06:48 2014 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 CE16CA6E for ; Mon, 24 Feb 2014 11:06:48 +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 B9A721618 for ; Mon, 24 Feb 2014 11:06:48 +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 s1OB6m8c027519 for ; Mon, 24 Feb 2014 11:06:48 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s1OB6mIa027514 for freebsd-geom@FreeBSD.org; Mon, 24 Feb 2014 11:06:48 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 24 Feb 2014 11:06:48 GMT Message-Id: <201402241106.s1OB6mIa027514@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, 24 Feb 2014 11:06:48 -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/186816 geom [geom] After adding a disk in the disk pool is lost ge 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 f 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. 81 problems total. From owner-freebsd-geom@FreeBSD.ORG Mon Feb 24 19:00:00 2014 Return-Path: Delivered-To: freebsd-geom@smarthost.ysv.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 7405FBF; Mon, 24 Feb 2014 19:00:00 +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 58D5719A4; Mon, 24 Feb 2014 19:00:00 +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 s1OJ00ZJ085460; Mon, 24 Feb 2014 19:00:00 GMT (envelope-from jmg@freefall.freebsd.org) Received: (from jmg@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s1OJ00Nk085439; Mon, 24 Feb 2014 19:00:00 GMT (envelope-from jmg) Date: Mon, 24 Feb 2014 19:00:00 GMT Message-Id: <201402241900.s1OJ00Nk085439@freefall.freebsd.org> To: admin@support.od.ua, jmg@FreeBSD.org, freebsd-geom@FreeBSD.org, jmg@FreeBSD.org From: jmg@FreeBSD.org Subject: Re: kern/186816: [geom] After adding a disk in the disk pool is lost geom disk 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, 24 Feb 2014 19:00:00 -0000 Synopsis: [geom] After adding a disk in the disk pool is lost geom disk State-Changed-From-To: open->feedback State-Changed-By: jmg State-Changed-When: Mon Feb 24 18:58:53 UTC 2014 State-Changed-Why: I'll take this over as I believe the user was just using the wrong device.. waiting for feedback (submitted as follow up, should be there shortly).. Responsible-Changed-From-To: freebsd-geom->jmg Responsible-Changed-By: jmg Responsible-Changed-When: Mon Feb 24 18:58:53 UTC 2014 Responsible-Changed-Why: I'll take this over as I believe the user was just using the wrong device.. waiting for feedback (submitted as follow up, should be there shortly).. http://www.freebsd.org/cgi/query-pr.cgi?pr=186816 From owner-freebsd-geom@FreeBSD.ORG Tue Feb 25 22:01:10 2014 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 08DEB9B7; Tue, 25 Feb 2014 22:01:10 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id C2C5210BD; Tue, 25 Feb 2014 22:01:09 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:2572:353:cc5e:8eee]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 65E5B4AC2D; Wed, 26 Feb 2014 02:01:08 +0400 (MSK) Date: Wed, 26 Feb 2014 02:01:05 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <585146922.20140226020105@serebryakov.spb.ru> To: freebsd-geom@freebsd.org Subject: 3rd party geom module on 10-STABLE cause panics in biodone() MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: mav@FreeBSD.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: lev@FreeBSD.org List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 22:01:10 -0000 Hello, Freebsd-geom. My geom_raid5, which works rock-stable on 9-STABLE, causes panics in biodone() on 10-STABLE. It causes panic at line 3567, 3561 if ((bp->bio_flags & BIO_TRANSIENT_MAPPING) != 0) { 3562 bp->bio_flags &= ~BIO_TRANSIENT_MAPPING; 3563 bp->bio_flags |= BIO_UNMAPPED; 3564 start = trunc_page((vm_offset_t)bp->bio_data); 3565 end = round_page((vm_offset_t)bp->bio_data + bp->bio_length); 3566 pmap_qremove(start, OFF_TO_IDX(end - start)); 3567 vmem_free(transient_arena, start, end - start); 3568 atomic_add_int(&inflight_transient_maps, -1); 3569 } And these crashes are very bad: 9 of 10 times system could not make crashdump or reboot and 8 out of 10 times it shuts down video output (!). I was lucky to get one crashdump to find this line... What could I do wrong in my module? -- // Black Lion AKA Lev Serebryakov From owner-freebsd-geom@FreeBSD.ORG Tue Feb 25 22:16:38 2014 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 6F542E95; Tue, 25 Feb 2014 22:16:38 +0000 (UTC) Received: from mail-bk0-x22a.google.com (mail-bk0-x22a.google.com [IPv6:2a00:1450:4008:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C914311B9; Tue, 25 Feb 2014 22:16:37 +0000 (UTC) Received: by mail-bk0-f42.google.com with SMTP id mx12so464236bkb.1 for ; Tue, 25 Feb 2014 14:16:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=YziSJVWSY+grv5AqHVvCqrLES29xca0AMxFV/m+jR2A=; b=SbQ+jCelZusQVlGNzjZMhQkH+lM9laHxWEn2PDJKmNoiZGnmClkIBSZXwXCCXT0SRT 7qU5Ux+26OtTMSmXLIgpnNWaPGjFLfDOZDClJJXnKr9ivSdV/vfIl+DippLiyt/Le2EF izfWBy8+lwlGzdtNN/PuQ11SAcMhYE4kSRN8fSmCq2JGfiMJJD/i56Ad+n0dVd8s+SDU T90Iq5cZDo4CazM3Z5x0nos/ouCb5MpbTfOIS0hQbhjFRMG0F7WyODJh/mbobKSBBBP8 FpOwT7L31hKaMmyEYl9+jMOtBoWNdbMWp0iE9EyHslFbAStjiMSTllDkqShPQAozt5YZ /LPg== X-Received: by 10.205.32.142 with SMTP id sk14mr2397609bkb.18.1393366596041; Tue, 25 Feb 2014 14:16:36 -0800 (PST) Received: from mavbook.mavhome.dp.ua ([134.249.139.101]) by mx.google.com with ESMTPSA id z2sm19981850bkm.14.2014.02.25.14.16.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Feb 2014 14:16:35 -0800 (PST) Sender: Alexander Motin Message-ID: <530D1640.3050104@FreeBSD.org> Date: Wed, 26 Feb 2014 00:16:32 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: lev@FreeBSD.org, freebsd-geom@freebsd.org Subject: Re: 3rd party geom module on 10-STABLE cause panics in biodone() References: <585146922.20140226020105@serebryakov.spb.ru> In-Reply-To: <585146922.20140226020105@serebryakov.spb.ru> 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: Tue, 25 Feb 2014 22:16:38 -0000 On 26.02.2014 00:01, Lev Serebryakov wrote: > My geom_raid5, which works rock-stable on 9-STABLE, causes panics in > biodone() on 10-STABLE. It causes panic at line 3567, > > 3561 if ((bp->bio_flags & BIO_TRANSIENT_MAPPING) != 0) { > 3562 bp->bio_flags &= ~BIO_TRANSIENT_MAPPING; > 3563 bp->bio_flags |= BIO_UNMAPPED; > 3564 start = trunc_page((vm_offset_t)bp->bio_data); > 3565 end = round_page((vm_offset_t)bp->bio_data + bp->bio_length); > 3566 pmap_qremove(start, OFF_TO_IDX(end - start)); > 3567 vmem_free(transient_arena, start, end - start); > 3568 atomic_add_int(&inflight_transient_maps, -1); > 3569 } > > And these crashes are very bad: 9 of 10 times system could not make > crashdump or reboot and 8 out of 10 times it shuts down video output (!). > > I was lucky to get one crashdump to find this line... > > What could I do wrong in my module? IIRC I had problem with that part of code during my GEOM direct dispatch work when some requests were unmapped twice. At that time I've added restoring the flags at lines 3562-3563, and it helped in my case. Make sure that you are not have some unexpected requests reuse, etc, that may cause incorrect combination of BIO flags and addresses. -- Alexander Motin From owner-freebsd-geom@FreeBSD.ORG Wed Feb 26 07:05:52 2014 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 AF2AB30D; Wed, 26 Feb 2014 07:05:52 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 6D1A113AC; Wed, 26 Feb 2014 07:05:52 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:2572:353:cc5e:8eee]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id F36914AC2D; Wed, 26 Feb 2014 11:05:44 +0400 (MSK) Date: Wed, 26 Feb 2014 11:05:41 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <202114262.20140226110541@serebryakov.spb.ru> To: Alexander Motin Subject: Re: 3rd party geom module on 10-STABLE cause panics in biodone() In-Reply-To: <530D1640.3050104@FreeBSD.org> References: <585146922.20140226020105@serebryakov.spb.ru> <530D1640.3050104@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Cc: freebsd-geom@freebsd.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: lev@FreeBSD.org List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 07:05:52 -0000 Hello, Alexander. You wrote 26 =F4=E5=E2=F0=E0=EB=FF 2014 =E3., 2:16:32: >> 3561 if ((bp->bio_flags & BIO_TRANSIENT_MAPPING) !=3D 0) { >> 3562 bp->bio_flags &=3D ~BIO_TRANSIENT_MAPPING; >> 3563 bp->bio_flags |=3D BIO_UNMAPPED; >> 3564 start =3D trunc_page((vm_offset_t)bp->bio_data); >> 3565 end =3D round_page((vm_offset_t)bp->bio_data + bp->bio_length); >> 3566 pmap_qremove(start, OFF_TO_IDX(end - start)); >> 3567 vmem_free(transient_arena, start, end - start); >> 3568 atomic_add_int(&inflight_transient_maps, -1); >> 3569 } >> >> And these crashes are very bad: 9 of 10 times system could not make >> crashdump or reboot and 8 out of 10 times it shuts down video output (!). >> >> I was lucky to get one crashdump to find this line... >> >> What could I do wrong in my module? AM> IIRC I had problem with that part of code during my GEOM direct dispatch AM> work when some requests were unmapped twice. At that time I've added=20 AM> restoring the flags at lines 3562-3563, and it helped in my case. Make= =20 AM> sure that you are not have some unexpected requests reuse, etc, that ma= y=20 AM> cause incorrect combination of BIO flags and addresses. It is impossible to debug this on real hardware and now I'm trying to reproduce this on VirtualBox. My plan is to print out EVERY bio which is freed here and every processed bio in my module and to find exact path of failing bio though my module... --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-geom@FreeBSD.ORG Sat Mar 1 11:00:40 2014 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 E606FD70 for ; Sat, 1 Mar 2014 11:00:40 +0000 (UTC) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7333F1BA5 for ; Sat, 1 Mar 2014 11:00:40 +0000 (UTC) Received: by mail-la0-f53.google.com with SMTP id b8so3456284lan.12 for ; Sat, 01 Mar 2014 03:00:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=9AVzQPZ0/I+BESDj+P34bMFP4FkfRtS2XVbZqKbh0vs=; b=zH9WCQ+OTm6q4a2G8KXIUtRcP/pHiIrrs9fKRu2iYPcBRe3l7wW2zJl1ZNlEIDIM6a AhnNR2IqVtC3cu6T49oRmQGleJ86FPZmKrncTDvLNB8VnkO5i5IDRn4gzn1Pifq4a51g 1jiGtDkupeqYLhIM+jS7O4PVhu/2CNqppnHDxGVAgq13t8FkhiOU77RRJMqxbNHGRXTQ S3bNPlaZZk4d7QoBJ7Sk6vAGw8XO1N9lK447m6hwmK4mZl1RQMCf8FxcHaRvDAIAW9de 6cgeqR4Ds8oXkNUc3GfZS9X5LYvyCFQ7LSDfQVx/gXAvuqGC1bBH1epJrHz7/EHq4rWU lkzQ== MIME-Version: 1.0 X-Received: by 10.152.242.165 with SMTP id wr5mr1386174lac.47.1393671638576; Sat, 01 Mar 2014 03:00:38 -0800 (PST) Received: by 10.112.243.10 with HTTP; Sat, 1 Mar 2014 03:00:38 -0800 (PST) Date: Sat, 1 Mar 2014 14:30:38 +0330 Message-ID: Subject: editing geli code to write something in a file From: s m To: freebsd-geom@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 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: Sat, 01 Mar 2014 11:00:41 -0000 hello all for some reason, i want to do some extra process when entered passphrase is correct in geli. in order to do that, i edit geli code (g_eli.c file) and add my code to g_eli_taste function. every thing is ok except writing some thing in a file. i can't use any standard library here. is there any way to do that? should i use kernel functions which works with vnode in order to do that??? if yes, how should i do it? please give me a point. thanks in advance SAM From owner-freebsd-geom@FreeBSD.ORG Sat Mar 1 20:00:39 2014 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 BCDED4C6 for ; Sat, 1 Mar 2014 20:00:39 +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 987B41961 for ; Sat, 1 Mar 2014 20:00:39 +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 s21K0c6f099676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 1 Mar 2014 12:00:38 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s21K0co7099675; Sat, 1 Mar 2014 12:00:38 -0800 (PST) (envelope-from jmg) Date: Sat, 1 Mar 2014 12:00:38 -0800 From: John-Mark Gurney To: s m Subject: Re: editing geli code to write something in a file Message-ID: <20140301200038.GB47921@funkthat.com> Mail-Followup-To: s m , freebsd-geom@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE 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]); Sat, 01 Mar 2014 12:00:39 -0800 (PST) Cc: 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: Sat, 01 Mar 2014 20:00:39 -0000 s m wrote this message on Sat, Mar 01, 2014 at 14:30 +0330: > for some reason, i want to do some extra process when entered passphrase is > correct in geli. in order to do that, i edit geli code (g_eli.c file) and > add my code to g_eli_taste function. every thing is ok except writing some > thing in a file. i can't use any standard library here. is there any way to > do that? should i use kernel functions which works with vnode in order to > do that??? if yes, how should i do it? please give me a point. asked and answered: http://docs.freebsd.org/cgi/mid.cgi?4652AD8C.7000605 -- 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 Mon Mar 3 11:06:44 2014 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 73DA7DEF for ; Mon, 3 Mar 2014 11:06:44 +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 6101793C for ; Mon, 3 Mar 2014 11:06:44 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s23B6inH008489 for ; Mon, 3 Mar 2014 11:06:44 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s23B6h7k008487 for freebsd-geom@FreeBSD.org; Mon, 3 Mar 2014 11:06:43 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 3 Mar 2014 11:06:43 GMT Message-Id: <201403031106.s23B6h7k008487@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, 03 Mar 2014 11:06:44 -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 f 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 Wed Mar 5 14:10:07 2014 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 E1CA0AA1 for ; Wed, 5 Mar 2014 14:10:07 +0000 (UTC) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id AC2DECC9 for ; Wed, 5 Mar 2014 14:10:07 +0000 (UTC) Received: from Mail-PC.tdx.co.uk (storm.tdx.co.uk [62.13.130.251]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id s25E89fB027353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 5 Mar 2014 14:08:10 GMT Date: Wed, 05 Mar 2014 14:08:09 +0000 From: Karl Pielorz To: freebsd-geom@freebsd.org Subject: HAST local read performance? Message-ID: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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: Wed, 05 Mar 2014 14:10:07 -0000 Hi, I have a couple of FreeBSD 10 systems I've setup HAST on - this seems to work well, but I've noticed the read performance of local /dev/hast/* devices is around half of the normal raw device? e.g. a dd from an SSD as /dev/da0 nets around 220Mbyte/sec - the same dd run against the same device when setup with hast (i.e. /dev/hast/disk1) only nets around 110Mbyte/sec. I realise another layer is going to affect performance (and this may just be the price you have to pay) but is there anything likely tunable for this? If I fail the other node (so I'm running the test against a 'degraded primary') it's still as slow [as you'd kind of expect, as reads were/are only local] I've setup ZFS on top of the hast devices - again this seems to work OK, but you can really see the performance difference when doing a pool scrub on hast backed devices vs. the raw ones... -Karl From owner-freebsd-geom@FreeBSD.ORG Wed Mar 5 16:13:11 2014 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 4BEEE540 for ; Wed, 5 Mar 2014 16:13:11 +0000 (UTC) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1C902CAE for ; Wed, 5 Mar 2014 16:13:10 +0000 (UTC) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 6DE2F2119D for ; Wed, 5 Mar 2014 11:13:00 -0500 (EST) Received: from web6 ([10.202.2.216]) by compute5.internal (MEProxy); Wed, 05 Mar 2014 11:13:00 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:subject:date:in-reply-to :references; s=smtpout; bh=UBC3R9KxjekoHN9OolPwJ84ER10=; b=NyP03 9ozS9PAahFRhII7gNMtwuK+Mx50UPrL1VDxF3456zr35b2cUPLLqWdDcXZuAIV/p vt3e7w727HzAeeq/jHHMR6Qu9X2chktWFAZZRca89wGYelO/RvMvEoRMcggGS4Ks 3Mt1yVHAmtpwKEBsVFrguMomRQNrwOgQYrKcL8= Received: by web6.nyi.mail.srv.osa (Postfix, from userid 99) id 597F528A4CB; Wed, 5 Mar 2014 11:13:00 -0500 (EST) Message-Id: <1394035980.8640.90922737.615AFA56@webmail.messagingengine.com> X-Sasl-Enc: 4QaC8oSdySYiOZwsODjGJf+hIvwg2gzwwXhY9gHN24Nu 1394035980 From: Mark Felder To: freebsd-geom@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-4527a23f Subject: Re: HAST local read performance? Date: Wed, 05 Mar 2014 10:13:00 -0600 In-Reply-To: References: 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: Wed, 05 Mar 2014 16:13:11 -0000 On Wed, Mar 5, 2014, at 8:08, Karl Pielorz wrote: > > Hi, > > I have a couple of FreeBSD 10 systems I've setup HAST on - this seems to > work well, but I've noticed the read performance of local /dev/hast/* > devices is around half of the normal raw device? > > e.g. a dd from an SSD as /dev/da0 nets around 220Mbyte/sec - the same dd > run against the same device when setup with hast (i.e. /dev/hast/disk1) > only nets around 110Mbyte/sec. > > I realise another layer is going to affect performance (and this may just > be the price you have to pay) but is there anything likely tunable for > this? > > If I fail the other node (so I'm running the test against a 'degraded > primary') it's still as slow [as you'd kind of expect, as reads were/are > only local] > > I've setup ZFS on top of the hast devices - again this seems to work OK, > but you can really see the performance difference when doing a pool scrub > on hast backed devices vs. the raw ones... > Which HAST replication mode are you using? Fullsync? Do you have atime enabled on that filesystem? I'd expect it to act like a local disk without any significant penalties unless you're doing writes and they're waiting to be synced before the next read. From owner-freebsd-geom@FreeBSD.ORG Wed Mar 5 18:12:49 2014 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 73780E38; Wed, 5 Mar 2014 18:12:49 +0000 (UTC) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id 14F51AD5; Wed, 5 Mar 2014 18:12:48 +0000 (UTC) Received: from study64.tdx.co.uk (study64.tdx.co.uk [62.13.130.231]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id s25ICkOs052545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Mar 2014 18:12:47 GMT Date: Wed, 05 Mar 2014 18:12:46 +0000 From: Karl Pielorz To: Mark Felder , freebsd-geom@freebsd.org Subject: Re: HAST local read performance? Message-ID: <0256F5C22685BD8205AE3952@study64.tdx.co.uk> In-Reply-To: <1394035980.8640.90922737.615AFA56@webmail.messagingengine.com> References: <1394035980.8640.90922737.615AFA56@webmail.messagingengine.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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: Wed, 05 Mar 2014 18:12:49 -0000 --On 5 March 2014 10:13:00 -0600 Mark Felder wrote: > Which HAST replication mode are you using? Fullsync? Do you have atime > enabled on that filesystem? I'd expect it to act like a local disk > without any significant penalties unless you're doing writes and they're > waiting to be synced before the next read. Currently using async (makes no difference from fullsync - I'd guess that would only affect writes, not reads), and 'checksum none' No atime enabled on the file system (ZFS) - the speed difference is very apparent with reading via dd (which is obviously raw-read only) - and on zpool scrubbing (which is 99% read with few writes) - if I deliberately 'fail' the secondary (so not even those few writes are sent to the secondary) the speed remains the same. It's certainly 'usable' - the only issue is with a few TB's of ZFS filesystem to scrub, it's rather slow through HAST (even when reads are happening only on the local machine). Like you said you'd expect reads, from the local primary would be pretty similar to a local disk. I guess with more devices online it'll pickup speed wise anyway. -Karl From owner-freebsd-geom@FreeBSD.ORG Mon Mar 10 11:06:45 2014 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 0DE19C6 for ; Mon, 10 Mar 2014 11:06:45 +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 EE816805 for ; Mon, 10 Mar 2014 11:06:44 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s2AB6inT043187 for ; Mon, 10 Mar 2014 11:06:44 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s2AB6ixL043185 for freebsd-geom@FreeBSD.org; Mon, 10 Mar 2014 11:06:44 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 10 Mar 2014 11:06:44 GMT Message-Id: <201403101106.s2AB6ixL043185@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, 10 Mar 2014 11:06:45 -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 f 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 Mon Mar 17 11:06:44 2014 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 B437A92D for ; Mon, 17 Mar 2014 11:06:44 +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 A07FD28F for ; Mon, 17 Mar 2014 11:06:44 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s2HB6i0q011230 for ; Mon, 17 Mar 2014 11:06:44 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s2HB6iDc011228 for freebsd-geom@FreeBSD.org; Mon, 17 Mar 2014 11:06:44 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 17 Mar 2014 11:06:44 GMT Message-Id: <201403171106.s2HB6iDc011228@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, 17 Mar 2014 11:06:44 -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 f 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 Mar 18 02:37:16 2014 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 AEFAE6B1; Tue, 18 Mar 2014 02:37:16 +0000 (UTC) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 82E5BBA7; Tue, 18 Mar 2014 02:37:16 +0000 (UTC) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id CEA7820D1D; Mon, 17 Mar 2014 22:37:14 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute6.internal (MEProxy); Mon, 17 Mar 2014 22:37:14 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:cc:mime-version :content-transfer-encoding:content-type:subject:date; s=smtpout; bh=tLn7NGhHmQTZa9ZoUjeLTw2azhg=; b=NIosZFxNQkGgtLkeM4qeGqUB7KXI 5IEiai6apYJQGeb2HxU8/QAg+y+7Se2fgvupGjsAB/WjJB+keFAr7O188729atXP /NnNk87csNjqVw1OGYkomIxnrCdWOJAhYgKRDQT98MMjOtXEjD0wZC3rIcLyE7s7 YamBGx27NibpgAw= Received: by web3.nyi.mail.srv.osa (Postfix, from userid 99) id 959641480A1; Mon, 17 Mar 2014 22:37:14 -0400 (EDT) Message-Id: <1395110234.28391.95721417.1EBDEC74@webmail.messagingengine.com> X-Sasl-Enc: aa1PlYTp4+48JpV24VQKRimQVlYh62gKZ0L6U4I/3kVC 1395110234 From: Ryan Lortie To: freebsd-geom@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-88721676 Subject: GLib vs. libgeom: g_close() Date: Mon, 17 Mar 2014 22:37:14 -0400 X-Forwarded-Message-Id: <1391613475.11936.79646661.124E1A36@webmail.messagingengine.com> Cc: kwm@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, 18 Mar 2014 02:37:16 -0000 hi, I'm part of a team that's trying to get the latest versions of GNOME (out of git) building on FreeBSD with the eventual goal of getting a "continuous integration" sort of setup so that we can flag FreeBSD portability issues in GNOME at an earlier stage. We've made some pretty good progress so far: https://wiki.gnome.org/Projects/Jhbuild/FreeBSD We hit an issue a bit over a month ago when attempting to get libgtop working with the latest GLib on FreeBSD. Specifically: GLib added a g_close() function during the 2.36 cycle which conflicts with the g_close() function that is exported by libgeom. https://developer.gnome.org/glib/stable/glib-File-Utilities.html#g-close http://www.unix.com/man-page/FreeBSD/3/g_close/ I tried to write to pjd@ to ask for advice but I didn't receive any reply. In tthe short term is that we have had to remove support for reporting disk usage statistics on FreeBSD from libgtop in order to avoid the conflict. In the medium-long term (maybe FreeBSD 11 timeframe) I was wondering if it would be possible to change libgeom so that it only uses one namespace (eg: geom_) instead of three (geom_, gctl_, g_). This would allow us to re-enable support for disk statistics and would avoid future problems that will surely come up in other situations due to this conflict. I understand that GLib was the second library to use the name 'g_close' but there are some factors that I think weigh in favour of GLib's continued use of the name: - GLib has a very strong and publicly-stated policy of API/ABI stability - GLib is extremely widely used on essentially every platform in existence - GLib's use of the g_ namespace is long-established, predating the existence of libgeom. It currently has approximately 4000 symbols starting with g_ in this namespace. - I don't personally believe that it's a good idea to have multiple libraries sharing a namespace, and libgeom is also using three separate namespaces... I appreciate any input on this issue. I particularly hope to be able to find a solution that would allow us to re-enable the filesystem statistics reporting on FreeBSD. Thanks in advance. From owner-freebsd-geom@FreeBSD.ORG Tue Mar 18 15:23:09 2014 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 B3491FFA; Tue, 18 Mar 2014 15:23:09 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D4614F99; Tue, 18 Mar 2014 15:23:08 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.8/8.14.8) with ESMTP id s2IFMti8005093; Tue, 18 Mar 2014 17:22:55 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s2IFMti8005093 Received: (from kostik@localhost) by tom.home (8.14.8/8.14.8/Submit) id s2IFMsJa005092; Tue, 18 Mar 2014 17:22:54 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 18 Mar 2014 17:22:54 +0200 From: Konstantin Belousov To: Ryan Lortie Subject: Re: GLib vs. libgeom: g_close() Message-ID: <20140318152254.GF21331@kib.kiev.ua> References: <1395110234.28391.95721417.1EBDEC74@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yRA+Bmk8aPhU85Qt" Content-Disposition: inline In-Reply-To: <1395110234.28391.95721417.1EBDEC74@webmail.messagingengine.com> User-Agent: Mutt/1.5.23 (2014-03-12) 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 autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: kwm@freebsd.org, 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, 18 Mar 2014 15:23:09 -0000 --yRA+Bmk8aPhU85Qt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 17, 2014 at 10:37:14PM -0400, Ryan Lortie wrote: > hi, >=20 > I'm part of a team that's trying to get the latest versions of GNOME > (out of git) building on FreeBSD with the eventual goal of getting a > "continuous integration" sort of setup so that we can flag FreeBSD > portability issues in GNOME at an earlier stage. >=20 > We've made some pretty good progress so far: >=20 > https://wiki.gnome.org/Projects/Jhbuild/FreeBSD >=20 > We hit an issue a bit over a month ago when attempting to get libgtop > working with the latest GLib on FreeBSD. Specifically: GLib added a > g_close() function during the 2.36 cycle which conflicts with the > g_close() function that is exported by libgeom. >=20 > https://developer.gnome.org/glib/stable/glib-File-Utilities.html#g-close > http://www.unix.com/man-page/FreeBSD/3/g_close/ >=20 > I tried to write to pjd@ to ask for advice but I didn't receive any > reply. >=20 > In tthe short term is that we have had to remove support for reporting > disk usage statistics on FreeBSD from libgtop in order to avoid the > conflict. >=20 > In the medium-long term (maybe FreeBSD 11 timeframe) I was wondering if > it would be possible to change libgeom so that it only uses one > namespace (eg: geom_) instead of three (geom_, gctl_, g_). This would > allow us to re-enable support for disk statistics and would avoid future > problems that will surely come up in other situations due to this > conflict. >=20 > I understand that GLib was the second library to use the name 'g_close' > but there are some factors that I think weigh in favour of GLib's > continued use of the name: >=20 > - GLib has a very strong and publicly-stated policy of API/ABI > stability >=20 > - GLib is extremely widely used on essentially every platform in > existence >=20 > - GLib's use of the g_ namespace is long-established, predating the > existence of libgeom. It currently has approximately 4000 symbols > starting with g_ in this namespace. >=20 > - I don't personally believe that it's a good idea to have multiple > libraries sharing a namespace, and libgeom is also using three > separate namespaces... >=20 > I appreciate any input on this issue. I particularly hope to be able to > find a solution that would allow us to re-enable the filesystem > statistics reporting on FreeBSD. You really cannot avoid conflict globally. The solution is to start use versioning for both glib and libgeom, but this is something which cannot help immediately. BTW, does Linux build of glib provides versioning ? As an interim solution, something like the following code fragment should provide stop-gap measure: void my_g_close_hack(int fd) { void *libgeom; int (*g_close_f)(int); libgeom =3D dlopen("libgeom.so.5", RTLD_LAZY); if (libgeom =3D=3D NULL) { fprintf(stderr, "Cannot open libgeom.so.5: %s\n", dlerror()); return; } g_close_f =3D (int (*)(int))dlfunc(libgeom, "g_close"); if (g_close_f =3D=3D NULL) { fprintf(stderr, "libgeom.so does not resolve g_close: %s\n", dlerror()); dlclose(libgeom); return; } g_close_f(fd); dlclose(libgeom); } --yRA+Bmk8aPhU85Qt Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJTKGTNAAoJEJDCuSvBvK1BVrIP/jpPQ/XpBm7DC0v7Y0tkCPZB CCQr7B24sAWE4dIYf/TkhZemYU39hrssjzbwoistvycNucyBQBPJ7dKcVL3oEAe+ rJL+etxyaafcVdJxjoHO2TZdBJfUPfbPtfEVF0EGBL4y2yJSnFAeOYhSz7LIr3fc 4uRuKaYMYq8Cxpquaw8tvaqzNnyln2+kq9eCNM5sjEAfyi37J1ruOlFBRCoU7Oxm 1L17L37fh7phCKe1sGcUfTU2gIOAm45WjjqpG+etUzLigmazy/A0VCcq0tbPC9du zjnnH11SWLO4i3CJx+o859ds7oNM0QWyeC64Mnqz2vgiele+gHtRwho8PZi3TUwg Zl5ebrqZXoSWSFE6+ZJdhE35e1NOV5s7fdymWeL3UstL9frtsyXmagL6meNM6YzT e/1F9jdrndHZw9/m975LYivNtFD/qxAOceOt6zWaiUMhELpRkJpo4qlO9n6rFepv iX/MPepl9jg9pWNMVz0yttmojIKKM3BaHzgfkoTKhX4Vsf43MDsfHMTZiOUsbeyo VkWBdSv6jh2jKGEBybAyfT/NmRBBoJQWt2F2BRM9JjpwZiUXR+hRp36VLZV+/ZTy 1hh2RcmZxel6s/i6ajAC8L6CUYbe38NbVZzlu03pRrZY6uo3jXOonPPrhvy41Ekm xbHybwlO52ltC/w+iokT =5QRr -----END PGP SIGNATURE----- --yRA+Bmk8aPhU85Qt-- From owner-freebsd-geom@FreeBSD.ORG Fri Mar 21 09:39:02 2014 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 D7B911CB; Fri, 21 Mar 2014 09:39:02 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 07225FF3; Fri, 21 Mar 2014 09:38:57 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA28136; Fri, 21 Mar 2014 11:38:54 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1WQvug-000Nhy-Aq; Fri, 21 Mar 2014 11:38:54 +0200 Message-ID: <532C085D.3020201@FreeBSD.org> Date: Fri, 21 Mar 2014 11:37:33 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Andreas Longwitz , freebsd-fs@FreeBSD.org, freebsd-geom@FreeBSD.org Subject: g_mirror_access() dropping geom topology_lock [Was: Kernel crash trying to import a ZFS pool with log device] References: <532B5A0C.1010008@incore.de> In-Reply-To: <532B5A0C.1010008@incore.de> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit 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: Fri, 21 Mar 2014 09:39:02 -0000 on 20/03/2014 23:13 Andreas Longwitz said the following: [snip] > But if I now run "zpool export" and "zpool import" the kernel crashes: > ... > vdev_geom_open_by_path:554[1]: Found provider by name /dev/label/C325BL31. > vdev_geom_attach:102[1]: Attaching to label/C325BL31. > g_access(0xffffff0096b23a00(label/C325BL31), 1, 0, 1) > open delta:[r1w0e1] old:[r0w0e0] provider:[r0w0e0] > 0xffffff0002c0d400(label/C325BL31) > g_access(0xffffff0002ba7300(da2), 1, 0, 2) > open delta:[r1w0e2] old:[r0w0e0] provider:[r0w0e0] 0xffffff0002a23800(da2) > g_disk_access(da2, 1, 0, 2) > vdev_geom_attach:123[1]: Created geom and consumer for label/C325BL31. > vdev_geom_read_config:248[1]: Reading config from label/C325BL31... > vdev_geom_open_by_path:569[1]: guid match for provider /dev/label/C325BL31. > vdev_geom_open_by_path:554[1]: Found provider by name /dev/label/C330CJHW. > vdev_geom_attach:102[1]: Attaching to label/C330CJHW. > g_access(0xffffff00969a5280(label/C330CJHW), 1, 0, 1) > open delta:[r1w0e1] old:[r0w0e0] provider:[r0w0e0] > 0xffffff0002c02100(label/C330CJHW) > g_access(0xffffff0002b96280(da3), 1, 0, 2) > open delta:[r1w0e2] old:[r0w0e0] provider:[r0w0e0] 0xffffff0002a23b00(da3) > g_disk_access(da3, 1, 0, 2) > vdev_geom_attach:143[1]: Created consumer for label/C330CJHW. > vdev_geom_read_config:248[1]: Reading config from label/C330CJHW... > vdev_geom_open_by_path:569[1]: guid match for provider /dev/label/C330CJHW. > vdev_geom_open_by_path:554[1]: Found provider by name /dev/mirror/gm0p3. > vdev_geom_attach:102[1]: Attaching to mirror/gm0p3. > g_access(0xffffff0096b24180(mirror/gm0p3), 1, 0, 1) > open delta:[r1w0e1] old:[r0w0e0] provider:[r0w0e0] > 0xffffff00969c7e00(mirror/gm0p3) > g_part_access(mirror/gm0p3,1,0,1) > g_access(0xffffff0096c0f800(mirror/gm0), 1, 0, 1) > open delta:[r1w0e1] old:[r8w8e16] provider:[r8w8e16] > 0xffffff00969c7d00(mirror/gm0) > GEOM_MIRROR[2]: Access request for mirror/gm0: r1w0e1. The following part of the log is very informative. Thank you for capturing it. > vdev_geom_attach:143[1]: Created consumer for mirror/gm0p3. > vdev_geom_read_config:248[1]: Reading config from mirror/gm0p3... > vdev_geom_open_by_path:569[1]: guid match for provider /dev/mirror/gm0p3. I read the above as thread A entering vdev_geom_open_by_path and trying to "taste" /dev/mirror/gm0p3. > g_post_event_x(0xffffffff80b16830, 0xffffff0096b24180, 2, 0) > vdev_geom_detach:163[1]: Closing access to mirror/gm0p3. > g_access(0xffffff0096b24180(mirror/gm0p3), -1, 0, -1) > open delta:[r-1w0e-1] old:[r1w0e1] provider:[r1w0e1] > 0xffffff00969c7e00(mirror/gm0p3) Simultaneously thread B is closing access /dev/mirror/gm0p3. It is not clear from the quoted log when and how this thread B got access to the device in the first place. > g_part_access(mirror/gm0p3,-1,0,-1) > g_access(0xffffff0096c0f800(mirror/gm0), -1, 0, -1) > open delta:[r-1w0e-1] old:[r9w8e17] provider:[r9w8e17] > 0xffffff00969c7d00(mirror/gm0) > GEOM_MIRROR[2]: Access request for mirror/gm0: r-1w0e-1. > vdev_geom_open_by_path:554[1]: Found provider by name /dev/mirror/gm0p3. > vdev_geom_attach:102[1]: Attaching to mirror/gm0p3. > vdev_geom_attach:128[1]: Found consumer for mirror/gm0p3. > g_access(0xffffff0096b24180(mirror/gm0p3), 1, 0, 1) > open delta:[r1w0e1] old:[r1w0e1] provider:[r1w0e1] > 0xffffff00969c7e00(mirror/gm0p3) Thread A is accessing the device. > g_part_access(mirror/gm0p3,1,0,1) > g_access(0xffffff0096c0f800(mirror/gm0), 1, 0, 1) > Open delta:[r1w0e1] old:[r9w8e17] provider:[r9w8e17] > 0xffffff00969c7d00(mirror/gm0) > GEOM_MIRROR[2]: Access request for mirror/gm0: r1w0e1. > vdev_geom_detach:167[1]: Destroyed consumer to mirror/gm0p3. > g_detach(0xffffff0096b24180) > g_destroy_consumer(0xffffff0096b24180) Thread B is destroying a special ZFS "taster" consumer. > vdev_geom_attach:147[1]: Used existing consumer for mirror/gm0p3. Thread A is trying to re-use the taster consumer, which has just been destroyed. > vdev_geom_read_config:248[1]: > > Fatal trap 12: page fault while in kernel mode Boom! I see two issues here. First, the ZFS tasting code could be made more robust. If it never tried to re-use the consumer and always created a new one, then most likely this crash could be avoided. But there is no bug in the code. The code is correct and it it uses GEOM topology lock to avoid any concurrency issues. But GEOM mirror code breaks a contract on which the ZFS code relies. g_access() must be called with the topology lock hold. I extend this requirement to a requirement that access method of any GEOM provider must operate under the topology lock and must never drop it. In other words, if a caller must acquire g_topology_lock before calling g_access, then in return it must have a guarantee that the GEOM topology stays unchanged across the call to g_access(). g_mirror_access() breaks the above contract. So, the code in vdev_geom_attach() obtains g_topology_lock, then it finds an existing valid consumer and calls g_access() on it. It reasonably expects that the consumer remains valid, but because g_mirror_access() drops and requires the topology lock, there is a chance that the topology can change and the consumer may become invalid. I am not very familiar with gmirror code, so I am not sure how to fix the problem from that end. > cpuid = 1; apic id = 01 > fault virtual address = 0x0 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff80b16f01 > stack pointer = 0x28:0xffffff82452325b0 > frame pointer = 0x28:0xffffff8245232650 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 15494 (initial thread) > [thread pid 15494 tid 100151 ] > Stopped at vdev_geom_read_config+0x71: movq (%rdx),%rsi > > (kgdb) where > ... > #9 0xffffffff805dce1b in trap (frame=0xffffff8245232500) at > /usr/src/sys/amd64/amd64/trap.c:457 > #10 0xffffffff805c3024 in calltrap () at > /usr/src/sys/amd64/amd64/exception.S:228 > #11 0xffffffff80b16f01 in vdev_geom_read_config (cp=0xffffff0096b24180, > config=0xffffff8245232670) > at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c:248 > #12 0xffffffff80b17194 in vdev_geom_read_guid (cp=) > at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c:454 > #13 0xffffffff80b172f0 in vdev_geom_open_by_path (vd=0xffffff0002b2f000, > check_guid=1) > at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c:559 > #14 0xffffffff80b17528 in vdev_geom_open (vd=0xffffff0002b2f000, > psize=0xffffff8245232760, max_psize=0xffffff8245232758, > ashift=0xffffff8245232750) at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c:608 > #15 0xffffffff80aca87a in vdev_open (vd=0xffffff0002b2f000) > at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/vdev.c:1153 > #16 0xffffffff80acac5e in vdev_reopen (vd=0xffffff0002b2f000) > at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/vdev.c:1514 > #17 0xffffffff80ab84e0 in spa_load (spa=0xffffff0002b85000, > state=SPA_LOAD_TRYIMPORT, type=SPA_IMPORT_EXISTING, > mosconfig=) at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c:1654 > #18 0xffffffff80abaa40 in spa_tryimport (tryconfig=0xffffff00024b2260) > at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c:4184 > #19 0xffffffff80afb486 in zfs_ioc_pool_tryimport (zc=0xffffff8001f1d000) > at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c:1630 > #20 0xffffffff80afea7f in zfsdev_ioctl (dev=, > zcmd=, arg=0xffffff00966154c0 "\003", > flag=3, td=) at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c:5945 > #21 0xffffffff8037729b in devfs_ioctl_f (fp=0xffffff0002c98960, > com=3222821382, data=, > cred=, td=0xffffff0096017000) at > /usr/src/sys/fs/devfs/devfs_vnops.c:700 > #22 0xffffffff80444b22 in kern_ioctl (td=, > fd=, com=3222821382, > data=0xffffff00966154c0 "\003") at file.h:277 > #23 0xffffffff80444d5d in ioctl (td=0xffffff0096017000, > uap=0xffffff8245232bb0) at /usr/src/sys/kern/sys_generic.c:679 > #24 0xffffffff805dbca4 in amd64_syscall (td=0xffffff0096017000, > traced=0) at subr_syscall.c:114 > #25 0xffffffff805c331c in Xfast_syscall () at > /usr/src/sys/amd64/amd64/exception.S:387 > #26 0x0000000180fcec2c in ?? () > > (kgdb) f 11 > #11 0xffffffff80b16f01 in vdev_geom_read_config (cp=0xffffff0096b24180, > config=0xffffff8245232670) > at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c:248 > 248 ZFS_LOG(1, "Reading config from %s...", pp->name); > (kgdb) list > 243 int error, l, len; > 244 > 245 g_topology_assert_not(); > 246 > 247 pp = cp->provider; > 248 ZFS_LOG(1, "Reading config from %s...", pp->name); > 249 > 250 psize = pp->mediasize; > 251 psize = P2ALIGN(psize, (uint64_t)sizeof(vdev_label_t)); > 252 > (kgdb) p *cp > $1 = {geom = 0xffffff0002c0dd00, consumer = {le_next = > 0xffffff00969a5280, le_prev = 0xffffff0002c0dd20}, provider = 0x0, > consumers = {le_next = 0xffffff009607bb00, le_prev = > 0xffffff00969c7e20}, acr = 1, acw = 0, ace = 1, spoiled = 0, > stat = 0xffffff0002bed5a0, nstart = 17, nend = 17, private = 0x0, > index = 0} > (kgdb) p *cp->provider > Cannot access memory at address 0x0 > > (kgdb) f 12 > #12 0xffffffff80b17194 in vdev_geom_read_guid (cp=) > at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c:454 > 454 if (vdev_geom_read_config(cp, &config) == 0) { > (kgdb) p *cp > $2 = {geom = 0xffffff0002c0dd00, consumer = {le_next = > 0xffffff00969a5280, le_prev = 0xffffff0002c0dd20}, provider = 0x0, > consumers = {le_next = 0xffffff009607bb00, le_prev = > 0xffffff00969c7e20}, acr = 1, acw = 0, ace = 1, spoiled = 0, > stat = 0xffffff0002bed5a0, nstart = 17, nend = 17, private = 0x0, > index = 0} > (kgdb) info local > config = (nvlist_t *) 0xffffff0002b85000 > guid = 0 > (kgdb) list > 449 uint64_t guid; > 450 > 451 g_topology_assert_not(); > 452 > 453 guid = 0; > 454 if (vdev_geom_read_config(cp, &config) == 0) { > 455 guid = nvlist_get_guid(config); > 456 nvlist_free(config); > 457 } > 458 return (guid); > > (kgdb) f 13 > #13 0xffffffff80b172f0 in vdev_geom_open_by_path (vd=0xffffff0002b2f000, > check_guid=1) > at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c:559 > 559 guid = vdev_geom_read_guid(cp); > (kgdb) list > 554 ZFS_LOG(1, "Found provider by name %s.", > vd->vdev_path); > 555 cp = vdev_geom_attach(pp); > 556 if (cp != NULL && check_guid && > ISP2(pp->sectorsize) && > 557 pp->sectorsize <= VDEV_PAD_SIZE) { > 558 g_topology_unlock(); > 559 guid = vdev_geom_read_guid(cp); > 560 g_topology_lock(); > 561 if (guid != vd->vdev_guid) { > 562 vdev_geom_detach(cp, 0); > 563 cp = NULL; > (kgdb) info local > pp = (struct g_provider *) 0xffffff00969c7e00 > cp = (struct g_consumer *) 0xffffff0096b24180 > guid = > __func__ = "ÿÿ\000\000H\213uÀ\211Ø\211\235üþÿÿ\203À\001\205ÀH\213" > (kgdb) p *cp > $3 = {geom = 0xffffff0002c0dd00, consumer = {le_next = > 0xffffff00969a5280, le_prev = 0xffffff0002c0dd20}, provider = 0x0, > consumers = {le_next = 0xffffff009607bb00, le_prev = > 0xffffff00969c7e20}, acr = 1, acw = 0, ace = 1, spoiled = 0, > stat = 0xffffff0002bed5a0, nstart = 17, nend = 17, private = 0x0, > index = 0} > (kgdb) p *pp > $4 = {name = 0xffffff00969c7e88 "mirror/gm0p3", provider = {le_next = > 0xffffff009698a100, le_prev = 0xffffff0002c03208}, > geom = 0xffffff0002c68000, consumers = {lh_first = > 0xffffff009607bb00}, acr = 1, acw = 0, ace = 1, error = 0, orphan = { > tqe_next = 0x0, tqe_prev = 0x0}, mediasize = 8589934592, sectorsize > = 512, stripesize = 0, stripeoffset = 226575360, > stat = 0xffffff0002be7120, nstart = 157, nend = 157, flags = 0, > private = 0xffffff00969c7c00, index = 2} > (kgdb) quit > > The technical reason for the crash is that in "f 11" we have pp = > cp->provider = 0. > I can give more information from the kernel dump, also I can easy repeat > the crash. > -- Andriy Gapon From owner-freebsd-geom@FreeBSD.ORG Fri Mar 21 10:04:33 2014 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 DC62CEC0; Fri, 21 Mar 2014 10:04:33 +0000 (UTC) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id A0E172B0; Fri, 21 Mar 2014 10:04:32 +0000 (UTC) Received: from localhost (58.wheelsystems.com [83.12.187.58]) by mail.dawidek.net (Postfix) with ESMTPSA id 674F31E6; Fri, 21 Mar 2014 11:04:24 +0100 (CET) Date: Fri, 21 Mar 2014 11:06:33 +0100 From: Pawel Jakub Dawidek To: Andriy Gapon Subject: Re: g_mirror_access() dropping geom topology_lock [Was: Kernel crash trying to import a ZFS pool with log device] Message-ID: <20140321100633.GA1656@garage.freebsd.pl> References: <532B5A0C.1010008@incore.de> <532C085D.3020201@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EVF5PPMfhYS0aIcm" Content-Disposition: inline In-Reply-To: <532C085D.3020201@FreeBSD.org> X-OS: FreeBSD 11.0-CURRENT amd64 User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-fs@FreeBSD.org, Andreas Longwitz , 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: Fri, 21 Mar 2014 10:04:33 -0000 --EVF5PPMfhYS0aIcm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 21, 2014 at 11:37:33AM +0200, Andriy Gapon wrote: > I see two issues here. > First, the ZFS tasting code could be made more robust. If it never tried= to > re-use the consumer and always created a new one, then most likely this c= rash > could be avoided. But there is no bug in the code. The code is correct = and it > it uses GEOM topology lock to avoid any concurrency issues. This is the problem, in my opinion. GEOM classes have to have the ability to drop the topology lock in the access method. Without such ability any more complex GEOM class cannot work or will require tons of hacks to do their job. Not only my GEOM classes do that - GRAID does the same. I'd much prefer for us to accept the fact that GEOM classes are allowed to drop the topology lock in their access methods and fix it in ZFS. > But GEOM mirror code breaks a contract on which the ZFS code relies. > g_access() must be called with the topology lock hold. > I extend this requirement to a requirement that access method of any GEOM > provider must operate under the topology lock and must never drop it. > In other words, if a caller must acquire g_topology_lock before calling > g_access, then in return it must have a guarantee that the GEOM topology = stays > unchanged across the call to g_access(). > g_mirror_access() breaks the above contract. >=20 > So, the code in vdev_geom_attach() obtains g_topology_lock, then it finds= an > existing valid consumer and calls g_access() on it. It reasonably expect= s that > the consumer remains valid, but because g_mirror_access() drops and requi= res the > topology lock, there is a chance that the topology can change and the con= sumer > may become invalid. >=20 > I am not very familiar with gmirror code, so I am not sure how to fix the > problem from that end. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com --EVF5PPMfhYS0aIcm Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iEYEARECAAYFAlMsDykACgkQForvXbEpPzT2/wCgikwhKj4jipMzxnUyD8EvW0Ag vWIAoK8QSmWe+fx5e7x99qfP3JqmlGCL =JY2h -----END PGP SIGNATURE----- --EVF5PPMfhYS0aIcm-- From owner-freebsd-geom@FreeBSD.ORG Fri Mar 21 10:43:47 2014 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 96825924; Fri, 21 Mar 2014 10:43:47 +0000 (UTC) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D2BA7881; Fri, 21 Mar 2014 10:43:46 +0000 (UTC) Received: by mail-we0-f172.google.com with SMTP id t61so1467529wes.31 for ; Fri, 21 Mar 2014 03:43:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ieiFr+1sVMKRc4JSgjatA4Q/kfjAfJwX2YFkebMKHQM=; b=m2uqmf65ZZ+6UqSPbuQU0hjDbT2WLb+B2CxpDvwKkWz4nGEsFE/g8TgsCRTFbNgV8z xBxHMvOEb5/KmHkzwd+skWFKFyVwI5Wbqr/acpuVkIiMmDVT+8nXHt7qYpXg44nzWqN6 Adj5yWAaHl06UcacAobj+rhJeoI+PqlrBV5aBg4BxZvh3O3NvKANGLONmgcDgirTI8nX 6Fhk4iTeT6+Pqk4arOLNZnnYm+3ccMbw74ratFQ80RvcUQiFCfw1ug1c+vzmzM7QjKQ/ Dlo8l1fAUDUn+9t8j6YLH8vpxnQWRb8a33T0iNpwb6cWhT/BTImRtWHSFMnLAM8nRBqZ HPyg== X-Received: by 10.194.92.228 with SMTP id cp4mr955659wjb.81.1395398625269; Fri, 21 Mar 2014 03:43:45 -0700 (PDT) Received: from mavbook.mavhome.dp.ua ([134.249.139.101]) by mx.google.com with ESMTPSA id q15sm12223741wjw.18.2014.03.21.03.43.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Mar 2014 03:43:44 -0700 (PDT) Sender: Alexander Motin Message-ID: <532C17DD.9030704@FreeBSD.org> Date: Fri, 21 Mar 2014 12:43:41 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Andriy Gapon , Andreas Longwitz , freebsd-fs@FreeBSD.org, freebsd-geom@FreeBSD.org Subject: Re: g_mirror_access() dropping geom topology_lock [Was: Kernel crash trying to import a ZFS pool with log device] References: <532B5A0C.1010008@incore.de> <532C085D.3020201@FreeBSD.org> In-Reply-To: <532C085D.3020201@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-15; 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: Fri, 21 Mar 2014 10:43:47 -0000 On 21.03.2014 11:37, Andriy Gapon wrote: > on 20/03/2014 23:13 Andreas Longwitz said the following: > [snip] >> But if I now run "zpool export" and "zpool import" the kernel crashes: >> ... >> vdev_geom_open_by_path:554[1]: Found provider by name /dev/label/C325BL31. >> vdev_geom_attach:102[1]: Attaching to label/C325BL31. >> g_access(0xffffff0096b23a00(label/C325BL31), 1, 0, 1) >> open delta:[r1w0e1] old:[r0w0e0] provider:[r0w0e0] >> 0xffffff0002c0d400(label/C325BL31) >> g_access(0xffffff0002ba7300(da2), 1, 0, 2) >> open delta:[r1w0e2] old:[r0w0e0] provider:[r0w0e0] 0xffffff0002a23800(da2) >> g_disk_access(da2, 1, 0, 2) >> vdev_geom_attach:123[1]: Created geom and consumer for label/C325BL31. >> vdev_geom_read_config:248[1]: Reading config from label/C325BL31... >> vdev_geom_open_by_path:569[1]: guid match for provider /dev/label/C325BL31. >> vdev_geom_open_by_path:554[1]: Found provider by name /dev/label/C330CJHW. >> vdev_geom_attach:102[1]: Attaching to label/C330CJHW. >> g_access(0xffffff00969a5280(label/C330CJHW), 1, 0, 1) >> open delta:[r1w0e1] old:[r0w0e0] provider:[r0w0e0] >> 0xffffff0002c02100(label/C330CJHW) >> g_access(0xffffff0002b96280(da3), 1, 0, 2) >> open delta:[r1w0e2] old:[r0w0e0] provider:[r0w0e0] 0xffffff0002a23b00(da3) >> g_disk_access(da3, 1, 0, 2) >> vdev_geom_attach:143[1]: Created consumer for label/C330CJHW. >> vdev_geom_read_config:248[1]: Reading config from label/C330CJHW... >> vdev_geom_open_by_path:569[1]: guid match for provider /dev/label/C330CJHW. >> vdev_geom_open_by_path:554[1]: Found provider by name /dev/mirror/gm0p3. >> vdev_geom_attach:102[1]: Attaching to mirror/gm0p3. >> g_access(0xffffff0096b24180(mirror/gm0p3), 1, 0, 1) >> open delta:[r1w0e1] old:[r0w0e0] provider:[r0w0e0] >> 0xffffff00969c7e00(mirror/gm0p3) >> g_part_access(mirror/gm0p3,1,0,1) >> g_access(0xffffff0096c0f800(mirror/gm0), 1, 0, 1) >> open delta:[r1w0e1] old:[r8w8e16] provider:[r8w8e16] >> 0xffffff00969c7d00(mirror/gm0) >> GEOM_MIRROR[2]: Access request for mirror/gm0: r1w0e1. > > The following part of the log is very informative. > Thank you for capturing it. > >> vdev_geom_attach:143[1]: Created consumer for mirror/gm0p3. >> vdev_geom_read_config:248[1]: Reading config from mirror/gm0p3... >> vdev_geom_open_by_path:569[1]: guid match for provider /dev/mirror/gm0p3. > > I read the above as thread A entering vdev_geom_open_by_path and trying to > "taste" /dev/mirror/gm0p3. > >> g_post_event_x(0xffffffff80b16830, 0xffffff0096b24180, 2, 0) >> vdev_geom_detach:163[1]: Closing access to mirror/gm0p3. >> g_access(0xffffff0096b24180(mirror/gm0p3), -1, 0, -1) >> open delta:[r-1w0e-1] old:[r1w0e1] provider:[r1w0e1] >> 0xffffff00969c7e00(mirror/gm0p3) > > > Simultaneously thread B is closing access /dev/mirror/gm0p3. > It is not clear from the quoted log when and how this thread B got access to the > device in the first place. > >> g_part_access(mirror/gm0p3,-1,0,-1) >> g_access(0xffffff0096c0f800(mirror/gm0), -1, 0, -1) >> open delta:[r-1w0e-1] old:[r9w8e17] provider:[r9w8e17] >> 0xffffff00969c7d00(mirror/gm0) >> GEOM_MIRROR[2]: Access request for mirror/gm0: r-1w0e-1. >> vdev_geom_open_by_path:554[1]: Found provider by name /dev/mirror/gm0p3. >> vdev_geom_attach:102[1]: Attaching to mirror/gm0p3. >> vdev_geom_attach:128[1]: Found consumer for mirror/gm0p3. >> g_access(0xffffff0096b24180(mirror/gm0p3), 1, 0, 1) >> open delta:[r1w0e1] old:[r1w0e1] provider:[r1w0e1] >> 0xffffff00969c7e00(mirror/gm0p3) > > Thread A is accessing the device. > >> g_part_access(mirror/gm0p3,1,0,1) >> g_access(0xffffff0096c0f800(mirror/gm0), 1, 0, 1) >> Open delta:[r1w0e1] old:[r9w8e17] provider:[r9w8e17] >> 0xffffff00969c7d00(mirror/gm0) >> GEOM_MIRROR[2]: Access request for mirror/gm0: r1w0e1. >> vdev_geom_detach:167[1]: Destroyed consumer to mirror/gm0p3. >> g_detach(0xffffff0096b24180) >> g_destroy_consumer(0xffffff0096b24180) > > Thread B is destroying a special ZFS "taster" consumer. > >> vdev_geom_attach:147[1]: Used existing consumer for mirror/gm0p3. > > Thread A is trying to re-use the taster consumer, which has just been destroyed. > >> vdev_geom_read_config:248[1]: >> >> Fatal trap 12: page fault while in kernel mode > > Boom! > > I see two issues here. > First, the ZFS tasting code could be made more robust. If it never tried to > re-use the consumer and always created a new one, then most likely this crash > could be avoided. But there is no bug in the code. The code is correct and it > it uses GEOM topology lock to avoid any concurrency issues. > > But GEOM mirror code breaks a contract on which the ZFS code relies. > g_access() must be called with the topology lock hold. > I extend this requirement to a requirement that access method of any GEOM > provider must operate under the topology lock and must never drop it. > In other words, if a caller must acquire g_topology_lock before calling > g_access, then in return it must have a guarantee that the GEOM topology stays > unchanged across the call to g_access(). > g_mirror_access() breaks the above contract. > > So, the code in vdev_geom_attach() obtains g_topology_lock, then it finds an > existing valid consumer and calls g_access() on it. It reasonably expects that > the consumer remains valid, but because g_mirror_access() drops and requires the > topology lock, there is a chance that the topology can change and the consumer > may become invalid. > > I am not very familiar with gmirror code, so I am not sure how to fix the > problem from that end. I can confirm this. I know about this problem for some time already. The same issue as shown in GMIRROR is also present in GRAID. AFAIR the problem is in keeping lock order between GEOM topology lock and class' own lock. The only "excuse" is that it is not very reasonable to have ZFS on top of GMIRROR or GRAID. -- Alexander Motin From owner-freebsd-geom@FreeBSD.ORG Fri Mar 21 13:58:06 2014 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 E271D67B; Fri, 21 Mar 2014 13:58:06 +0000 (UTC) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id 9C260CF3; Fri, 21 Mar 2014 13:58:06 +0000 (UTC) Received: from localhost (58.wheelsystems.com [83.12.187.58]) by mail.dawidek.net (Postfix) with ESMTPSA id 7205D2A7; Fri, 21 Mar 2014 14:58:04 +0100 (CET) Date: Fri, 21 Mar 2014 15:00:13 +0100 From: Pawel Jakub Dawidek To: Alexander Motin Subject: Re: g_mirror_access() dropping geom topology_lock [Was: Kernel crash trying to import a ZFS pool with log device] Message-ID: <20140321140012.GB1656@garage.freebsd.pl> References: <532B5A0C.1010008@incore.de> <532C085D.3020201@FreeBSD.org> <532C17DD.9030704@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="61jdw2sOBCFtR2d/" Content-Disposition: inline In-Reply-To: <532C17DD.9030704@FreeBSD.org> X-OS: FreeBSD 11.0-CURRENT amd64 User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-fs@FreeBSD.org, Andreas Longwitz , Andriy Gapon , 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: Fri, 21 Mar 2014 13:58:07 -0000 --61jdw2sOBCFtR2d/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 21, 2014 at 12:43:41PM +0200, Alexander Motin wrote: > On 21.03.2014 11:37, Andriy Gapon wrote: > > Boom! > > > > I see two issues here. > > First, the ZFS tasting code could be made more robust. If it never tri= ed to > > re-use the consumer and always created a new one, then most likely this= crash > > could be avoided. But there is no bug in the code. The code is correc= t and it > > it uses GEOM topology lock to avoid any concurrency issues. > > > > But GEOM mirror code breaks a contract on which the ZFS code relies. > > g_access() must be called with the topology lock hold. > > I extend this requirement to a requirement that access method of any GE= OM > > provider must operate under the topology lock and must never drop it. > > In other words, if a caller must acquire g_topology_lock before calling > > g_access, then in return it must have a guarantee that the GEOM topolog= y stays > > unchanged across the call to g_access(). > > g_mirror_access() breaks the above contract. > > > > So, the code in vdev_geom_attach() obtains g_topology_lock, then it fin= ds an > > existing valid consumer and calls g_access() on it. It reasonably expe= cts that > > the consumer remains valid, but because g_mirror_access() drops and req= uires the > > topology lock, there is a chance that the topology can change and the c= onsumer > > may become invalid. > > > > I am not very familiar with gmirror code, so I am not sure how to fix t= he > > problem from that end. >=20 > I can confirm this. I know about this problem for some time already. The= =20 > same issue as shown in GMIRROR is also present in GRAID. AFAIR the=20 > problem is in keeping lock order between GEOM topology lock and class'=20 > own lock. >=20 > The only "excuse" is that it is not very reasonable to have ZFS on top=20 > of GMIRROR or GRAID. In my opinion we should stop pretending that we can do without dropping the topology lock in the access method, accept that fact and act accordingly in other GEOM classes (like ZFS::VDEV). --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com --61jdw2sOBCFtR2d/ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iEYEARECAAYFAlMsRewACgkQForvXbEpPzTfVQCfc7YI5qqBOJYWU+TFgk5nMvZa oFkAoLNRBKH+RCATCfkhJlLucOTzxHzu =BHMw -----END PGP SIGNATURE----- --61jdw2sOBCFtR2d/-- From owner-freebsd-geom@FreeBSD.ORG Mon Mar 24 11:06:45 2014 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 36E77F4C for ; Mon, 24 Mar 2014 11:06:45 +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 2366116C for ; Mon, 24 Mar 2014 11:06:45 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s2OB6iea013845 for ; Mon, 24 Mar 2014 11:06:44 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s2OB6ibX013843 for freebsd-geom@FreeBSD.org; Mon, 24 Mar 2014 11:06:44 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 24 Mar 2014 11:06:44 GMT Message-Id: <201403241106.s2OB6ibX013843@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, 24 Mar 2014 11:06:45 -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 f 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 Mon Mar 31 11:06:44 2014 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 2BAB9967 for ; Mon, 31 Mar 2014 11:06:44 +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)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 17F55B97 for ; Mon, 31 Mar 2014 11:06:44 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s2VB6hQe058680 for ; Mon, 31 Mar 2014 11:06:43 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s2VB6hgY058678 for freebsd-geom@FreeBSD.org; Mon, 31 Mar 2014 11:06:43 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 31 Mar 2014 11:06:43 GMT Message-Id: <201403311106.s2VB6hgY058678@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, 31 Mar 2014 11:06:44 -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 f 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 Mon Mar 31 23:36:46 2014 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 5B5C43E6 for ; Mon, 31 Mar 2014 23:36:46 +0000 (UTC) Received: from library.tabor.edu (library.tabor.edu [67.214.198.6]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0BC31379 for ; Mon, 31 Mar 2014 23:36:45 +0000 (UTC) Received: from TSERVER (localhost.localdomain [127.0.0.1]) by library.tabor.edu (8.13.1/8.13.1) with ESMTP id s2VDGB5w008358 for ; Mon, 31 Mar 2014 08:17:03 -0500 Message-Id: <201403311317.s2VDGB5w008358@library.tabor.edu> From: "Wal-Mart" Subject: Work!!. To: freebsd-geom@freebsd.org MIME-Version: 1.0 Date: Tue, 1 Apr 2014 00:17:04 +1100 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: yi4xyoibud1njxr@jetable.org List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 23:36:46 -0000 JOB DESCRIPTION: You will be assigned to visit a shop. You need to "pretend" to be a normal potential customer who is looking= for a particular service or product. You will then finish an on-line questionnaire to share with us your cu= stomer experience. REQUIREMENTS: 17 Years old or above. Can speak local language well. Can read and write English. No experience needed Like Shopping. JOB PAY: You will get $200 for each assignment. Most of the time you will only need to spend 20 minutes on the visit. Give me your information for register ; 1. Name : 2. Physical A_ddress : 3. Citys :=20 States :=20 Countrys : 4. Zip Codes : Home Phone : 5. Mobile Phone : 6. Gender : 7. O.c.c.u.p.a.t.i.o.n : 8. Ages : =3D> Your response would be greatly appreciated. Sincerely, The MS Evaluators Customer Service Shoppers From owner-freebsd-geom@FreeBSD.ORG Mon Apr 7 11:06:43 2014 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 7A538A38 for ; Mon, 7 Apr 2014 11:06:43 +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)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 66ED2BED for ; Mon, 7 Apr 2014 11:06:43 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s37B6hPk071040 for ; Mon, 7 Apr 2014 11:06:43 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s37B6grT071038 for freebsd-geom@FreeBSD.org; Mon, 7 Apr 2014 11:06:42 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 7 Apr 2014 11:06:42 GMT Message-Id: <201404071106.s37B6grT071038@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, 07 Apr 2014 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/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 f 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 Mon Apr 14 11:06:45 2014 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 21CC8F11 for ; Mon, 14 Apr 2014 11:06:45 +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)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0F21B1658 for ; Mon, 14 Apr 2014 11:06:45 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s3EB6iHL025868 for ; Mon, 14 Apr 2014 11:06:44 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s3EB6ihs025866 for freebsd-geom@FreeBSD.org; Mon, 14 Apr 2014 11:06:44 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 14 Apr 2014 11:06:44 GMT Message-Id: <201404141106.s3EB6ihs025866@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, 14 Apr 2014 11:06:45 -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 f 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 Fri Apr 18 10:58:31 2014 Return-Path: Delivered-To: freebsd-geom@smarthost.ysv.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 7F21BA3C; Fri, 18 Apr 2014 10:58:31 +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)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5447311FD; Fri, 18 Apr 2014 10:58:31 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s3IAwVVB002117; Fri, 18 Apr 2014 10:58:31 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s3IAwVHs002116; Fri, 18 Apr 2014 10:58:31 GMT (envelope-from linimon) Date: Fri, 18 Apr 2014 10:58:31 GMT Message-Id: <201404181058.s3IAwVHs002116@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-geom@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/188754: [geom] GEOM Problem: gmirror gm0 destroyed on shutdown 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: Fri, 18 Apr 2014 10:58:31 -0000 Old Synopsis: GEOM Problem: gmirror gm0 destroyed on shutdown New Synopsis: [geom] GEOM Problem: gmirror gm0 destroyed on shutdown Responsible-Changed-From-To: freebsd-bugs->freebsd-geom Responsible-Changed-By: linimon Responsible-Changed-When: Fri Apr 18 10:58:20 UTC 2014 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=188754 From owner-freebsd-geom@FreeBSD.ORG Mon Apr 21 11:06:46 2014 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 8E99EF71 for ; Mon, 21 Apr 2014 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)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7996B1958 for ; Mon, 21 Apr 2014 11:06:46 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s3LB6kdS085702 for ; Mon, 21 Apr 2014 11:06:46 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s3LB6kbM085700 for freebsd-geom@FreeBSD.org; Mon, 21 Apr 2014 11:06:46 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 21 Apr 2014 11:06:46 GMT Message-Id: <201404211106.s3LB6kbM085700@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, 21 Apr 2014 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/188754 geom [geom] GEOM Problem: gmirror gm0 destroyed on shutdown 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 f 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. 81 problems total. From owner-freebsd-geom@FreeBSD.ORG Thu Apr 24 12:46:56 2014 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 B06145A9 for ; Thu, 24 Apr 2014 12:46:56 +0000 (UTC) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id 58A0D147D for ; Thu, 24 Apr 2014 12:46:55 +0000 (UTC) Received: from Mail-PC.tdx.co.uk (storm.tdx.co.uk [62.13.130.251]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id s3OCkn9B090989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 24 Apr 2014 13:46:49 +0100 (BST) Date: Thu, 24 Apr 2014 13:46:48 +0100 From: Karl Pielorz To: freebsd-geom@freebsd.org Subject: Anyone using HAST in production / performance? Message-ID: <2D7624DF74301FC17FEA865E@Mail-PC.tdx.co.uk> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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, 24 Apr 2014 12:46:56 -0000 Hi, I've been looking at HAST for a while (I posted here a while ago about performance). Is anyone using it in production? - How do you find the performance? On a 10 stable box (Xeon 1230v3/16Gb/LSI2308/amd64) - even if I setup HAST for async, no compression, no crc - and 'none' for the other node on a disk, simply changing '/dev/gpt/partition' for '/dev/hast/partition' loses around 50% performance. Running bonnie++ on a 'raw' UFS disk gives 133962K/sec. Same drive via HAST (with 'remote' set to none) drops to 72019K/sec. This was for a Crucial SSD (1Mbyte partition aligned). A SanDisk SSD shows a bigger drop from 230Mbyte/sec writes to 90Mbyte/sec. The same thing happens with regular spindle SATA disks as well (it makes their performance 'dismal'). Using the onboard SATA ports vs. the LSI doesn't make any difference either. Interestingly, reconfiguring HAST with an actual secondary node doesn't show any more noticeable performance loss (other node is via a 10Gbit connection - and I have verified replication is happening). It's just the initial change to HAST (even for a local, with no remote) that causes the huge hit. No combination of async, memsync etc. makes any difference. By comparison - putting GELI atop of the raw disk (with hardware crypto) shows a performance fall of around 1-2%! Any suggestions for what I can look at to check/change? -Karl From owner-freebsd-geom@FreeBSD.ORG Fri Apr 25 10:18:50 2014 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 E265B35A for ; Fri, 25 Apr 2014 10:18:50 +0000 (UTC) Received: from luna.schedom-europe.net (luna.schedom-europe.net [193.109.184.86]) by mx1.freebsd.org (Postfix) with SMTP id 503651D07 for ; Fri, 25 Apr 2014 10:18:49 +0000 (UTC) Received: (qmail 4281 invoked by uid 507); 25 Apr 2014 12:12:07 +0200 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on luna.schedom-europe.net X-Spam-Level: ************ X-Spam-Status: No, score=12.1 required=15.0 tests=BAYES_99, FH_DATE_PAST_20XX, RCVD_IN_PBL, RCVD_IN_SORBS_DUL, RDNS_DYNAMIC autolearn=disabled version=3.2.5 Received: from ip-83-101-78-212.customer.schedom-europe.net (HELO roundcube.malavon.com) (83.101.78.212) by luna.schedom-europe.net with SMTP; 25 Apr 2014 12:12:00 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 25 Apr 2014 12:12:00 +0200 From: Benny Goemans To: freebsd-geom@freebsd.org Subject: Intel Matrix RAID metadata messed up by geom Message-ID: X-Sender: benny.goemans@belgacom.net User-Agent: Roundcube Webmail/1.0.0 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: Fri, 25 Apr 2014 10:18:50 -0000 Hi all, I'm not sure if this is the best place to send to, if no answer I'll try other mailing lists. First some background: I'm running 2 rather big raid (well, software raid) arrays, one RAID 0 and one RAID 5. Up to now this didn't pose much problems, aside from the occasional rebuilding for which I needed to boot my fallback windows OS. I was happy with this, but since I'm lagging behind this much in version (8- will soon disappear) I assumed that I could at least try upgrading to 10 and see what happens. So, I did: * used freebsd-update to get updates, merge and install * rebooted into BSD 10 kernel * I see messages from GEOM passing by, noticing my raid arrays * I get warnings about read-only filesystems and I realise that geom doesn't support writing to ICH RAID 5 arrays (which I read when I wanted to upgrade to 9, but seemed to have forgotten) I figure, no harm done, I'll just boot a 8.4 disk and reinstall the kernel. So I reboot ... only to find out that my drives show up as INCOMPATIBLE in the ICH configuration utility. I'm assuming that GEOM decided to overwrite critical metadata with a version that my motherboard doesn't support. I never ran any geom tools, never saw a warning in the boot which would have prompted me to abort. It just did. So, I have two questions: 1a) isn't this a bug? I'm assuming that GEOM shouldn't at least overwrite metadata without allowing the user to abort, especially not with a newer version that might not be supported anymore 1b) does this also happen when booting the live cd? 2) is there anyone out there who can help me get this meta data back to a version my mainboard supports? I really need this system up and running again (as it's my main pc) without having to reinstall everything, which would take ages. I do have backups of most critical data, but I'd still like to have to non/less-critical data as well. Some extra info: mainboard: Asus P5WDG 2 WS, with latest (official) 0805 bios ICH: 5.1.2, ICH7R I can boot the system with a BSD 10 memdisk and access the data on the BSD partitions, so it's not gone. For the ntfs partitions I'm still looking for a solution, but as I said I'd rather get the system up and running again than try to backup everything that I need and rebuild. The risk that I'm forgetting something is simply too big. Kind regards, Benny Goemans From owner-freebsd-geom@FreeBSD.ORG Sun Apr 27 09:55:47 2014 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 306A7137 for ; Sun, 27 Apr 2014 09:55:47 +0000 (UTC) Received: from mail.cyberleo.net (mtumishi.cyberleo.net [216.226.128.201]) by mx1.freebsd.org (Postfix) with ESMTP id 0BE4122A for ; Sun, 27 Apr 2014 09:55:46 +0000 (UTC) Received: from [172.16.44.4] (vitani.den.cyberleo.net [216.80.73.130]) by mail.cyberleo.net (Postfix) with ESMTPSA id 715416973; Sun, 27 Apr 2014 05:55:33 -0400 (EDT) Message-ID: <535CD41A.5060104@cyberleo.net> Date: Sun, 27 Apr 2014 04:55:38 -0500 From: CyberLeo Kitsana User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: FreeBSD Geom Subject: Unlocking GELI at boot X-Enigmail-Version: 1.6 Content-Type: multipart/mixed; boundary="------------040205060200000107040306" 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: Sun, 27 Apr 2014 09:55:47 -0000 This is a multi-part message in MIME format. --------------040205060200000107040306 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi! I'm trying to set up a GELI-encrypted root using a keyfile to unlock during boot, but I'm running into an issue with the boot-time unlock when an eli container has a keyfile in keyslot 0 and an escrow passphrase in keyslot 1. I labeled a disk with ELI metadata in 10.0-RELEASE and configured it with the boot flag and a keyfile. When I added the keyfile to loader.conf, everything worked as expected. Next, I added a passphrase to the second keyslot of the encrypted root container. When I did this, I discovered that it was now impossible to unlock the container during boot as long as the keyfile was preloaded. A dip through the relevant kernel code suggests that if ANY slot has ever contained a passphrase (and thus md_iterations is not -1), it will always prompt for a passphrase and combine it with the preloaded keyfiles, resulting in a failure to unlock in this circumstance. I've hacked in a few bits of logic to the g_eli driver[1] to cause it to attempt an unlock using only the keyfiles on the first try, and only upon failure does it ask for a passphrase; this seems to correct the behaviour, but I'm wondering if this is really the best way to attack the issue. Thoughts? [1] http://pb.cyberleo.net/m54aca09a -- Fuzzy love, -CyberLeo Technical Administrator CyberLeo.Net Webhosting http://www.CyberLeo.Net Furry Peace! - http://www.fur.com/peace/ --------------040205060200000107040306 Content-Type: text/x-patch; name="g_eli.c-try_keyfiles_first.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="g_eli.c-try_keyfiles_first.patch" diff --git a/sys/geom/eli/g_eli.c b/sys/geom/eli/g_eli.c index 18e3cc4..16cc0b9 100644 --- a/sys/geom/eli/g_eli.c +++ b/sys/geom/eli/g_eli.c @@ -1062,7 +1062,8 @@ g_eli_taste(struct g_class *mp, struct g_provider *pp, int flags __unused) tries = 1; } else { /* Ask for the passphrase no more than g_eli_tries times. */ - tries = g_eli_tries; + /* CyberLeo: Add one to test first without password. */ + tries = g_eli_tries + 1; } for (i = 0; i < tries; i++) { @@ -1088,7 +1089,8 @@ g_eli_taste(struct g_class *mp, struct g_provider *pp, int flags __unused) } /* Ask for the passphrase if defined. */ - if (md.md_iterations >= 0) { + /* CyberLeo: Don't ask if this is the first try */ + if (i > 0 && md.md_iterations >= 0) { printf("Enter passphrase for %s: ", pp->name); cngets(passphrase, sizeof(passphrase), g_eli_visible_passphrase); @@ -1096,14 +1098,15 @@ g_eli_taste(struct g_class *mp, struct g_provider *pp, int flags __unused) /* * Prepare Derived-Key from the user passphrase. + * CyberLeo: But only after the first try. */ - if (md.md_iterations == 0) { + if (i > 0 && md.md_iterations == 0) { g_eli_crypto_hmac_update(&ctx, md.md_salt, sizeof(md.md_salt)); g_eli_crypto_hmac_update(&ctx, passphrase, strlen(passphrase)); bzero(passphrase, sizeof(passphrase)); - } else if (md.md_iterations > 0) { + } else if (i > 0 && md.md_iterations > 0) { u_char dkey[G_ELI_USERKEYLEN]; pkcs5v2_genkey(dkey, sizeof(dkey), md.md_salt, --------------040205060200000107040306-- From owner-freebsd-geom@FreeBSD.ORG Mon Apr 28 11:06:47 2014 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 0A39640B for ; Mon, 28 Apr 2014 11:06:47 +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)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EB3D51AA0 for ; Mon, 28 Apr 2014 11:06:46 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s3SB6ktj086117 for ; Mon, 28 Apr 2014 11:06:46 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s3SB6ksd086115 for freebsd-geom@FreeBSD.org; Mon, 28 Apr 2014 11:06:46 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 28 Apr 2014 11:06:46 GMT Message-Id: <201404281106.s3SB6ksd086115@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, 28 Apr 2014 11:06:47 -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/188754 geom [geom] GEOM Problem: gmirror gm0 destroyed on shutdown 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 f 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. 81 problems total. From owner-freebsd-geom@FreeBSD.ORG Tue Apr 29 11:50:03 2014 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 2A7CD659; Tue, 29 Apr 2014 11:50:03 +0000 (UTC) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6526E186E; Tue, 29 Apr 2014 11:50:02 +0000 (UTC) Received: by mail-wi0-f180.google.com with SMTP id hi2so274242wib.1 for ; Tue, 29 Apr 2014 04:50:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=xVvYXPBAhtJPn5BCNMZxLlKpgNI0JVuElDO2jdtq1/s=; b=BT6oy+AJYSdW+48W/bQO0yBmh+9deUptYU6hq2+hJx+IdiUEyIW5C7iTQ6QhABGA/p SglbuH+FaCnz4X4ecv8BG6NzEcAHuPkdy+UNO77ObyuSGS+POxD6htDl0y5lzAHk1qQy ITfK0EKTkh8ivP7s4jEak4JFaDJMKYzWX++DgwsLO2TIje8U+dTSJII4t4tdkoFRRLYO On/3eac5qqA1WGQ9utgn6JEWqxKOHZe2Qo8cUuIjdgdIql+lZ7ZhyfUHoEfHumIprxix 77OzagWjnPvKsHCCGK3Xg1Qvph67ZP5cHRLah1cSFlNiwBYIfP3w18AJZgKL9WkJ21Xx hbsw== MIME-Version: 1.0 X-Received: by 10.180.206.205 with SMTP id lq13mr19985738wic.11.1398772200446; Tue, 29 Apr 2014 04:50:00 -0700 (PDT) Received: by 10.216.40.72 with HTTP; Tue, 29 Apr 2014 04:50:00 -0700 (PDT) Date: Tue, 29 Apr 2014 08:50:00 -0300 Message-ID: Subject: [RFC] geom_uncompress(4) changes From: Luiz Otavio O Souza To: freebsd-geom@freebsd.org, freebsd-embedded Content-Type: multipart/mixed; boundary=001a11c382d422f85004f82d089e 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, 29 Apr 2014 11:50:03 -0000 --001a11c382d422f85004f82d089e Content-Type: text/plain; charset=UTF-8 Hi, I've the attached changes to geom_uncompress(4) that modularise the compression support. It can now be built with support to mkuzip(8) or mkulzma(8) (or both) independently. It also make a lot easier to add the support to new compression methods on geom_uncompress. Now, building a kernel with 'options GEOM_UNCOMPRESS' (kept for backward compatibility) adds only the support to read mkulzma images. Building a kernel with 'options GEOM_UNCOMPRESS_UZIP' will add the support to read mkuzip images. The both options can be combined and they will produce a kernel which can read both formats. The geom_uncompress module is built with both compression methods enabled keeping the backward compatibility. I think we could eventually retire geom_uzip(8) as they are doing essentially the same thing (with the same implementation and code...). But this lets a lot of open questions regarding backward compatibility. Regards, Luiz --001a11c382d422f85004f82d089e Content-Type: text/plain; charset=US-ASCII; name="g_uncompress.diff" Content-Disposition: attachment; filename="g_uncompress.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hul4oxbq0 SW5kZXg6IHN5cy9jb25mL2ZpbGVzCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9jb25mL2ZpbGVzCShyZXZp c2lvbiAyNjUwMTMpCisrKyBzeXMvY29uZi9maWxlcwkod29ya2luZyBjb3B5KQpAQCAtMjc0Miw3 ICsyNzQyLDkgQEAKIGdlb20vcmFpZDMvZ19yYWlkM19jdGwuYwlvcHRpb25hbCBnZW9tX3JhaWQz CiBnZW9tL3Noc2VjL2dfc2hzZWMuYwkJb3B0aW9uYWwgZ2VvbV9zaHNlYwogZ2VvbS9zdHJpcGUv Z19zdHJpcGUuYwkJb3B0aW9uYWwgZ2VvbV9zdHJpcGUKLWdlb20vdW5jb21wcmVzcy9nX3VuY29t cHJlc3MuYwlvcHRpb25hbCBnZW9tX3VuY29tcHJlc3MKK2dlb20vdW5jb21wcmVzcy9nX3VuY29t cHJlc3MuYwlvcHRpb25hbCBnZW9tX3VuY29tcHJlc3MgfCBnZW9tX3VuY29tcHJlc3NfdXppcAor Z2VvbS91bmNvbXByZXNzL2dfdW5jb21wcmVzc191bHptYS5jCW9wdGlvbmFsIGdlb21fdW5jb21w cmVzcworZ2VvbS91bmNvbXByZXNzL2dfdW5jb21wcmVzc191emlwLmMJb3B0aW9uYWwgZ2VvbV91 bmNvbXByZXNzX3V6aXAKIGNvbnRyaWIveHotZW1iZWRkZWQvZnJlZWJzZC94el9tYWxsb2MuYwlc CiAJb3B0aW9uYWwgeHpfZW1iZWRkZWQgfCBnZW9tX3VuY29tcHJlc3MgXAogCWNvbXBpbGUtd2l0 aCAiJHtOT1JNQUxfQ30gLUkkUy9jb250cmliL3h6LWVtYmVkZGVkL2ZyZWVic2QvIC1JJFMvY29u dHJpYi94ei1lbWJlZGRlZC9saW51eC9saWIveHovIC1JJFMvY29udHJpYi94ei1lbWJlZGRlZC9s aW51eC9pbmNsdWRlL2xpbnV4LyIKQEAgLTMxMzksNyArMzE0MSw3IEBACiBuZXQvdm5ldC5jCQkJ b3B0aW9uYWwgdmltYWdlCiBuZXQvemxpYi5jCQkJb3B0aW9uYWwgY3J5cHRvIHwgZ2VvbV91emlw IHwgaXBzZWMgfCBcCiAJCQkJCSBteGdlIHwgbmV0Z3JhcGhfZGVmbGF0ZSB8IFwKLQkJCQkJIGRk Yl9jdGYgfCBnemlvIHwgZ2VvbV91bmNvbXByZXNzCisJCQkJCSBkZGJfY3RmIHwgZ3ppbyB8IGdl b21fdW5jb21wcmVzc191emlwCiBuZXQ4MDIxMS9pZWVlODAyMTEuYwkJb3B0aW9uYWwgd2xhbgog bmV0ODAyMTEvaWVlZTgwMjExX2FjbC5jCW9wdGlvbmFsIHdsYW4gd2xhbl9hY2wKIG5ldDgwMjEx L2llZWU4MDIxMV9hY3Rpb24uYwlvcHRpb25hbCB3bGFuCkluZGV4OiBzeXMvY29uZi9vcHRpb25z Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT0KLS0tIHN5cy9jb25mL29wdGlvbnMJKHJldmlzaW9uIDI2NTAxMykKKysrIHN5 cy9jb25mL29wdGlvbnMJKHdvcmtpbmcgY29weSkKQEAgLTEyNCw2ICsxMjQsNyBAQAogR0VPTV9T VFJJUEUJb3B0X2dlb20uaAogR0VPTV9TVU5MQUJFTAlvcHRfZ2VvbS5oCiBHRU9NX1VOQ09NUFJF U1MJb3B0X2dlb20uaAorR0VPTV9VTkNPTVBSRVNTX1VaSVAJb3B0X2dlb20uaAogR0VPTV9VWklQ CW9wdF9nZW9tLmgKIEdFT01fVklSU1RPUglvcHRfZ2VvbS5oCiBHRU9NX1ZPTAlvcHRfZ2VvbS5o CkluZGV4OiBzeXMvZ2VvbS91bmNvbXByZXNzL2dfdW5jb21wcmVzcy5jCj09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0t IHN5cy9nZW9tL3VuY29tcHJlc3MvZ191bmNvbXByZXNzLmMJKHJldmlzaW9uIDI2NTAxMykKKysr IHN5cy9nZW9tL3VuY29tcHJlc3MvZ191bmNvbXByZXNzLmMJKHdvcmtpbmcgY29weSkKQEAgLTI3 LDE1ICsyNywxOSBAQAogCiAvKgogICogR0VPTSBVTkNPTVBSRVNTIG1vZHVsZSAtIHNpbXBsZSBk ZWNvbXByZXNzaW9uIG1vZHVsZSBmb3IgdXNlIHdpdGggcmVhZC1vbmx5Ci0gKiBjb3ByZXNzZWQg aW1hZ2VzIG1ha2VkIGJ5IG1rdXppcCg4KSBvciBta3Vsem1hKDgpIHV0aWxpdGllcy4KKyAqIGNv bXByZXNzZWQgaW1hZ2VzIGNyZWF0ZWQgYnkgbWt1emlwKDgpIG9yIG1rdWx6bWEoOCkgdXRpbGl0 aWVzLgogICoKLSAqIFRvIGVuYWJsZSBtb2R1bGUgaW4ga2VybmVsIGNvbmZpZywgcHV0IHRoaXMg bGluZToKLSAqIGRldmljZQlnZW9tX3VuY29tcHJlc3MKKyAqIFRvIGVuYWJsZSB1bmNvbXByZXNz IHN1cHBvcnQgaW4ga2VybmVsIGNvbmZpZywgYWRkIHRoZXNlIGxpbmVzIChmb3IgdWx6bWEKKyAq IGFuZCB1emlwIHN1cHBvcnQgcmVzcGVjdGl2ZWx5KToKKyAqIG9wdGlvbnMJZ2VvbV91bmNvbXBy ZXNzCisgKiBvcHRpb25zCWdlb21fdW5jb21wcmVzc191emlwCiAgKi8KIAogI2luY2x1ZGUgPHN5 cy9jZGVmcy5oPgogX19GQlNESUQoIiRGcmVlQlNEJCIpOwogCisjaW5jbHVkZSAib3B0X2dlb20u aCIKKwogI2luY2x1ZGUgPHN5cy9wYXJhbS5oPgogI2luY2x1ZGUgPHN5cy9iaW8uaD4KICNpbmNs dWRlIDxzeXMvZW5kaWFuLmg+CkBAIC00NywxMCArNTEsOCBAQAogI2luY2x1ZGUgPHN5cy9zeXN0 bS5oPgogCiAjaW5jbHVkZSA8Z2VvbS9nZW9tLmg+CisjaW5jbHVkZSA8Z2VvbS91bmNvbXByZXNz L2dfdW5jb21wcmVzcy5oPgogCi0jaW5jbHVkZSA8bmV0L3psaWIuaD4KLSNpbmNsdWRlIDxjb250 cmliL3h6LWVtYmVkZGVkL2xpbnV4L2luY2x1ZGUvbGludXgveHouaD4KLQogI2lmZGVmIEdFT01f VU5DT01QUkVTU19ERUJVRwogI2RlZmluZQlEUFJJTlRGKGEpCXByaW50ZiBhCiBleHRlcm4gaW50 IGdfZGVidWdmbGFnczsKQEAgLTU4LDEyICs2MCwxMCBAQAogI2RlZmluZQlEUFJJTlRGKGEpCiAj ZW5kaWYKIAotc3RhdGljIE1BTExPQ19ERUZJTkUoTV9HRU9NX1VOQ09NUFJFU1MsICJnZW9tX3Vu Y29tcHJlc3MiLAorTUFMTE9DX0RFRklORShNX0dFT01fVU5DT01QUkVTUywgImdlb21fdW5jb21w cmVzcyIsCiAgICAgIkdFT00gVU5DT01QUkVTUyBkYXRhIHN0cnVjdHVyZXMiKTsKIAogI2RlZmlu ZQlVTkNPTVBSRVNTX0NMQVNTX05BTUUJIlVOQ09NUFJFU1MiCi0jZGVmaW5lCUdFT01fVVpJUF9N QUpWRVIgJzInCi0jZGVmaW5lCUdFT01fVUxaTUFfTUFKVkVSICczJwogCiAvKgogICogTWF4aW11 bSBhbGxvd2VkIHZhbGlkIGJsb2NrIHNpemUgKHRvIHByZXZlbnQgZm9vdC1zaG9vdGluZykKQEAg LTcxLDI4ICs3MSwxNyBAQAogI2RlZmluZQlNQVhfQkxLU1oJKE1BWFBIWVMpCiAKIC8qCi0gKiBJ bnRlZ2VyIHZhbHVlcyAoYmxvY2sgc2l6ZSwgbnVtYmVyIG9mIGJsb2Nrcywgb2Zmc2V0cykKLSAq IGFyZSBzdG9yZWQgaW4gYmlnLWVuZGlhbiAobmV0d29yaykgb3JkZXIgb24gZGlzayBhbmQgc3Ry dWN0IGNsb29wX2hlYWRlcgotICogYW5kIGluIG5hdGl2ZSBvcmRlciBpbiBzdHJ1Y3QgZ191bmNv bXByZXNzX3NvZnRjCisgKiBJbnRlZ2VyIHZhbHVlcyAoYmxvY2sgc2l6ZSwgbnVtYmVyIG9mIGJs b2Nrcywgb2Zmc2V0cykgYXJlIHN0b3JlZCBpbiBuYXRpdmUKKyAqIG9yZGVyIGluIHN0cnVjdCBn X3VuY29tcHJlc3Nfc29mdGMuCiAgKi8KIAotI2RlZmluZQlDTE9PUF9NQUdJQ19MRU4JMTI4CiBz dGF0aWMgY2hhciBDTE9PUF9NQUdJQ19TVEFSVFtdID0gIiMhL2Jpbi9zaFxuIjsKIAotc3RydWN0 IGNsb29wX2hlYWRlciB7Ci0JY2hhciBtYWdpY1tDTE9PUF9NQUdJQ19MRU5dOwkvKiBjbG9vcCBt YWdpYyAqLwotCXVpbnQzMl90IGJsa3N6OwkJCS8qIGJsb2NrIHNpemUgKi8KLQl1aW50MzJfdCBu YmxvY2tzOwkJLyogbnVtYmVyIG9mIGJsb2NrcyAqLwotfTsKLQogc3RydWN0IGdfdW5jb21wcmVz c19zb2Z0YyB7CiAJdWludDMyX3QgYmxrc3o7CQkJLyogYmxvY2sgc2l6ZSAqLwogCXVpbnQzMl90 IG5ibG9ja3M7CQkvKiBudW1iZXIgb2YgYmxvY2tzICovCiAJdWludDY0X3QgKm9mZnNldHM7Ci0J ZW51bSB7Ci0JCUdFT01fVVpJUCA9IDEsCi0JCUdFT01fVUxaTUEKLQl9IHR5cGU7CisJaW50IHR5 cGU7CiAKIAlzdHJ1Y3QgbXR4IGxhc3RfbXR4OwogCXVpbnQzMl90IGxhc3RfYmxrOwkJLyogbGFz dCBibGsgbm8gKi8KQEAgLTk5LDExICs4OCwxNiBAQAogCWNoYXIgKmxhc3RfYnVmOwkJCS8qIGxh c3QgYmxrIGRhdGEgKi8KIAlpbnQgcmVxX3RvdGFsOwkJCS8qIHRvdGFsIHJlcXVlc3RzICovCiAJ aW50IHJlcV9jYWNoZWQ7CQkJLyogY2FjaGVkIHJlcXVlc3RzICovCit9OwogCi0JLyogWFogZGVj b2RlciBzdHJ1Y3RzICovCi0Jc3RydWN0IHh6X2J1ZiAqYjsKLQlzdHJ1Y3QgeHpfZGVjICpzOwot CXpfc3RyZWFtICp6czsKK3N0YXRpYyBzdHJ1Y3QgZ191bmNvbXByZXNzX2Rlc2MgKmdfdW5jb21w cmVzc1tdID0geworI2lmZGVmIEdFT01fVU5DT01QUkVTUworCSZnX3VuY29tcHJlc3NfdWx6bWEs CisjZW5kaWYKKyNpZmRlZiBHRU9NX1VOQ09NUFJFU1NfVVpJUAorCSZnX3VuY29tcHJlc3NfdXpp cCwKKyNlbmRpZgorCU5VTEwKIH07CiAKIHN0YXRpYyB2b2lkCkBAIC0xMTksMjUgKzExMyw4IEBA CiAJCXNjLT5vZmZzZXRzID0gMDsKIAl9CiAKLQlzd2l0Y2ggKHNjLT50eXBlKSB7Ci0JY2FzZSBH RU9NX1VMWk1BOgotCQlpZiAoc2MtPmIpIHsKLQkJCWZyZWUoc2MtPmIsIE1fR0VPTV9VTkNPTVBS RVNTKTsKLQkJCXNjLT5iID0gMDsKLQkJfQotCQlpZiAoc2MtPnMpIHsKLQkJCXh6X2RlY19lbmQo c2MtPnMpOwotCQkJc2MtPnMgPSAwOwotCQl9Ci0JCWJyZWFrOwotCWNhc2UgR0VPTV9VWklQOgot CQlpZiAoc2MtPnpzKSB7Ci0JCQlpbmZsYXRlRW5kKHNjLT56cyk7Ci0JCQlmcmVlKHNjLT56cywg TV9HRU9NX1VOQ09NUFJFU1MpOwotCQkJc2MtPnpzID0gMDsKLQkJfQotCQlicmVhazsKLQl9CisJ LyogQ2FsbCB0aGUgZnJlZSBtZXRob2QuICovCisJZ191bmNvbXByZXNzW3NjLT50eXBlXS0+ZF9m cmVlKGdfdW5jb21wcmVzc1tzYy0+dHlwZV0pOwogCiAJbXR4X2Rlc3Ryb3koJnNjLT5sYXN0X210 eCk7CiAJZnJlZShzYy0+bGFzdF9idWYsIE1fR0VPTV9VTkNPTVBSRVNTKTsKQEAgLTE0NCwyMyAr MTIxLDcgQEAKIAlmcmVlKHNjLCBNX0dFT01fVU5DT01QUkVTUyk7CiB9CiAKLXN0YXRpYyB2b2lk ICoKLXpfYWxsb2Modm9pZCAqbmlsLCB1X2ludCB0eXBlLCB1X2ludCBzaXplKQotewotCXZvaWQg KnB0cjsKLQotCXB0ciA9IG1hbGxvYyh0eXBlICogc2l6ZSwgTV9HRU9NX1VOQ09NUFJFU1MsIE1f Tk9XQUlUKTsKLQlyZXR1cm4gKHB0cik7Ci19Ci0KIHN0YXRpYyB2b2lkCi16X2ZyZWUodm9pZCAq bmlsLCB2b2lkICpwdHIpCi17Ci0KLQlmcmVlKHB0ciwgTV9HRU9NX1VOQ09NUFJFU1MpOwotfQot Ci1zdGF0aWMgdm9pZAogZ191bmNvbXByZXNzX2RvbmUoc3RydWN0IGJpbyAqYnApCiB7CiAJc3Ry dWN0IGdfdW5jb21wcmVzc19zb2Z0YyAqc2M7CkBAIC0yNTQsMzMgKzIxNSw5IEBACiAJCQloZXhk dW1wKGJwLT5iaW9fZGF0YSArIHBvcywgZGxlbiwgMCwgMCk7CiAjZW5kaWYKIAotCQlzd2l0Y2gg KHNjLT50eXBlKSB7Ci0JCWNhc2UgR0VPTV9VTFpNQToKLQkJCXNjLT5iLT5pbiA9IGJwLT5iaW9f ZGF0YSArIHBvczsKLQkJCXNjLT5iLT5vdXQgPSBzYy0+bGFzdF9idWY7Ci0JCQlzYy0+Yi0+aW5f cG9zID0gc2MtPmItPm91dF9wb3MgPSAwOwotCQkJc2MtPmItPmluX3NpemUgPSBkbGVuOwotCQkJ c2MtPmItPm91dF9zaXplID0gKHNpemVfdCktMTsKLQotCQkJZXJyID0gKHh6X2RlY19ydW4oc2Mt PnMsIHNjLT5iKSAhPSBYWl9TVFJFQU1fRU5EKSA/Ci0JCQkgICAgMSA6IDA7Ci0JCQkvKiBUT0RP IGRlY29kZXIgcmVjb3ZlcnksIGlmIG5lZWRlZCAqLwotCQkJYnJlYWs7Ci0JCWNhc2UgR0VPTV9V WklQOgotCQkJc2MtPnpzLT5uZXh0X2luID0gYnAtPmJpb19kYXRhICsgcG9zOwotCQkJc2MtPnpz LT5hdmFpbF9pbiA9IGRsZW47Ci0JCQlzYy0+enMtPm5leHRfb3V0ID0gc2MtPmxhc3RfYnVmOwot CQkJc2MtPnpzLT5hdmFpbF9vdXQgPSBzYy0+Ymxrc3o7Ci0KLQkJCWVyciA9IChpbmZsYXRlKHNj LT56cywgWl9GSU5JU0gpICE9IFpfU1RSRUFNX0VORCkgPwotCQkJICAgIDEgOiAwOwotCQkJaWYg KChlcnIpIHx8IChpbmZsYXRlUmVzZXQoc2MtPnpzKSAhPSBaX09LKSkKLQkJCQlwcmludGYoIiVz OiBVWklQIGRlY29kZXIgcmVzZXQgZmFpbGVkXG4iLAotCQkJCSAgICAgZ3AtPm5hbWUpOwotCQkJ YnJlYWs7Ci0JCX0KLQotCQlpZiAoZXJyKSB7CisJCWlmIChnX3VuY29tcHJlc3Nbc2MtPnR5cGVd LT5kX2RlY29tKGdfdW5jb21wcmVzc1tzYy0+dHlwZV0sCisJCSAgICBncC0+bmFtZSwgYnAtPmJp b19kYXRhICsgcG9zLCBsZW4sIHNjLT5sYXN0X2J1ZiwKKwkJICAgIHNjLT5ibGtzeikgIT0gMCkg ewogCQkJc2MtPmxhc3RfYmxrID0gLTE7CiAJCQltdHhfdW5sb2NrKCZzYy0+bGFzdF9tdHgpOwog CQkJRFBSSU5URigoIiVzOiBkb25lOiBpbmZsYXRlIGZhaWxlZCwgY29kZT0lZFxuIiwKQEAgLTI5 MSw3ICsyMjgsNyBAQAogCiAjaWZkZWYgR0VPTV9VTkNPTVBSRVNTX0RFQlVHCiAJCWlmIChnX2Rl YnVnZmxhZ3MgJiAzMikKLQkJCWhleGR1bXAoc2MtPmxhc3RfYnVmLCBzYy0+Yi0+b3V0X3NpemUs IDAsIDApOworCQkJaGV4ZHVtcChzYy0+bGFzdF9idWYsIHNjLT5ibGtzeiwgMCwgMCk7CiAjZW5k aWYKIAogCQlzYy0+bGFzdF9ibGsgPSBpOwpAQCAtNTIxLDI0ICs0NTgsMTYgQEAKIAkJZ290byBl cnI7CiAJfQogCi0Jc3dpdGNoIChoZWFkZXItPm1hZ2ljWzB4MGJdKSB7Ci0JY2FzZSAnTCc6Ci0J CXR5cGUgPSBHRU9NX1VMWk1BOwotCQlpZiAoaGVhZGVyLT5tYWdpY1sweDBjXSA8IEdFT01fVUxa TUFfTUFKVkVSKSB7Ci0JCQlEUFJJTlRGKCgiJXM6IGltYWdlIHZlcnNpb24gdG9vIG9sZFxuIiwg Z3AtPm5hbWUpKTsKKwlmb3IgKGkgPSAwOyBnX3VuY29tcHJlc3NbaV0gIT0gTlVMTDsgaSsrKSB7 CisJCWVycm9yID0gZ191bmNvbXByZXNzW2ldLT5kX3Rhc3RlKGhlYWRlciwgZ3AtPm5hbWUpOwor CQlpZiAoZXJyb3IgPT0gMSkgeworCQkJLyogTWF0Y2guICovCisJCQl0eXBlID0gaTsKKwkJCWJy ZWFrOworCQl9IGVsc2UgaWYgKGVycm9yID09IC0xKQogCQkJZ290byBlcnI7Ci0JCX0KLQkJcHJp bnRmKCIlczogR0VPTV9VTFpNQSBpbWFnZSBmb3VuZFxuIiwgZ3AtPm5hbWUpOwotCQlicmVhazsK LQljYXNlICdWJzoKLQkJdHlwZSA9IEdFT01fVVpJUDsKLQkJaWYgKGhlYWRlci0+bWFnaWNbMHgw Y10gPCBHRU9NX1VaSVBfTUFKVkVSKSB7Ci0JCQlEUFJJTlRGKCgiJXM6IGltYWdlIHZlcnNpb24g dG9vIG9sZFxuIiwgZ3AtPm5hbWUpKTsKLQkJCWdvdG8gZXJyOwotCQl9Ci0JCXByaW50ZigiJXM6 IEdFT01fVVpJUCBpbWFnZSBmb3VuZFxuIiwgZ3AtPm5hbWUpOwotCQlicmVhazsKLQlkZWZhdWx0 OgorCX0KKwlpZiAoZ191bmNvbXByZXNzW2ldID09IE5VTEwpIHsKIAkJRFBSSU5URigoIiVzOiB1 bnN1cHBvcnRlZCBpbWFnZSB0eXBlXG4iLCBncC0+bmFtZSkpOwogCQlnb3RvIGVycjsKIAl9CkBA IC01ODgsMjMgKzUxNyw5IEBACiAJc2MtPnJlcV90b3RhbCA9IDA7CiAJc2MtPnJlcV9jYWNoZWQg PSAwOwogCi0Jc3dpdGNoIChzYy0+dHlwZSkgewotCWNhc2UgR0VPTV9VTFpNQToKLQkJeHpfY3Jj MzJfaW5pdCgpOwotCQlzYy0+cyA9IHh6X2RlY19pbml0KFhaX1NJTkdMRSwgMCk7Ci0JCXNjLT5i ID0gKHN0cnVjdCB4el9idWYqKW1hbGxvYyhzaXplb2Yoc3RydWN0IHh6X2J1ZiksCi0JCSAgICBN X0dFT01fVU5DT01QUkVTUywgTV9XQUlUT0spOwotCQlicmVhazsKLQljYXNlIEdFT01fVVpJUDoK LQkJc2MtPnpzID0gKHpfc3RyZWFtICopbWFsbG9jKHNpemVvZih6X3N0cmVhbSksCi0JCSAgICBN X0dFT01fVU5DT01QUkVTUywgTV9XQUlUT0spOwotCQlzYy0+enMtPnphbGxvYyA9IHpfYWxsb2M7 Ci0JCXNjLT56cy0+emZyZWUgPSB6X2ZyZWU7Ci0JCWlmIChpbmZsYXRlSW5pdChzYy0+enMpICE9 IFpfT0spIHsKLQkJCWdvdG8gZXJyOwotCQl9Ci0JCWJyZWFrOwotCX0KKwkvKiBJbml0aWFsaXpl IHRoZSBjb21wcmVzc2lvbiBtZXRob2QuICovCisJaWYgKGdfdW5jb21wcmVzc1tzYy0+dHlwZV0t PmRfaW5pdChnX3VuY29tcHJlc3Nbc2MtPnR5cGVdKSAhPSAwKQorCQlnb3RvIGVycjsKIAogCWdf dG9wb2xvZ3lfbG9jaygpOwogCXBwMiA9IGdfbmV3X3Byb3ZpZGVyZihncCwgIiVzIiwgZ3AtPm5h bWUpOwpJbmRleDogc3lzL21vZHVsZXMvZ2VvbS9nZW9tX3VuY29tcHJlc3MvTWFrZWZpbGUKPT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQotLS0gc3lzL21vZHVsZXMvZ2VvbS9nZW9tX3VuY29tcHJlc3MvTWFrZWZpbGUJKHJl dmlzaW9uIDI2NTAxMykKKysrIHN5cy9tb2R1bGVzL2dlb20vZ2VvbV91bmNvbXByZXNzL01ha2Vm aWxlCSh3b3JraW5nIGNvcHkpCkBAIC0xMCw4ICsxMCw5IEBACiBDRkxBR1MrPSAtSSR7LkNVUkRJ Un0vLi4vLi4vLi4vZ2VvbS91bmNvbXByZXNzLyBcCiAJLUkkey5DVVJESVJ9Ly4uLy4uLy4uL2Nv bnRyaWIveHotZW1iZWRkZWQvZnJlZWJzZCBcCiAJLUkkey5DVVJESVJ9Ly4uLy4uLy4uL2NvbnRy aWIveHotZW1iZWRkZWQvbGludXgvbGliL3h6LwotU1JDUz0JZ191bmNvbXByZXNzLmMgeHpfY3Jj MzIuYyB4el9kZWNfYmNqLmMgeHpfZGVjX2x6bWEyLmMgeHpfZGVjX3N0cmVhbS5jIFwKLSAgICB4 el9tYWxsb2MuYworQ0ZMQUdTKz0tREdFT01fVU5DT01QUkVTUyAtREdFT01fVU5DT01QUkVTU19V WklQCitTUkNTPQlnX3VuY29tcHJlc3MuYyBnX3VuY29tcHJlc3NfdWx6bWEuYyBnX3VuY29tcHJl c3NfdXppcC5jIG9wdF9nZW9tLmgKK1NSQ1MrPQl4el9jcmMzMi5jIHh6X2RlY19iY2ouYyB4el9k ZWNfbHptYTIuYyB4el9kZWNfc3RyZWFtLmMgeHpfbWFsbG9jLmMKIFNSQ1MrPQl4ei5oIHh6X2Nv bmZpZy5oIHh6X2x6bWEyLmggeHpfbWFsbG9jLmggeHpfcHJpdmF0ZS5oIHh6X3N0cmVhbS5oCiAK IC5pbmNsdWRlIDxic2Qua21vZC5taz4KLS0tIC9kZXYvbnVsbAkyMDE0LTA0LTI3IDEwOjMzOjAw LjAwMDAwMDAwMCAtMDMwMAorKysgc3lzL2dlb20vdW5jb21wcmVzcy9nX3VuY29tcHJlc3MuaAky MDE0LTA0LTI2IDE2OjE4OjM0LjgyMTU0OTUyNCAtMDMwMApAQCAtMCwwICsxLDcxIEBACisvKi0K KyAqIENvcHlyaWdodCAoYykgMjAxMC0yMDEyIEFsZWtzYW5kciBSeWJhbGtvCisgKiBDb3B5cmln aHQgKGMpIDIwMDQgTWF4IEtob24KKyAqIEFsbCByaWdodHMgcmVzZXJ2ZWQuCisgKgorICogUmVk aXN0cmlidXRpb24gYW5kIHVzZSBpbiBzb3VyY2UgYW5kIGJpbmFyeSBmb3Jtcywgd2l0aCBvciB3 aXRob3V0CisgKiBtb2RpZmljYXRpb24sIGFyZSBwZXJtaXR0ZWQgcHJvdmlkZWQgdGhhdCB0aGUg Zm9sbG93aW5nIGNvbmRpdGlvbnMKKyAqIGFyZSBtZXQ6CisgKiAxLiBSZWRpc3RyaWJ1dGlvbnMg b2Ygc291cmNlIGNvZGUgbXVzdCByZXRhaW4gdGhlIGFib3ZlIGNvcHlyaWdodAorICogICAgbm90 aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVy LgorICogMi4gUmVkaXN0cmlidXRpb25zIGluIGJpbmFyeSBmb3JtIG11c3QgcmVwcm9kdWNlIHRo ZSBhYm92ZSBjb3B5cmlnaHQKKyAqICAgIG5vdGljZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMg YW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lciBpbiB0aGUKKyAqICAgIGRvY3VtZW50YXRpb24g YW5kL29yIG90aGVyIG1hdGVyaWFscyBwcm92aWRlZCB3aXRoIHRoZSBkaXN0cmlidXRpb24uCisg KgorICogVEhJUyBTT0ZUV0FSRSBJUyBQUk9WSURFRCBCWSBUSEUgQVVUSE9SIEFORCBDT05UUklC VVRPUlMgYGBBUyBJUycnIEFORAorICogQU5ZIEVYUFJFU1MgT1IgSU1QTElFRCBXQVJSQU5USUVT LCBJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywgVEhFCisgKiBJTVBMSUVEIFdBUlJBTlRJ RVMgT0YgTUVSQ0hBTlRBQklMSVRZIEFORCBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9T RQorICogQVJFIERJU0NMQUlNRUQuICBJTiBOTyBFVkVOVCBTSEFMTCBUSEUgQVVUSE9SIE9SIENP TlRSSUJVVE9SUyBCRSBMSUFCTEUKKyAqIEZPUiBBTlkgRElSRUNULCBJTkRJUkVDVCwgSU5DSURF TlRBTCwgU1BFQ0lBTCwgRVhFTVBMQVJZLCBPUiBDT05TRVFVRU5USUFMCisgKiBEQU1BR0VTIChJ TkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywgUFJPQ1VSRU1FTlQgT0YgU1VCU1RJVFVURSBH T09EUworICogT1IgU0VSVklDRVM7IExPU1MgT0YgVVNFLCBEQVRBLCBPUiBQUk9GSVRTOyBPUiBC VVNJTkVTUyBJTlRFUlJVUFRJT04pCisgKiBIT1dFVkVSIENBVVNFRCBBTkQgT04gQU5ZIFRIRU9S WSBPRiBMSUFCSUxJVFksIFdIRVRIRVIgSU4gQ09OVFJBQ1QsIFNUUklDVAorICogTElBQklMSVRZ LCBPUiBUT1JUIChJTkNMVURJTkcgTkVHTElHRU5DRSBPUiBPVEhFUldJU0UpIEFSSVNJTkcgSU4g QU5ZIFdBWQorICogT1VUIE9GIFRIRSBVU0UgT0YgVEhJUyBTT0ZUV0FSRSwgRVZFTiBJRiBBRFZJ U0VEIE9GIFRIRSBQT1NTSUJJTElUWSBPRgorICogU1VDSCBEQU1BR0UuCisgKi8KKworI2lmbmRl ZiBfR19VTkNPTVBSRVNTX0hfCisjZGVmaW5lIF9HX1VOQ09NUFJFU1NfSF8KKworTUFMTE9DX0RF Q0xBUkUoTV9HRU9NX1VOQ09NUFJFU1MpOworCisjZGVmaW5lCUNMT09QX01BR0lDX0xFTgkxMjgK KyNkZWZpbmUJQ0xPT1BfVFlQRQkweDBiCisjZGVmaW5lCUNMT09QX1ZFUlNJT04JMHgwYworCisv KgorICogSW50ZWdlciB2YWx1ZXMgKGJsb2NrIHNpemUsIG51bWJlciBvZiBibG9ja3MsIG9mZnNl dHMpIGFyZSBzdG9yZWQgaW4KKyAqIGJpZy1lbmRpYW4gKG5ldHdvcmspIG9yZGVyIG9uIGRpc2sg YW5kIHN0cnVjdCBjbG9vcF9oZWFkZXIuCisgKi8KK3N0cnVjdCBjbG9vcF9oZWFkZXIgeworCWNo YXIgbWFnaWNbQ0xPT1BfTUFHSUNfTEVOXTsJLyogY2xvb3AgbWFnaWMgKi8KKwl1aW50MzJfdCBi bGtzejsJCQkvKiBibG9jayBzaXplICovCisJdWludDMyX3QgbmJsb2NrczsJCS8qIG51bWJlciBv ZiBibG9ja3MgKi8KK307IAorCitzdHJ1Y3QgZ191bmNvbXByZXNzX2Rlc2M7CisKK3R5cGVkZWYg aW50IGdfdW5jb21wcmVzc19kZWNvbV90IChzdHJ1Y3QgZ191bmNvbXByZXNzX2Rlc2MgKiwgY2hh ciAqLAorCWNhZGRyX3QsIG9mZl90LCBjYWRkcl90LCBvZmZfdCk7Cit0eXBlZGVmIHZvaWQgZ191 bmNvbXByZXNzX2ZyZWVfdCAoc3RydWN0IGdfdW5jb21wcmVzc19kZXNjICopOwordHlwZWRlZiBp bnQgZ191bmNvbXByZXNzX2luaXRfdCAoc3RydWN0IGdfdW5jb21wcmVzc19kZXNjICopOwordHlw ZWRlZiBpbnQgZ191bmNvbXByZXNzX3Rhc3RlX3QgKHN0cnVjdCBjbG9vcF9oZWFkZXIgKiwgY2hh ciAqKTsKKworc3RydWN0IGdfdW5jb21wcmVzc19kZXNjIHsKKwl2b2lkCQkJKmRfZGF0YTsKKwln X3VuY29tcHJlc3NfZGVjb21fdAkqZF9kZWNvbTsKKwlnX3VuY29tcHJlc3NfZnJlZV90CSpkX2Zy ZWU7CisJZ191bmNvbXByZXNzX2luaXRfdAkqZF9pbml0OworCWdfdW5jb21wcmVzc190YXN0ZV90 CSpkX3Rhc3RlOworfTsKKworLyogU3VwcG9ydGVkIGNvbXByZXNzaW9uIG1ldGhvZHMuICovCisj aWZkZWYgR0VPTV9VTkNPTVBSRVNTCitleHRlcm4gc3RydWN0IGdfdW5jb21wcmVzc19kZXNjIGdf dW5jb21wcmVzc191bHptYTsKKyNlbmRpZgorI2lmZGVmIEdFT01fVU5DT01QUkVTU19VWklQCitl eHRlcm4gc3RydWN0IGdfdW5jb21wcmVzc19kZXNjIGdfdW5jb21wcmVzc191emlwOworI2VuZGlm CisKKyNlbmRpZiAvKiBfR19VTkNPTVBSRVNTX0hfICovCi0tLSAvZGV2L251bGwJMjAxNC0wNC0y NyAxMDozMzowMC4wMDAwMDAwMDAgLTAzMDAKKysrIHN5cy9nZW9tL3VuY29tcHJlc3MvZ191bmNv bXByZXNzX3Vsem1hLmMJMjAxNC0wNC0yNiAxNjoxOTowNC4wMDM1NDc3MTAgLTAzMDAKQEAgLTAs MCArMSwxMjkgQEAKKy8qLQorICogQ29weXJpZ2h0IChjKSAyMDEwLTIwMTIgQWxla3NhbmRyIFJ5 YmFsa28KKyAqIENvcHlyaWdodCAoYykgMjAwNCBNYXggS2hvbgorICogQWxsIHJpZ2h0cyByZXNl cnZlZC4KKyAqCisgKiBSZWRpc3RyaWJ1dGlvbiBhbmQgdXNlIGluIHNvdXJjZSBhbmQgYmluYXJ5 IGZvcm1zLCB3aXRoIG9yIHdpdGhvdXQKKyAqIG1vZGlmaWNhdGlvbiwgYXJlIHBlcm1pdHRlZCBw cm92aWRlZCB0aGF0IHRoZSBmb2xsb3dpbmcgY29uZGl0aW9ucworICogYXJlIG1ldDoKKyAqIDEu IFJlZGlzdHJpYnV0aW9ucyBvZiBzb3VyY2UgY29kZSBtdXN0IHJldGFpbiB0aGUgYWJvdmUgY29w eXJpZ2h0CisgKiAgICBub3RpY2UsIHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9s bG93aW5nIGRpc2NsYWltZXIuCisgKiAyLiBSZWRpc3RyaWJ1dGlvbnMgaW4gYmluYXJ5IGZvcm0g bXVzdCByZXByb2R1Y2UgdGhlIGFib3ZlIGNvcHlyaWdodAorICogICAgbm90aWNlLCB0aGlzIGxp c3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVyIGluIHRoZQorICog ICAgZG9jdW1lbnRhdGlvbiBhbmQvb3Igb3RoZXIgbWF0ZXJpYWxzIHByb3ZpZGVkIHdpdGggdGhl IGRpc3RyaWJ1dGlvbi4KKyAqCisgKiBUSElTIFNPRlRXQVJFIElTIFBST1ZJREVEIEJZIFRIRSBB VVRIT1IgQU5EIENPTlRSSUJVVE9SUyBgYEFTIElTJycgQU5ECisgKiBBTlkgRVhQUkVTUyBPUiBJ TVBMSUVEIFdBUlJBTlRJRVMsIElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRPLCBUSEUKKyAq IElNUExJRUQgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgQU5EIEZJVE5FU1MgRk9SIEEg UEFSVElDVUxBUiBQVVJQT1NFCisgKiBBUkUgRElTQ0xBSU1FRC4gIElOIE5PIEVWRU5UIFNIQUxM IFRIRSBBVVRIT1IgT1IgQ09OVFJJQlVUT1JTIEJFIExJQUJMRQorICogRk9SIEFOWSBESVJFQ1Qs IElORElSRUNULCBJTkNJREVOVEFMLCBTUEVDSUFMLCBFWEVNUExBUlksIE9SIENPTlNFUVVFTlRJ QUwKKyAqIERBTUFHRVMgKElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRPLCBQUk9DVVJFTUVO VCBPRiBTVUJTVElUVVRFIEdPT0RTCisgKiBPUiBTRVJWSUNFUzsgTE9TUyBPRiBVU0UsIERBVEEs IE9SIFBST0ZJVFM7IE9SIEJVU0lORVNTIElOVEVSUlVQVElPTikKKyAqIEhPV0VWRVIgQ0FVU0VE IEFORCBPTiBBTlkgVEhFT1JZIE9GIExJQUJJTElUWSwgV0hFVEhFUiBJTiBDT05UUkFDVCwgU1RS SUNUCisgKiBMSUFCSUxJVFksIE9SIFRPUlQgKElOQ0xVRElORyBORUdMSUdFTkNFIE9SIE9USEVS V0lTRSkgQVJJU0lORyBJTiBBTlkgV0FZCisgKiBPVVQgT0YgVEhFIFVTRSBPRiBUSElTIFNPRlRX QVJFLCBFVkVOIElGIEFEVklTRUQgT0YgVEhFIFBPU1NJQklMSVRZIE9GCisgKiBTVUNIIERBTUFH RS4KKyAqLworCisvKgorICogR0VPTSBVTFpNQSBtb2R1bGUgLSBzaW1wbGUgZGVjb21wcmVzc2lv biBtb2R1bGUgZm9yIHVzZSB3aXRoIHJlYWQtb25seQorICogY29tcHJlc3NlZCBpbWFnZXMgY3Jl YXRlZCBieSBta3Vsem1hKDgpLgorICovCisKKyNpbmNsdWRlIDxzeXMvY2RlZnMuaD4KK19fRkJT RElEKCIkRnJlZUJTRCQiKTsKKworI2luY2x1ZGUgPHN5cy9wYXJhbS5oPgorI2luY2x1ZGUgPHN5 cy9rZXJuZWwuaD4KKyNpbmNsdWRlIDxzeXMvbWFsbG9jLmg+CisjaW5jbHVkZSA8c3lzL3N5c3Rt Lmg+CisKKyNpbmNsdWRlIDxnZW9tL3VuY29tcHJlc3MvZ191bmNvbXByZXNzLmg+CisKKyNpbmNs dWRlIDxjb250cmliL3h6LWVtYmVkZGVkL2xpbnV4L2luY2x1ZGUvbGludXgveHouaD4KKworI2Rl ZmluZQlHRU9NX1VMWk1BX01BSlZFUgknMycKKworc3RydWN0IGdfdW5jb21wcmVzc191bHptYV9z b2Z0YyB7CisJLyogWFogZGVjb2RlciBzdHJ1Y3RzICovCisJc3RydWN0IHh6X2J1ZiAqYjsKKwlz dHJ1Y3QgeHpfZGVjICpzOworfTsKKworc3RhdGljIHZvaWQKK2dfdW5jb21wcmVzc191bHptYV9m cmVlKHN0cnVjdCBnX3VuY29tcHJlc3NfZGVzYyAqdW5jb21wcmVzcykKK3sKKwlzdHJ1Y3QgZ191 bmNvbXByZXNzX3Vsem1hX3NvZnRjICpzYzsKKyAgICAgICAgICAgICAgICAKKwlzYyA9IChzdHJ1 Y3QgZ191bmNvbXByZXNzX3Vsem1hX3NvZnRjICopdW5jb21wcmVzcy0+ZF9kYXRhOworCWlmIChz YykgeworCQlpZiAoc2MtPmIpIHsKKwkJCWZyZWUoc2MtPmIsIE1fR0VPTV9VTkNPTVBSRVNTKTsK KwkJCXNjLT5iID0gTlVMTDsKKwkJfQorCQlpZiAoc2MtPnMpIHsKKwkJCXh6X2RlY19lbmQoc2Mt PnMpOworCQkJc2MtPnMgPSBOVUxMOworCQl9CisJCWZyZWUoc2MsIE1fR0VPTV9VTkNPTVBSRVNT KTsKKwkJdW5jb21wcmVzcy0+ZF9kYXRhID0gTlVMTDsKKwl9Cit9CisKK3N0YXRpYyBpbnQKK2df dW5jb21wcmVzc191bHptYV9pbml0KHN0cnVjdCBnX3VuY29tcHJlc3NfZGVzYyAqdW5jb21wcmVz cykKK3sKKwlzdHJ1Y3QgZ191bmNvbXByZXNzX3Vsem1hX3NvZnRjICpzYzsKKworCXNjID0gKHN0 cnVjdCBnX3VuY29tcHJlc3NfdWx6bWFfc29mdGMgKiltYWxsb2Moc2l6ZW9mKCpzYyksCisJICAg IE1fR0VPTV9VTkNPTVBSRVNTLCBNX1dBSVRPSyB8IE1fWkVSTyk7CisJeHpfY3JjMzJfaW5pdCgp OworCXNjLT5zID0geHpfZGVjX2luaXQoWFpfU0lOR0xFLCAwKTsKKwlzYy0+YiA9IChzdHJ1Y3Qg eHpfYnVmICopbWFsbG9jKHNpemVvZihzdHJ1Y3QgeHpfYnVmKSwKKwkgICAgTV9HRU9NX1VOQ09N UFJFU1MsIE1fV0FJVE9LKTsKKworCXVuY29tcHJlc3MtPmRfZGF0YSA9ICh2b2lkICopc2M7CisK KwlyZXR1cm4gKDApOworfQorCitzdGF0aWMgaW50CitnX3VuY29tcHJlc3NfdWx6bWFfZGVjb20o c3RydWN0IGdfdW5jb21wcmVzc19kZXNjICp1bmNvbXByZXNzLCBjaGFyICpwcm92aWRlciwKKwlj YWRkcl90IGluLCBvZmZfdCBpbmxlbiwgY2FkZHJfdCBvdXQsIG9mZl90IG91dGxlbikKK3sKKwlz dHJ1Y3QgZ191bmNvbXByZXNzX3Vsem1hX3NvZnRjICpzYzsKKworCXNjID0gKHN0cnVjdCBnX3Vu Y29tcHJlc3NfdWx6bWFfc29mdGMgKil1bmNvbXByZXNzLT5kX2RhdGE7CisJc2MtPmItPmluID0g aW47CisJc2MtPmItPm91dCA9IG91dDsKKwlzYy0+Yi0+aW5fcG9zID0gc2MtPmItPm91dF9wb3Mg PSAwOworCXNjLT5iLT5pbl9zaXplID0gaW5sZW47CisJc2MtPmItPm91dF9zaXplID0gKHNpemVf dCktMTsKKworCWlmICh4el9kZWNfcnVuKHNjLT5zLCBzYy0+YikgIT0gWFpfU1RSRUFNX0VORCkK KwkJcmV0dXJuICgtMSk7CisKKwlyZXR1cm4gKDApOworfQorCitzdGF0aWMgaW50CitnX3VuY29t cHJlc3NfdWx6bWFfdGFzdGUoc3RydWN0IGNsb29wX2hlYWRlciAqaGVhZGVyLCBjaGFyICpwcm92 aWRlcikKK3sgICAgICAgCisKKwlpZiAoaGVhZGVyLT5tYWdpY1tDTE9PUF9UWVBFXSAhPSAnTCcp CisJCXJldHVybiAoMCk7CisJaWYgKGhlYWRlci0+bWFnaWNbQ0xPT1BfVkVSU0lPTl0gPCBHRU9N X1VMWk1BX01BSlZFUikgeworCQlwcmludGYoIiVzOiBpbWFnZSB2ZXJzaW9uIHRvbyBvbGRcbiIs IHByb3ZpZGVyKTsKKwkJcmV0dXJuICgtMSk7CisJfQorCXByaW50ZigiJXM6IEdFT01fVUxaTUEg aW1hZ2UgZm91bmRcbiIsIHByb3ZpZGVyKTsKKworCXJldHVybiAoMSk7Cit9CisKK3N0cnVjdCBn X3VuY29tcHJlc3NfZGVzYyBnX3VuY29tcHJlc3NfdWx6bWEgPSB7CisJLmRfZGVjb20gPSBnX3Vu Y29tcHJlc3NfdWx6bWFfZGVjb20sCisJLmRfZnJlZSA9IGdfdW5jb21wcmVzc191bHptYV9mcmVl LAorCS5kX2luaXQgPSBnX3VuY29tcHJlc3NfdWx6bWFfaW5pdCwKKwkuZF90YXN0ZSA9IGdfdW5j b21wcmVzc191bHptYV90YXN0ZSwKK307Ci0tLSAvZGV2L251bGwJMjAxNC0wNC0yNyAxMDozMzow MC4wMDAwMDAwMDAgLTAzMDAKKysrIHN5cy9nZW9tL3VuY29tcHJlc3MvZ191bmNvbXByZXNzX3V6 aXAuYwkyMDE0LTA0LTI2IDE2OjQwOjExLjQxMzQ2Mjg1NSAtMDMwMApAQCAtMCwwICsxLDE0OCBA QAorLyotCisgKiBDb3B5cmlnaHQgKGMpIDIwMTAtMjAxMiBBbGVrc2FuZHIgUnliYWxrbworICog Q29weXJpZ2h0IChjKSAyMDA0IE1heCBLaG9uCisgKiBBbGwgcmlnaHRzIHJlc2VydmVkLgorICoK KyAqIFJlZGlzdHJpYnV0aW9uIGFuZCB1c2UgaW4gc291cmNlIGFuZCBiaW5hcnkgZm9ybXMsIHdp dGggb3Igd2l0aG91dAorICogbW9kaWZpY2F0aW9uLCBhcmUgcGVybWl0dGVkIHByb3ZpZGVkIHRo YXQgdGhlIGZvbGxvd2luZyBjb25kaXRpb25zCisgKiBhcmUgbWV0OgorICogMS4gUmVkaXN0cmli dXRpb25zIG9mIHNvdXJjZSBjb2RlIG11c3QgcmV0YWluIHRoZSBhYm92ZSBjb3B5cmlnaHQKKyAq ICAgIG5vdGljZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlz Y2xhaW1lci4KKyAqIDIuIFJlZGlzdHJpYnV0aW9ucyBpbiBiaW5hcnkgZm9ybSBtdXN0IHJlcHJv ZHVjZSB0aGUgYWJvdmUgY29weXJpZ2h0CisgKiAgICBub3RpY2UsIHRoaXMgbGlzdCBvZiBjb25k aXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIgaW4gdGhlCisgKiAgICBkb2N1bWVu dGF0aW9uIGFuZC9vciBvdGhlciBtYXRlcmlhbHMgcHJvdmlkZWQgd2l0aCB0aGUgZGlzdHJpYnV0 aW9uLgorICoKKyAqIFRISVMgU09GVFdBUkUgSVMgUFJPVklERUQgQlkgVEhFIEFVVEhPUiBBTkQg Q09OVFJJQlVUT1JTIGBgQVMgSVMnJyBBTkQKKyAqIEFOWSBFWFBSRVNTIE9SIElNUExJRUQgV0FS UkFOVElFUywgSU5DTFVESU5HLCBCVVQgTk9UIExJTUlURUQgVE8sIFRIRQorICogSU1QTElFRCBX QVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElUWSBBTkQgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFS IFBVUlBPU0UKKyAqIEFSRSBESVNDTEFJTUVELiAgSU4gTk8gRVZFTlQgU0hBTEwgVEhFIEFVVEhP UiBPUiBDT05UUklCVVRPUlMgQkUgTElBQkxFCisgKiBGT1IgQU5ZIERJUkVDVCwgSU5ESVJFQ1Qs IElOQ0lERU5UQUwsIFNQRUNJQUwsIEVYRU1QTEFSWSwgT1IgQ09OU0VRVUVOVElBTAorICogREFN QUdFUyAoSU5DTFVESU5HLCBCVVQgTk9UIExJTUlURUQgVE8sIFBST0NVUkVNRU5UIE9GIFNVQlNU SVRVVEUgR09PRFMKKyAqIE9SIFNFUlZJQ0VTOyBMT1NTIE9GIFVTRSwgREFUQSwgT1IgUFJPRklU UzsgT1IgQlVTSU5FU1MgSU5URVJSVVBUSU9OKQorICogSE9XRVZFUiBDQVVTRUQgQU5EIE9OIEFO WSBUSEVPUlkgT0YgTElBQklMSVRZLCBXSEVUSEVSIElOIENPTlRSQUNULCBTVFJJQ1QKKyAqIExJ QUJJTElUWSwgT1IgVE9SVCAoSU5DTFVESU5HIE5FR0xJR0VOQ0UgT1IgT1RIRVJXSVNFKSBBUklT SU5HIElOIEFOWSBXQVkKKyAqIE9VVCBPRiBUSEUgVVNFIE9GIFRISVMgU09GVFdBUkUsIEVWRU4g SUYgQURWSVNFRCBPRiBUSEUgUE9TU0lCSUxJVFkgT0YKKyAqIFNVQ0ggREFNQUdFLgorICovCisK Ky8qCisgKiBHRU9NIFVaSVAgbW9kdWxlIC0gc2ltcGxlIGRlY29tcHJlc3Npb24gbW9kdWxlIGZv ciB1c2Ugd2l0aCByZWFkLW9ubHkKKyAqIGNvbXByZXNzZWQgaW1hZ2VzIGNyZWF0ZWQgYnkgbWt1 emlwKDgpLgorICovCisKKyNpbmNsdWRlIDxzeXMvY2RlZnMuaD4KK19fRkJTRElEKCIkRnJlZUJT RCQiKTsKKworI2luY2x1ZGUgPHN5cy9wYXJhbS5oPgorI2luY2x1ZGUgPHN5cy9rZXJuZWwuaD4K KyNpbmNsdWRlIDxzeXMvbWFsbG9jLmg+CisjaW5jbHVkZSA8c3lzL3N5c3RtLmg+CisKKyNpbmNs dWRlIDxnZW9tL3VuY29tcHJlc3MvZ191bmNvbXByZXNzLmg+CisKKyNpbmNsdWRlIDxuZXQvemxp Yi5oPgorCisjZGVmaW5lCUdFT01fVVpJUF9NQUpWRVIJJzInCisKK3N0cnVjdCBnX3VuY29tcHJl c3NfdXppcF9zb2Z0YyB7CisJel9zdHJlYW0gKnpzOworfTsKKworc3RhdGljIHZvaWQKK2dfdW5j b21wcmVzc191emlwX2ZyZWUoc3RydWN0IGdfdW5jb21wcmVzc19kZXNjICp1bmNvbXByZXNzKQor eworCXN0cnVjdCBnX3VuY29tcHJlc3NfdXppcF9zb2Z0YyAqc2M7CisKKwlzYyA9IChzdHJ1Y3Qg Z191bmNvbXByZXNzX3V6aXBfc29mdGMgKil1bmNvbXByZXNzLT5kX2RhdGE7CisJaWYgKHNjKSB7 CisJCWlmIChzYy0+enMpIHsKKwkJCWluZmxhdGVFbmQoc2MtPnpzKTsKKwkJCWZyZWUoc2MtPnpz LCBNX0dFT01fVU5DT01QUkVTUyk7CisJCQlzYy0+enMgPSBOVUxMOworCQl9CisJCWZyZWUoc2Ms IE1fR0VPTV9VTkNPTVBSRVNTKTsKKwkJdW5jb21wcmVzcy0+ZF9kYXRhID0gTlVMTDsKKwl9Cit9 CisKK3N0YXRpYyB2b2lkICoKK3pfYWxsb2Modm9pZCAqbmlsLCB1X2ludCB0eXBlLCB1X2ludCBz aXplKQoreworCXZvaWQgKnB0cjsKKworCXB0ciA9IG1hbGxvYyh0eXBlICogc2l6ZSwgTV9HRU9N X1VOQ09NUFJFU1MsIE1fTk9XQUlUKTsKKwlyZXR1cm4gKHB0cik7Cit9CisKK3N0YXRpYyB2b2lk Cit6X2ZyZWUodm9pZCAqbmlsLCB2b2lkICpwdHIpCit7CisKKwlmcmVlKHB0ciwgTV9HRU9NX1VO Q09NUFJFU1MpOworfQorCitzdGF0aWMgaW50CitnX3VuY29tcHJlc3NfdXppcF9pbml0KHN0cnVj dCBnX3VuY29tcHJlc3NfZGVzYyAqdW5jb21wcmVzcykKK3sKKwlzdHJ1Y3QgZ191bmNvbXByZXNz X3V6aXBfc29mdGMgKnNjOworCisJc2MgPSAoc3RydWN0IGdfdW5jb21wcmVzc191emlwX3NvZnRj ICopbWFsbG9jKHNpemVvZigqc2MpLAorCSAgICBNX0dFT01fVU5DT01QUkVTUywgTV9XQUlUT0sg fCBNX1pFUk8pOworCXNjLT56cyA9ICh6X3N0cmVhbSAqKW1hbGxvYyhzaXplb2Yoel9zdHJlYW0p LAorCSAgICBNX0dFT01fVU5DT01QUkVTUywgTV9XQUlUT0spOworCXNjLT56cy0+emFsbG9jID0g el9hbGxvYzsKKwlzYy0+enMtPnpmcmVlID0gel9mcmVlOworCWlmIChpbmZsYXRlSW5pdChzYy0+ enMpICE9IFpfT0spIHsKKwkJZnJlZSAoc2MtPnpzLCBNX0dFT01fVU5DT01QUkVTUyk7CisJCWZy ZWUgKHNjLCBNX0dFT01fVU5DT01QUkVTUyk7CisJCXJldHVybiAoLTEpOworCX0KKworCXVuY29t cHJlc3MtPmRfZGF0YSA9ICh2b2lkICopc2M7CisKKwlyZXR1cm4gKDApOworfQorCitzdGF0aWMg aW50CitnX3VuY29tcHJlc3NfdXppcF9kZWNvbShzdHJ1Y3QgZ191bmNvbXByZXNzX2Rlc2MgKnVu Y29tcHJlc3MsIGNoYXIgKnByb3ZpZGVyLAorCWNhZGRyX3QgaW4sIG9mZl90IGlubGVuLCBjYWRk cl90IG91dCwgb2ZmX3Qgb3V0bGVuKQoreworCWludCBlcnI7CisJc3RydWN0IGdfdW5jb21wcmVz c191emlwX3NvZnRjICpzYzsKKworCXNjID0gKHN0cnVjdCBnX3VuY29tcHJlc3NfdXppcF9zb2Z0 YyAqKXVuY29tcHJlc3MtPmRfZGF0YTsKKwlzYy0+enMtPm5leHRfaW4gPSBpbjsKKwlzYy0+enMt PmF2YWlsX2luID0gaW5sZW47CisJc2MtPnpzLT5uZXh0X291dCA9IG91dDsKKwlzYy0+enMtPmF2 YWlsX291dCA9IG91dGxlbjsKKworCWVyciA9IChpbmZsYXRlKHNjLT56cywgWl9GSU5JU0gpICE9 IFpfU1RSRUFNX0VORCkgPyAgMSA6IDA7CisJaWYgKGVyciB8fCBpbmZsYXRlUmVzZXQoc2MtPnpz KSAhPSBaX09LKSB7CisJCXByaW50ZigiJXM6IFVaSVAgZGVjb2RlciByZXNldCBmYWlsZWRcbiIs IHByb3ZpZGVyKTsKKwkJcmV0dXJuICgtMSk7CisJfQorCisJcmV0dXJuICgwKTsKK30KKworc3Rh dGljIGludAorZ191bmNvbXByZXNzX3V6aXBfdGFzdGUoc3RydWN0IGNsb29wX2hlYWRlciAqaGVh ZGVyLCBjaGFyICpwcm92aWRlcikKK3sKKworCWlmIChoZWFkZXItPm1hZ2ljW0NMT09QX1RZUEVd ICE9ICdWJykKKwkJcmV0dXJuICgwKTsKKwlpZiAoaGVhZGVyLT5tYWdpY1tDTE9PUF9WRVJTSU9O XSA8IEdFT01fVVpJUF9NQUpWRVIpIHsKKwkJcHJpbnRmKCIlczogaW1hZ2UgdmVyc2lvbiB0b28g b2xkXG4iLCBwcm92aWRlcik7CisJCXJldHVybiAoLTEpOworCX0KKwlwcmludGYoIiVzOiBHRU9N X1VaSVAgaW1hZ2UgZm91bmRcbiIsIHByb3ZpZGVyKTsKKworCXJldHVybiAoMSk7Cit9CisKK3N0 cnVjdCBnX3VuY29tcHJlc3NfZGVzYyBnX3VuY29tcHJlc3NfdXppcCA9IHsKKwkuZF9kZWNvbSA9 IGdfdW5jb21wcmVzc191emlwX2RlY29tLAorCS5kX2ZyZWUgPSBnX3VuY29tcHJlc3NfdXppcF9m cmVlLAorCS5kX2luaXQgPSBnX3VuY29tcHJlc3NfdXppcF9pbml0LAorCS5kX3Rhc3RlID0gZ191 bmNvbXByZXNzX3V6aXBfdGFzdGUsCit9OwpJbmRleDogc2hhcmUvbWFuL21hbjQvZ2VvbV91bmNv bXByZXNzLjQKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PQotLS0gc2hhcmUvbWFuL21hbjQvZ2VvbV91bmNvbXByZXNzLjQJ KHJldmlzaW9uIDI2NTAxMykKKysrIHNoYXJlL21hbi9tYW40L2dlb21fdW5jb21wcmVzcy40CSh3 b3JraW5nIGNvcHkpCkBAIC0yNCw3ICsyNCw3IEBACiAuXCIKIC5cIiAkRnJlZUJTRCQKIC5cIgot LkRkIEphbnVhcnkgOSwgMjAxNAorLkRkIEFwcmlsIDI3LCAyMDE0CiAuRHQgR0VPTV9VTkNPTVBS RVNTIDQKIC5PcwogLlNoIE5BTUUKQEAgLTMxLDEwICszMSwxMSBAQAogLk5tIGdlb21fdW5jb21w cmVzcwogLk5kICJHRU9NIGJhc2VkIGNvbXByZXNzZWQgZGlzayBpbWFnZXMiCiAuU2ggU1lOT1BT SVMKLVRvIGNvbXBpbGUgdGhpcyBkcml2ZXIgaW50byB0aGUga2VybmVsLCBwbGFjZSB0aGUgZm9s bG93aW5nIGxpbmUgaW4geW91cgorVG8gY29tcGlsZSB0aGlzIGRyaXZlciBpbnRvIHRoZSBrZXJu ZWwsIHBsYWNlIHRoZSBmb2xsb3dpbmcgbGluZXMgaW4geW91cgoga2VybmVsIGNvbmZpZ3VyYXRp b24gZmlsZToKIC5CZCAtcmFnZ2VkIC1vZmZzZXQgaW5kZW50CiAuQ2QgIm9wdGlvbnMgR0VPTV9V TkNPTVBSRVNTIgorLkNkICJvcHRpb25zIEdFT01fVU5DT01QUkVTU19VWklQIgogLkVkCiAuUHAK IEFsdGVybmF0aXZlbHksIHRvIGxvYWQgdGhlIGRyaXZlciBhcyBhIG1vZHVsZSBhdCBib290IHRp bWUsIHBsYWNlIHRoZQpAQCAtODksNiArOTAsMTggQEAKICAgIFNlY3RvcnNpemU6IDUxMgogICAg TW9kZTogcjF3MGUwCiAuRWQKKy5QcAorVGhlIGNvbXByZXNzaW9uIHN1cHBvcnQgY2FuIGJlIGNo b3NlbiBpbiBrZXJuZWwgY29uZmlndXJhdGlvbjoKKy5CbCAtdGFnIC13aWR0aCAiLlN5IG9wdGlv bnMgR0VPTV9VTkNPTVBSRVNTX1VaSVAiCisuSXQgU3kgb3B0aW9ucyBHRU9NX1VOQ09NUFJFU1MK K0VuYWJsZSB0aGUgc3VwcG9ydCBmb3IgbWt1bHptYSg4KSBpbWFnZXMuCisuSXQgU3kgb3B0aW9u cyBHRU9NX1VOQ09NUFJFU1NfVVpJUAorRW5hYmxlIHRoZSBzdXBwb3J0IGZvciBta3V6aXAoOCkg aW1hZ2VzLgorLkVsCisuUHAKK1RoZQorLk5tCittb2R1bGUgaXMgYnVpbHQgd2l0aCBib3RoIGNv bXByZXNzaW9uIG1ldGhvZHMgZW5hYmxlZC4KIC5TaCBTRUUgQUxTTwogLlhyIEdFT00gNCAsCiAu WHIgbWQgNCAsCg== --001a11c382d422f85004f82d089e-- From owner-freebsd-geom@FreeBSD.ORG Tue Apr 29 15:55:09 2014 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 20D1D191 for ; Tue, 29 Apr 2014 15:55:09 +0000 (UTC) Received: from constantine.ingresso.co.uk (constantine.ingresso.co.uk [IPv6:2a02:b90:3002:e550::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DC09B1701 for ; Tue, 29 Apr 2014 15:55:08 +0000 (UTC) Received: from dilbert.london-internal.ingresso.co.uk ([10.64.50.6] helo=dilbert.ingresso.co.uk) by constantine.ingresso.co.uk with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1WfAN7-0008pa-1N; Tue, 29 Apr 2014 16:55:05 +0100 Received: from petefrench by dilbert.ingresso.co.uk with local (Exim 4.82 (FreeBSD)) (envelope-from ) id 1WfAN6-0000lN-UU; Tue, 29 Apr 2014 16:55:04 +0100 To: freebsd-geom@freebsd.org, kpielorz_lst@tdx.co.uk Subject: Re: Anyone using HAST in production / performance? In-Reply-To: <2D7624DF74301FC17FEA865E@Mail-PC.tdx.co.uk> Message-Id: From: Pete French Date: Tue, 29 Apr 2014 16:55:04 +0100 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, 29 Apr 2014 15:55:09 -0000 > I've been looking at HAST for a while (I posted here a while ago about > performance). > > Is anyone using it in production? - How do you find the performance? A belated followup to this, but yes, I have been using it in production for a while now - it replaces an older stack we constructed based on gmirror and ggated. Much mucy better and far more repliable. Performance wise I havent done any real testing I am afraid, aside form looking at raw disc bandwidth using gstat when we are doing a heavy operation. There we get about 50 meg/second, which is more or less what I would expecrt over gig ether. We use dedicates adapters for the hast connection - wired back to back and only talk to each other. We also use a pair of cards for each hast drive, and we then run ZFS over the top with light compression enabled (lz4). The setup is used to run mysql on top of - initially using myISAM tables, but now using innodb. Performance appears to be fine - i,.e. I havent noticed any issues, but as I said, we havent actually treid to measure it. -pete. From owner-freebsd-geom@FreeBSD.ORG Sun May 4 13:11:28 2014 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 1A771679 for ; Sun, 4 May 2014 13:11:28 +0000 (UTC) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id B67D01376 for ; Sun, 4 May 2014 13:11:26 +0000 (UTC) Received: from study64.tdx.co.uk (study64.tdx.co.uk [62.13.130.231]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id s44DBJZp053148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 May 2014 14:11:19 +0100 (BST) Date: Sun, 04 May 2014 14:11:19 +0100 From: Karl Pielorz To: Pete French , freebsd-geom@freebsd.org Subject: Re: Anyone using HAST in production / performance? Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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: Sun, 04 May 2014 13:11:28 -0000 --On 29 April 2014 16:55:04 +0100 Pete French wrote: > A belated followup to this, but yes, I have been using it in > production for a while now - it replaces an older stack > we constructed based on gmirror and ggated. Much mucy better and > far more repliable. I've used ggated before - I never got it working reliably enough to use :( - But it was very, very fast! ;) > Performance wise I havent done any real testing I am > afraid, aside form looking at raw disc bandwidth using > gstat when we are doing a heavy operation. There we get > about 50 meg/second, which is more or less what I would expecrt > over gig ether. My main concern is - if I take 4 'local' disks and run ZFS atop of them (2 mirrors of 2) I get 130Mbyte/sec for writes. If I switch that to 4 disks over HAST (all local, no remote node - i.e. remote set to 'none') - that drops to 31Mbyte/sec. for the same setup. It doesn't get any lower with the remote node enabled - but that's a heck of a drop :( By the time you've setup a ZVOL and exported as iSCSI (or just CIFS/NFS) there's really nothing left performance wise :( > The setup is used to run mysql on top of - initially using myISAM tables, > but now using innodb. Performance appears to be fine - i,.e. I havent > noticed any issues, but as I said, we havent actually treid to measure > it. I guess if you're just using the zool 'locally' - that 31Mbyte/sec may be close to the performance you're getting [estimated]? What version of FreeBSD are you using? I'm just wondering if that's making a difference... -Karl From owner-freebsd-geom@FreeBSD.ORG Sun May 4 22:50:49 2014 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 6B47299E for ; Sun, 4 May 2014 22:50:49 +0000 (UTC) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0139.outbound.protection.outlook.com [207.46.163.139]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D662D16C7 for ; Sun, 4 May 2014 22:25:38 +0000 (UTC) Received: from [IPv6:2601:2:4780:2fd:8875:75fe:c2a7:77e7] (2601:2:4780:2fd:8875:75fe:c2a7:77e7) by BLUPR03MB018.namprd03.prod.outlook.com (10.255.208.40) with Microsoft SMTP Server (TLS) id 15.0.934.12; Sun, 4 May 2014 22:25:30 +0000 Message-ID: <5366CC63.4000001@my.hennepintech.edu> Date: Sun, 4 May 2014 18:25:23 -0500 From: Andrew Berg User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Subject: Recreating a GPT Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [2601:2:4780:2fd:8875:75fe:c2a7:77e7] X-ClientProxiedBy: BY2PR03CA078.namprd03.prod.outlook.com (10.141.249.51) To BLUPR03MB018.namprd03.prod.outlook.com (10.255.208.40) X-Forefront-PRVS: 02015246A9 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(199002)(189002)(77982001)(64706001)(46102001)(92566001)(80976001)(4396001)(75432001)(50466002)(83322001)(23676002)(47776003)(87976001)(76482001)(42186004)(83506001)(92726001)(21056001)(101416001)(81342001)(50986999)(81542001)(54356999)(65816999)(20776003)(80022001)(74502001)(31966008)(85852003)(83072002)(99396002)(86362001)(33656001)(74662001)(59896001)(3826001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR03MB018; H:[IPv6:2601:2:4780:2fd:8875:75fe:c2a7:77e7]; FPR:; MLV:sfv; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (: my.HennepinTech.edu does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=aberg010@my.HennepinTech.edu; X-OriginatorOrg: my.hennepintech.edu X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 May 2014 22:50:49 -0000 Sorry if this is the wrong list; I have seen discussions regarding gpart in the archives for this list while doing some searching for answers to my problem. I destroyed a GPT ('gpart destroy -F ada0') and then ended up needing the data on it (the lesson here is to make many backups of important files, not just think you have one somewhere). Anyway, I don't have an actual backup of the partition layout (as created by 'gpart backup'), but I know the partition sizes and sector sizes, and I happen to have another disk that, AFAICT, is the exact same size: ada0: ATA-8 SATA 3.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) ada2: ATA-8 SATA 2.x device ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada2: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) ada0 being the disk I want to recover. My question is, knowing the exact commands given to create the GPT, how should I go about creating a file that will restore the GPT on ada0 without damaging the data on the partitions themselves? I suppose I could create a new GPT on the scratch disk and use the output of 'gpart backup' from that, but I'm not sure it would be 100% correct and I'd have to clone the original disk over it again, which would take hours since it's a TB and dd isn't exactly the fastest way of copying data (even with large blocksizes). I'm very hesitant to write *anything* to the original disk. From owner-freebsd-geom@FreeBSD.ORG Sun May 4 23:21:04 2014 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 A02B7F82 for ; Sun, 4 May 2014 23:21:04 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 554C61C6E for ; Sun, 4 May 2014 23:21:04 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.8/8.14.8) with ESMTP id s44NL2nF009387 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 4 May 2014 17:21:02 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.8/8.14.8/Submit) with ESMTP id s44NL2AA009384; Sun, 4 May 2014 17:21:02 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Sun, 4 May 2014 17:21:02 -0600 (MDT) From: Warren Block To: Andrew Berg Subject: Re: Recreating a GPT In-Reply-To: <5366CC63.4000001@my.hennepintech.edu> Message-ID: References: <5366CC63.4000001@my.hennepintech.edu> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Sun, 04 May 2014 17:21:03 -0600 (MDT) Cc: freebsd-geom@freebsd.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 May 2014 23:21:04 -0000 On Sun, 4 May 2014, Andrew Berg wrote: > ada0 being the disk I want to recover. My question is, knowing the exact > commands given to create the GPT, how should I go about creating a file that > will restore the GPT on ada0 without damaging the data on the partitions > themselves? I suppose I could create a new GPT on the scratch disk and use the > output of 'gpart backup' from that, but I'm not sure it would be 100% correct > and I'd have to clone the original disk over it again, which would take hours > since it's a TB and dd isn't exactly the fastest way of copying data (even > with large blocksizes). I'm very hesitant to write *anything* to the original > disk. It will take a while to copy the disk with dd(1), but that's really the only safe way. Make a copy, and write the partition tables to that. gpart(8) only writes to the partition tables or bootcode, and should be safe for the data in the partitions, but the only way to guarantee that is on a copy, not the original. gpart backup produces plain text that can be manually created. I'd still rather let gpart deal with the disk directly by using gpart create and add commands. From owner-freebsd-geom@FreeBSD.ORG Sun May 4 23:38:47 2014 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 20AC71F0 for ; Sun, 4 May 2014 23:38:47 +0000 (UTC) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0184.outbound.protection.outlook.com [207.46.163.184]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D6C581DB3 for ; Sun, 4 May 2014 23:38:45 +0000 (UTC) Received: from [IPv6:2601:2:4780:2fd:8875:75fe:c2a7:77e7] (2601:2:4780:2fd:8875:75fe:c2a7:77e7) by BLUPR03MB018.namprd03.prod.outlook.com (10.255.208.40) with Microsoft SMTP Server (TLS) id 15.0.934.12; Sun, 4 May 2014 23:38:36 +0000 Message-ID: <5366DD86.8050005@my.hennepintech.edu> Date: Sun, 4 May 2014 19:38:30 -0500 From: Andrew Berg User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Subject: Re: Recreating a GPT References: <5366CC63.4000001@my.hennepintech.edu> In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [2601:2:4780:2fd:8875:75fe:c2a7:77e7] X-ClientProxiedBy: BY2PR03CA052.namprd03.prod.outlook.com (10.141.249.25) To BLUPR03MB018.namprd03.prod.outlook.com (10.255.208.40) X-Forefront-PRVS: 02015246A9 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(24454002)(199002)(189002)(51704005)(83072002)(85852003)(99396002)(31966008)(59896001)(33656001)(86362001)(74662001)(92566001)(4396001)(80976001)(83322001)(50466002)(75432001)(64706001)(77982001)(76176999)(46102001)(81542001)(54356999)(65816999)(50986999)(101416001)(81342001)(21056001)(74502001)(80022001)(20776003)(87976001)(23676002)(47776003)(83506001)(92726001)(76482001)(42186004)(3826001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR03MB018; H:[IPv6:2601:2:4780:2fd:8875:75fe:c2a7:77e7]; FPR:; MLV:sfv; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (: my.HennepinTech.edu does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=aberg010@my.HennepinTech.edu; X-OriginatorOrg: my.hennepintech.edu X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 May 2014 23:38:47 -0000 On 2014.05.04 18:21, Warren Block wrote: > It will take a while to copy the disk with dd(1), but that's really the > only safe way. Make a copy, and write the partition tables to that. > > gpart(8) only writes to the partition tables or bootcode, and should be > safe for the data in the partitions, but the only way to guarantee that > is on a copy, not the original. I've already cloned the entire thing to the scratch drive. I'd just rather not rewrite it in its entirety again. How much of the disk will I need to rewrite to get the partition table back to its original state if my attempts are unsuccessful? IIRC, bits are written to the end of the disk as well, so I'm not sure how to do it with dd(1), though I'm sure it can be done. > gpart backup produces plain text that can be manually created. I'd > still rather let gpart deal with the disk directly by using gpart create > and add commands. I'm under the assumption that 'gpart create' will do more than 'gpart restore'; is that not correct? From owner-freebsd-geom@FreeBSD.ORG Mon May 5 00:27:00 2014 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 1278A98A for ; Mon, 5 May 2014 00:27:00 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A17C61280 for ; Mon, 5 May 2014 00:26:59 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.8/8.14.8) with ESMTP id s450QvGx009700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 4 May 2014 18:26:58 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.8/8.14.8/Submit) with ESMTP id s450Qv21009697; Sun, 4 May 2014 18:26:57 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Sun, 4 May 2014 18:26:57 -0600 (MDT) From: Warren Block To: Andrew Berg Subject: Re: Recreating a GPT In-Reply-To: <5366DD86.8050005@my.hennepintech.edu> Message-ID: References: <5366CC63.4000001@my.hennepintech.edu> <5366DD86.8050005@my.hennepintech.edu> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Sun, 04 May 2014 18:26:58 -0600 (MDT) Cc: freebsd-geom@freebsd.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 00:27:00 -0000 On Sun, 4 May 2014, Andrew Berg wrote: > On 2014.05.04 18:21, Warren Block wrote: >> It will take a while to copy the disk with dd(1), but that's really the >> only safe way. Make a copy, and write the partition tables to that. >> >> gpart(8) only writes to the partition tables or bootcode, and should be >> safe for the data in the partitions, but the only way to guarantee that >> is on a copy, not the original. > I've already cloned the entire thing to the scratch drive. I'd just rather > not rewrite it in its entirety again. How much of the disk will I need to > rewrite to get the partition table back to its original state if my attempts > are unsuccessful? IIRC, bits are written to the end of the disk as well, > so I'm not sure how to do it with dd(1), though I'm sure it can be done. One copy of the disk should be enough. Different partition offsets can be tried without having to copy the whole disk again. The backup GPT table at the end of the disk will be vacant after "gpart destroy", so rewriting it won't harm any actual data. GPT partition1 partition2 partition3 ... partitionN GPT-Backup 'gpart destroy -F' overwrote the GPT and the backup GPT. 'gpart create' and 'gpart add' only modify those also. Data in the partitions is not modified. >> gpart backup produces plain text that can be manually created. I'd >> still rather let gpart deal with the disk directly by using gpart create >> and add commands. > I'm under the assumption that 'gpart create' will do more than > 'gpart restore'; is that not correct? 'gpart restore' is just a single-step version of 'gpart create' and 'gpart add' for as many partitions as were on the original. From owner-freebsd-geom@FreeBSD.ORG Mon May 5 00:28:18 2014 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 EC1479C1 for ; Mon, 5 May 2014 00:28:18 +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)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AED251285 for ; Mon, 5 May 2014 00:28:18 +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 s450SHXD036856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 May 2014 17:28:18 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s450SHmT036855; Sun, 4 May 2014 17:28:17 -0700 (PDT) (envelope-from jmg) Date: Sun, 4 May 2014 17:28:17 -0700 From: John-Mark Gurney To: Andrew Berg Subject: Re: Recreating a GPT Message-ID: <20140505002817.GO43976@funkthat.com> Mail-Followup-To: Andrew Berg , freebsd-geom@freebsd.org References: <5366CC63.4000001@my.hennepintech.edu> <5366DD86.8050005@my.hennepintech.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5366DD86.8050005@my.hennepintech.edu> 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-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sun, 04 May 2014 17:28:18 -0700 (PDT) Cc: freebsd-geom@freebsd.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 00:28:19 -0000 Andrew Berg wrote this message on Sun, May 04, 2014 at 19:38 -0500: > On 2014.05.04 18:21, Warren Block wrote: > > It will take a while to copy the disk with dd(1), but that's really the > > only safe way. Make a copy, and write the partition tables to that. > > > > gpart(8) only writes to the partition tables or bootcode, and should be > > safe for the data in the partitions, but the only way to guarantee that > > is on a copy, not the original. > I've already cloned the entire thing to the scratch drive. I'd just rather > not rewrite it in its entirety again. How much of the disk will I need to > rewrite to get the partition table back to its original state if my attempts > are unsuccessful? IIRC, bits are written to the end of the disk as well, > so I'm not sure how to do it with dd(1), though I'm sure it can be done. If you've already cloned everything to the scratch drive, just run the gpart commands on the scratch drive, and you should be able to just mount the fs's... most of these commands don't write to sectors they don't need to as that's just a waste of time/resources... > > gpart backup produces plain text that can be manually created. I'd > > still rather let gpart deal with the disk directly by using gpart create > > and add commands. > I'm under the assumption that 'gpart create' will do more than > 'gpart restore'; is that not correct? -- 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 Mon May 5 01:11:48 2014 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 DA055272 for ; Mon, 5 May 2014 01:11:48 +0000 (UTC) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0142.outbound.protection.outlook.com [207.46.163.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 993801628 for ; Mon, 5 May 2014 01:11:47 +0000 (UTC) Received: from [IPv6:2601:2:4780:2fd:8875:75fe:c2a7:77e7] (2601:2:4780:2fd:8875:75fe:c2a7:77e7) by BLUPR03MB018.namprd03.prod.outlook.com (10.255.208.40) with Microsoft SMTP Server (TLS) id 15.0.934.12; Mon, 5 May 2014 01:11:39 +0000 Message-ID: <5366F34D.1000602@my.hennepintech.edu> Date: Sun, 4 May 2014 21:11:25 -0500 From: Andrew Berg User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Subject: Re: Recreating a GPT References: <5366CC63.4000001@my.hennepintech.edu> <5366DD86.8050005@my.hennepintech.edu> In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [2601:2:4780:2fd:8875:75fe:c2a7:77e7] X-ClientProxiedBy: BY2PR03CA052.namprd03.prod.outlook.com (10.141.249.25) To BLUPR03MB018.namprd03.prod.outlook.com (10.255.208.40) X-Forefront-PRVS: 0202D21D2F X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(51914003)(24454002)(199002)(189002)(83072002)(85852003)(99396002)(31966008)(59896001)(33656001)(86362001)(74662001)(92566001)(4396001)(80976001)(83322001)(50466002)(75432001)(64706001)(77982001)(76176999)(46102001)(54356999)(65816999)(81542001)(50986999)(101416001)(81342001)(21056001)(74502001)(80022001)(20776003)(87976001)(23676002)(47776003)(83506001)(92726001)(76482001)(42186004)(3826001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR03MB018; H:[IPv6:2601:2:4780:2fd:8875:75fe:c2a7:77e7]; FPR:; MLV:sfv; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (: my.HennepinTech.edu does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=aberg010@my.HennepinTech.edu; X-OriginatorOrg: my.hennepintech.edu X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 01:11:48 -0000 On 2014.05.04 19:26, Warren Block wrote: > One copy of the disk should be enough. Different partition offsets can > be tried without having to copy the whole disk again. The backup GPT > table at the end of the disk will be vacant after "gpart destroy", so > rewriting it won't harm any actual data. > ... > 'gpart restore' is just a single-step version of 'gpart create' and > 'gpart add' for as many partitions as were on the original. Thanks for the clarification. I recreated the partition table, and zpool can now see it for import, but says the disk is unavailable. It's possible the alignment is off slightly, but unfortunately, I don't think that's the case. Thanks for the help, though. From owner-freebsd-geom@FreeBSD.ORG Mon May 5 01:34:04 2014 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 0661B8F8 for ; Mon, 5 May 2014 01:34:04 +0000 (UTC) Received: from alogt.com (alogt.com [69.36.191.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D56431795 for ; Mon, 5 May 2014 01:34:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=UD8iE/0Bts1zq8lCX3IimGLT35mcxLxLpGwk/YBGHbE=; b=c9vJ5/ptgvD7tOjrpUqRPi7L9Wrpr9HRaHFhUeDAeC7duSRfFT7jJo7qF1AA7wWMPKfFlqprCTKz0+lmJUgCfGNqVOxj4P5ogJEJXT8cNtQBTjxhrVlkgtcc/L3CG7/P9rjc40ha5LsbcNxIRku9CTA1fM24h4H/MVaFr3Gp3Vg=; Received: from [182.10.137.14] (port=35833 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Wh7n7-001sCy-Nw; Sun, 04 May 2014 19:34:02 -0600 Date: Mon, 5 May 2014 09:33:56 +0800 From: Erich Dollansky To: Andrew Berg Subject: Re: Recreating a GPT Message-ID: <20140505093356.302a6791@X220.alogt.com> In-Reply-To: <5366CC63.4000001@my.hennepintech.edu> References: <5366CC63.4000001@my.hennepintech.edu> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; amd64-portbld-freebsd10.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-geom@freebsd.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 01:34:04 -0000 Hi, On Sun, 4 May 2014 18:25:23 -0500 Andrew Berg wrote: > Sorry if this is the wrong list; I have seen discussions regarding it is the right list if you will get the right answer. > I destroyed a GPT ('gpart destroy -F ada0') and then ended up needing You have read already some possible solution. Allow me to tell you mine after a hardware failure led to a damaged partitioning schema on one of my disks. I really have had to go down to a hex editor an recreate the entries. The sad part on this was that the source code is the only reliable source of information here. As you have a second disk which is at least similar, you can compare the individual sectors starting from the boot sector and change them when needed. Of course, do this only when all other methods have failed. Erich From owner-freebsd-geom@FreeBSD.ORG Mon May 5 02:28:27 2014 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 C38AF1BC for ; Mon, 5 May 2014 02:28:27 +0000 (UTC) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0244.outbound.protection.outlook.com [207.46.163.244]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 916641130 for ; Mon, 5 May 2014 02:28:26 +0000 (UTC) Received: from [IPv6:2601:2:4780:2fd:8875:75fe:c2a7:77e7] (2601:2:4780:2fd:8875:75fe:c2a7:77e7) by SN2PR03MB032.namprd03.prod.outlook.com (10.255.175.42) with Microsoft SMTP Server (TLS) id 15.0.934.12; Mon, 5 May 2014 02:28:19 +0000 Message-ID: <5367054D.9010908@my.hennepintech.edu> Date: Sun, 4 May 2014 22:28:13 -0500 From: Andrew Berg User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Subject: Re: Recreating a GPT References: <5366CC63.4000001@my.hennepintech.edu> <5366DD86.8050005@my.hennepintech.edu> <5366F34D.1000602@my.hennepintech.edu> In-Reply-To: <5366F34D.1000602@my.hennepintech.edu> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [2601:2:4780:2fd:8875:75fe:c2a7:77e7] X-ClientProxiedBy: BY2PR03CA059.namprd03.prod.outlook.com (10.141.249.32) To SN2PR03MB032.namprd03.prod.outlook.com (10.255.175.42) X-Forefront-PRVS: 0202D21D2F X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(199002)(189002)(24454002)(51914003)(74502001)(23676002)(101416001)(31966008)(64126003)(92566001)(99136001)(74662001)(87976001)(85852003)(77982001)(83072002)(81342001)(59896001)(4396001)(50986999)(76176999)(76482001)(46102001)(92726001)(75432001)(42186004)(21056001)(50466002)(99396002)(65816999)(83322001)(47776003)(87266999)(80976001)(81542001)(33656001)(83506001)(80022001)(86362001)(64706001)(20776003)(54356999)(79102001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB032; H:[IPv6:2601:2:4780:2fd:8875:75fe:c2a7:77e7]; FPR:; MLV:sfv; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (: my.HennepinTech.edu does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=aberg010@my.HennepinTech.edu; X-OriginatorOrg: my.hennepintech.edu X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 02:28:27 -0000 On 2014.05.04 21:11, Andrew Berg wrote: > I recreated the partition table, and zpool can now see it for import, but says > the disk is unavailable. It's possible the alignment is off slightly, but > unfortunately, I don't think that's the case. Thanks for the help, though. I got some help in #zfs on freenode and it turns out the alignment was off. I was able to correct it and import the pool and get my file. :) From owner-freebsd-geom@FreeBSD.ORG Mon May 5 11:06:44 2014 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 DF420D0E for ; Mon, 5 May 2014 11:06:43 +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)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CA8DC1CE7 for ; Mon, 5 May 2014 11:06:43 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s45B6hH7083104 for ; Mon, 5 May 2014 11:06:43 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s45B6hPX083102 for freebsd-geom@FreeBSD.org; Mon, 5 May 2014 11:06:43 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 5 May 2014 11:06:43 GMT Message-Id: <201405051106.s45B6hPX083102@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.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 11:06:44 -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/188754 geom [geom] GEOM Problem: gmirror gm0 destroyed on shutdown 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 f 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. 81 problems total. From owner-freebsd-geom@FreeBSD.ORG Tue May 6 10:43:47 2014 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 E2FCD70C for ; Tue, 6 May 2014 10:43:47 +0000 (UTC) Received: from constantine.ingresso.co.uk (constantine.ingresso.co.uk [IPv6:2a02:b90:3002:e550::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AA3D428B for ; Tue, 6 May 2014 10:43:47 +0000 (UTC) Received: from dilbert.london-internal.ingresso.co.uk ([10.64.50.6] helo=dilbert.ingresso.co.uk) by constantine.ingresso.co.uk with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1Whcqc-000PsR-2Z; Tue, 06 May 2014 11:43:42 +0100 Received: from petefrench by dilbert.ingresso.co.uk with local (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Whcqc-0008Eq-0C; Tue, 06 May 2014 11:43:42 +0100 To: freebsd-geom@freebsd.org, kpielorz_lst@tdx.co.uk, petefrench@ingresso.co.uk Subject: Re: Anyone using HAST in production / performance? In-Reply-To: Message-Id: From: Pete French Date: Tue, 06 May 2014 11:43:42 +0100 X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 10:43:48 -0000 > I guess if you're just using the zool 'locally' - that 31Mbyte/sec may be > close to the performance you're getting [estimated]? I just diud a very unscientific test - dd of /dev/random into a fle, and I see about 30 meg/second in gstat, and the end result is about that too, so well guessed ;) > What version of FreeBSD are you using? I'm just wondering if that's making > a difference... 9.2 - from the day after heartbleed came out. 10k drives, gig ether between the boxes. -pete. From owner-freebsd-geom@FreeBSD.ORG Wed May 7 07:33:57 2014 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 40CEF791 for ; Wed, 7 May 2014 07:33:57 +0000 (UTC) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id DC8D180 for ; Wed, 7 May 2014 07:33:56 +0000 (UTC) Received: from study64.tdx.co.uk (study64.tdx.co.uk [62.13.130.231]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3/) with ESMTP id s477XlUt002150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 May 2014 08:33:48 +0100 (BST) Date: Wed, 07 May 2014 08:33:48 +0100 From: Karl Pielorz To: Pete French , freebsd-geom@freebsd.org Subject: Re: Anyone using HAST in production / performance? Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 07:33:57 -0000 --On 6 May 2014 11:43:42 +0100 Pete French wrote: >> I guess if you're just using the zool 'locally' - that 31Mbyte/sec may >> be close to the performance you're getting [estimated]? > > I just diud a very unscientific test - dd of /dev/random into a fle, > and I see about 30 meg/second in gstat, and the end result > is about that too, so well guessed ;) Yeah, not a bad guess :) - Looks like I'm not doing anything 'obviously' wrong - it's just going as fast as it does... >> What version of FreeBSD are you using? I'm just wondering if that's >> making a difference... > > 9.2 - from the day after heartbleed came out. 10k drives, gig > ether between the boxes. Looks like I'm back to looking at iSCSI -> ZFS then for now. HAST has coped with everything I've thrown at it ('failure' wise) but I need more speed than that as storage for VM's etc. Thanks for the info anyway, -Karl From owner-freebsd-geom@FreeBSD.ORG Wed May 7 10:03:45 2014 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 8AF0924D for ; Wed, 7 May 2014 10:03:45 +0000 (UTC) Received: from constantine.ingresso.co.uk (constantine.ingresso.co.uk [IPv6:2a02:b90:3002:e550::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3C51A232 for ; Wed, 7 May 2014 10:03:45 +0000 (UTC) Received: from dilbert.london-internal.ingresso.co.uk ([10.64.50.6] helo=dilbert.ingresso.co.uk) by constantine.ingresso.co.uk with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1WhyhO-000Ljz-At; Wed, 07 May 2014 11:03:38 +0100 Received: from petefrench by dilbert.ingresso.co.uk with local (Exim 4.82 (FreeBSD)) (envelope-from ) id 1WhyhO-000AYu-8Z; Wed, 07 May 2014 11:03:38 +0100 To: freebsd-geom@freebsd.org, kpielorz_lst@tdx.co.uk, petefrench@ingresso.co.uk Subject: Re: Anyone using HAST in production / performance? In-Reply-To: Message-Id: From: Pete French Date: Wed, 07 May 2014 11:03:38 +0100 X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 10:03:45 -0000 > Looks like I'm back to looking at iSCSI -> ZFS then for now. HAST has coped > with everything I've thrown at it ('failure' wise) but I need more speed > than that as storage for VM's etc. I would be interested to know how that works out - I tried iscsi and ZFS a while ago, but my problem with it was that it didnt handle failure very well - you took away the remote iscsi drive and the ZFS layer locked up. Thats why I ended up using ggated + gmirror, instead of iscsi + zfs. We switched back to ZFS when hast came along, but then for me it is "fast enough" My experiences with iscsi were a long time ago though - 2007 or so, and am sure its rather different now! cheers, -pete. From owner-freebsd-geom@FreeBSD.ORG Wed May 7 13:49:47 2014 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:1900:2254:206a::19:2]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6EAF326A; Wed, 7 May 2014 13:49:47 +0000 (UTC) Received: from butcher-nb.yandex.net (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) by mx2.freebsd.org (Postfix) with ESMTP id C7C031833; Wed, 7 May 2014 13:49:44 +0000 (UTC) Message-ID: <536A39F3.1050807@FreeBSD.org> Date: Wed, 07 May 2014 17:49:39 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-geom@FreeBSD.org Subject: [RFC] Disconnect old geom classes from the build X-Enigmail-Version: 1.6 Content-Type: multipart/mixed; boundary="------------060809050401020209050602" X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 13:49:47 -0000 This is a multi-part message in MIME format. --------------060809050401020209050602 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi All, There are several GEOM classes that aren't used by default for a long time. I'm speaking about BSD, MBR, SUNLABEL and PC98. Now the PART class implements of those functionality. Also there are FOX, UZIP and VOL_FFS classes, that also have a replacement. I propose disconnect these kernel modules from the build. Your opinions? -- WBR, Andrey V. Elsukov --------------060809050401020209050602 Content-Type: text/x-patch; name="patch.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="patch.diff" Index: head/sys/modules/geom/Makefile =================================================================== --- head/sys/modules/geom/Makefile (revision 265538) +++ head/sys/modules/geom/Makefile (working copy) @@ -1,34 +1,27 @@ # $FreeBSD$ SUBDIR= geom_bde \ - geom_bsd \ geom_cache \ geom_ccd \ geom_concat \ geom_eli \ - geom_fox \ geom_gate \ geom_journal \ geom_label \ geom_linux_lvm \ - geom_mbr \ geom_mirror \ geom_mountver \ geom_multipath \ geom_nop \ geom_part \ - geom_pc98 \ geom_raid \ geom_raid3 \ geom_sched \ geom_shsec \ geom_stripe \ - geom_sunlabel \ geom_uncompress \ - geom_uzip \ geom_vinum \ geom_virstor \ - geom_vol_ffs \ geom_zero .include --------------060809050401020209050602-- From owner-freebsd-geom@FreeBSD.ORG Wed May 7 14:47:31 2014 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 8A2CC8EE; Wed, 7 May 2014 14:47:31 +0000 (UTC) Received: from mail.xcllnt.net (mail.xcllnt.net [50.0.150.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 30C6FB5; Wed, 7 May 2014 14:47:30 +0000 (UTC) Received: from meganw-sslvpn-nc.jnpr.net ([66.129.239.13]) (authenticated bits=0) by mail.xcllnt.net (8.14.8/8.14.8) with ESMTP id s47ElRHg018043 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 7 May 2014 07:47:29 -0700 (PDT) (envelope-from marcel@xcllnt.net) Content-Type: multipart/signed; boundary="Apple-Mail=_77C82B65-197C-4B3C-981C-8512893D1E00"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: [RFC] geom_uncompress(4) changes From: Marcel Moolenaar In-Reply-To: Date: Wed, 7 May 2014 07:47:21 -0700 Message-Id: References: To: Luiz Otavio O Souza X-Mailer: Apple Mail (2.1874) Cc: freebsd-embedded , freebsd-geom@freebsd.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 14:47:31 -0000 --Apple-Mail=_77C82B65-197C-4B3C-981C-8512893D1E00 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On Apr 29, 2014, at 4:50 AM, Luiz Otavio O Souza wrote: > Hi, > > I've the attached changes to geom_uncompress(4) that modularise the > compression support. > > It can now be built with support to mkuzip(8) or mkulzma(8) (or both) > independently. > > It also make a lot easier to add the support to new compression > methods on geom_uncompress. > > Now, building a kernel with 'options GEOM_UNCOMPRESS' (kept for > backward compatibility) adds only the support to read mkulzma images. You're not quite backward compatible, because GEOM_UNCOMPRESS now includes both lzma and zip. You may want to add GEOM_UNCOMPRESS_ULZMA and document it as the way to add support for lzma. That way you can simply "redefine" GEOM_UNCOMPRESS as meaning any and all compression algorithms. Thus: - GEOM_UNCOMPRESS gives you support for any and all. - GEOM_UNCOMPRESS_FOO gives you support for just FOO. > > I think we could eventually retire geom_uzip(8) as they are doing > essentially the same thing (with the same implementation and code...). > But this lets a lot of open questions regarding backward > compatibility. You can even redefine GEOM_UZIP to do what GEOM_UNCOMPRESS_UZIP does. If the code is effectively the same then compatibility is about the options, not the actual C files underneath... In general: good! -- Marcel Moolenaar marcel@xcllnt.net --Apple-Mail=_77C82B65-197C-4B3C-981C-8512893D1E00 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEUEARECAAYFAlNqR3kACgkQpgWlLWHuifaqAwCYwhmdAEdzD1X9lPFEmzg1BaXM HACeLqcmohEBBhRMNhmT2L8GMEqAOiQ= =J8Zq -----END PGP SIGNATURE----- --Apple-Mail=_77C82B65-197C-4B3C-981C-8512893D1E00-- From owner-freebsd-geom@FreeBSD.ORG Wed May 7 14:49:14 2014 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 402AA976; Wed, 7 May 2014 14:49:14 +0000 (UTC) Received: from mail.xcllnt.net (mail.xcllnt.net [50.0.150.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 097E9CC; Wed, 7 May 2014 14:49:10 +0000 (UTC) Received: from meganw-sslvpn-nc.jnpr.net ([66.129.239.13]) (authenticated bits=0) by mail.xcllnt.net (8.14.8/8.14.8) with ESMTP id s47En8DE018055 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 7 May 2014 07:49:09 -0700 (PDT) (envelope-from marcel@xcllnt.net) Content-Type: multipart/signed; boundary="Apple-Mail=_A7FA8774-15AC-4BFE-B502-B4B42678BA11"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: [RFC] Disconnect old geom classes from the build From: Marcel Moolenaar In-Reply-To: <536A39F3.1050807@FreeBSD.org> Date: Wed, 7 May 2014 07:49:02 -0700 Message-Id: <2099463C-87E3-4624-B5A2-B15A0CF9A2DD@xcllnt.net> References: <536A39F3.1050807@FreeBSD.org> To: "Andrey V. Elsukov" X-Mailer: Apple Mail (2.1874) Cc: freebsd-geom@FreeBSD.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 14:49:14 -0000 --Apple-Mail=_A7FA8774-15AC-4BFE-B502-B4B42678BA11 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=iso-8859-1 On May 7, 2014, at 6:49 AM, Andrey V. Elsukov wrote: > Hi All, > > There are several GEOM classes that aren't used by default for a long > time. I'm speaking about BSD, MBR, SUNLABEL and PC98. Now the PART class > implements of those functionality. Also there are FOX, UZIP and VOL_FFS > classes, that also have a replacement. > I propose disconnect these kernel modules from the build. > Your opinions? Yes, they should really be obsoleted... -- Marcel Moolenaar marcel@xcllnt.net --Apple-Mail=_A7FA8774-15AC-4BFE-B502-B4B42678BA11 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlNqR94ACgkQpgWlLWHuifY7BwCghTr++vHO8RlskV7TYASrYW1S srYAnAzbFw37tPZakxwQpyaxFUW2rEiw =2SYm -----END PGP SIGNATURE----- --Apple-Mail=_A7FA8774-15AC-4BFE-B502-B4B42678BA11-- From owner-freebsd-geom@FreeBSD.ORG Mon May 12 11:06:44 2014 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 EB4CAA8A for ; Mon, 12 May 2014 11:06:43 +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)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D84B026C1 for ; Mon, 12 May 2014 11:06:43 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s4CB6hCw067802 for ; Mon, 12 May 2014 11:06:43 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s4CB6hvr067800 for freebsd-geom@FreeBSD.org; Mon, 12 May 2014 11:06:43 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 12 May 2014 11:06:43 GMT Message-Id: <201405121106.s4CB6hvr067800@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.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 11:06:44 -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/188754 geom [geom] GEOM Problem: gmirror gm0 destroyed on shutdown 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 f 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. 81 problems total. From owner-freebsd-geom@FreeBSD.ORG Fri May 16 05:03:27 2014 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 9CE4C93F for ; Fri, 16 May 2014 05:03:27 +0000 (UTC) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 1B4AC27B7 for ; Fri, 16 May 2014 05:03:26 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 0132E3AE0E for ; Thu, 15 May 2014 22:03:20 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-geom@freebsd.org Subject: GEOM_PART: Integrity check failed (ada2, MBR) Date: Thu, 15 May 2014 22:03:20 -0700 Message-ID: <1758.1400216600@server1.tristatelogic.com> X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 05:03:27 -0000 I am getting the failure message shown in the Subject: line. I have no idea what is causing it or, more importantly, how to cure whatever the actual problem is. I would appreciate some help. The situation is as follows... I have two primary "desktop" systems. Each one contains one of these sATA hot-swap rack things: http://kingwin.com/products/cate/mobile/racks/images/sata/kf_252_bk/enlarge/KF_252_BK_enlarge4.jpg These have proven to be entirely reliable. I also have a relatively new 2.5" 1TB drive. I did the following with this drive: 1) I placed the 1tb drive into my #2 system and then booted that system using a recent vintage (0.18.2) version of the "Gparted Live" CD. 2) I used Gparted to create and initialize a GPT partition table on the drive. 3) I used Gparted to create and initialize a single partition (containing all free space on the drive) and had it (Gparted) create an ext3 filesystem on that partition. 4) I then performed a clean shutdown of Gparted. 5) I then removed the new 1tb drive in question from my #2 desktop system and moved it into the hot-swap rack of my main (FreeBSD 9.1-RELEASE) system (which already contains two other drives, i.e. ada0 and ada1). 6) I used the power switch on the rack to power on the drive. The result of the above operations is as follows: May 15 21:53:33 segfault kernel: ada2 at ata5 bus 0 scbus5 target 0 lun 0 May 15 21:53:33 segfault kernel: ada2: ATA-8 SATA 3.x device May 15 21:53:33 segfault kernel: ada2: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes) May 15 21:53:33 segfault kernel: ada2: 31MB (65134 512 byte sectors: 16H 63S/T 64C) May 15 21:53:33 segfault kernel: ada2: Previously was known as ad10 May 15 21:53:33 segfault kernel: GEOM_PART: integrity check failed (ada2, MBR) Please take note: At this point in time I *do* have a entry in my /dev directory named "ada2" however I *do not* have an entry there named "ada2p1" (or one named "ada2s1"). Please note also that I have re-tried all of the above steps, but in step #2 I instead had Gparted create a an MBR partition scheme on the drive, rather than GPT. This change however appears to make no different at all to the final outcome. (I still get the "Integrity check failed" either way.) Is there a known incompatability between Gparted and FreeBSD with respect to MBR and/or GPT partition tables? Was there any such in 9.1-RELEASE? Please let me know what other information I can or should provide in order to overcome this problem. Thank you. From owner-freebsd-geom@FreeBSD.ORG Fri May 16 11:04:23 2014 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 B210E227 for ; Fri, 16 May 2014 11:04:23 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4A94A22FF for ; Fri, 16 May 2014 11:04:22 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.8/8.14.8) with ESMTP id s4GB4Jmt034597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 16 May 2014 05:04:19 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.8/8.14.8/Submit) with ESMTP id s4GB4D1L034594; Fri, 16 May 2014 05:04:19 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Fri, 16 May 2014 05:04:13 -0600 (MDT) From: Warren Block To: "Ronald F. Guilmette" Subject: Re: GEOM_PART: Integrity check failed (ada2, MBR) In-Reply-To: <1758.1400216600@server1.tristatelogic.com> Message-ID: References: <1758.1400216600@server1.tristatelogic.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Fri, 16 May 2014 05:04:19 -0600 (MDT) Cc: freebsd-geom@freebsd.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 11:04:23 -0000 On Thu, 15 May 2014, Ronald F. Guilmette wrote: > 1) I placed the 1tb drive into my #2 system and then booted that system > using a recent vintage (0.18.2) version of the "Gparted Live" CD. > > 2) I used Gparted to create and initialize a GPT partition table on the > drive. > > 3) I used Gparted to create and initialize a single partition (containing > all free space on the drive) and had it (Gparted) create an ext3 filesystem > on that partition. > > 4) I then performed a clean shutdown of Gparted. > > 5) I then removed the new 1tb drive in question from my #2 desktop system > and moved it into the hot-swap rack of my main (FreeBSD 9.1-RELEASE) system > (which already contains two other drives, i.e. ada0 and ada1). > > 6) I used the power switch on the rack to power on the drive. > > The result of the above operations is as follows: > > May 15 21:53:33 segfault kernel: ada2 at ata5 bus 0 scbus5 target 0 lun 0 > May 15 21:53:33 segfault kernel: ada2: ATA-8 SATA 3.x device > May 15 21:53:33 segfault kernel: ada2: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes) > May 15 21:53:33 segfault kernel: ada2: 31MB (65134 512 byte sectors: 16H 63S/T 64C) > May 15 21:53:33 segfault kernel: ada2: Previously was known as ad10 > May 15 21:53:33 segfault kernel: GEOM_PART: integrity check failed (ada2, MBR) Some Linuxes (Linii?) might be creating "hybrid" GPTs, with a PMBR that is non-standard. I can't speak to what Gparted does. There is a sysctl to relax the strict checking in FreeBSD, but I would suggest using gpart(8) instead. (Backups necessary, etc., and this is off the top of my head and untested.): # gpart destroy -F ada2 # gpart create -s gpt ada2 # gpart add -t \!0x83 -b1m -a4k ada2 (That 0x83 is for the Linux partition type. gpart(8) might have a keyword for that, like "linux" or "linux-data".) Then newfs /dev/ada2p1 to ext2 or 3. The steps would be nearly identical for MBR, but avoid MBR if you can. From owner-freebsd-geom@FreeBSD.ORG Fri May 16 11:57:46 2014 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 7F6C9847 for ; Fri, 16 May 2014 11:57:46 +0000 (UTC) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 6208F26B2 for ; Fri, 16 May 2014 11:57:45 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id A31BB3AF6D; Fri, 16 May 2014 04:57:45 -0700 (PDT) From: "Ronald F. Guilmette" To: Warren Block Subject: Re: GEOM_PART: Integrity check failed (ada2, MBR) In-Reply-To: Date: Fri, 16 May 2014 04:57:45 -0700 Message-ID: <30820.1400241465@server1.tristatelogic.com> Cc: freebsd-geom@freebsd.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 11:57:46 -0000 In message , Warren Block wrote: >On Thu, 15 May 2014, Ronald F. Guilmette wrote: >>... >> May 15 21:53:33 segfault kernel: GEOM_PART: integrity check failed (ada2, MBR) > >Some Linuxes (Linii?) might be creating "hybrid" GPTs, with a PMBR that >is non-standard. I can't speak to what Gparted does. I would like to get to the bottom of this, and find out what is really happening, and which piece of software is actually at fault here. If I were to post the first 512 bytes of the drive in question (run through "od -c") then could you, Warren, tell me what the real problem is here and which piece of software is actually at fault? To me it is more than a little inexplicable that two such closely related operating systems (linux, FreeBSD) cannot even seem to agree on what the age-old and time-tested MBR format should look like. >There is a sysctl to relax the strict checking in FreeBSD, but I would >suggest using gpart(8) instead. If something is checking for correctness of the MBR then I most certainly *do not* have any desire to disable that. Certainly not now, when I don't even have the foggiest idea what the problem is. Nor do I have an immediate desire to simply use FreeBSD gpart to re- partition the drive and do the equivalent of newfs (for an ext3 fs) all over again. In short, I want to actually find out what the bleep is going wrong, and why, and then learn how to fix it. I greatly appreciate that you are willing to give me this particular fish Warren, but in this instance I'm going to (mix my metaphores and) look this gift fish in the mouth and ask you to _teach_ me how to fish instead. If Linux and FreeBSD can't even agree on what constitutes a valid MBR, then I think that we owe it to the next poor fool who tries to get these two OSes to ``interoperate'' in this specific manner to find out why not. Regards, rfg From owner-freebsd-geom@FreeBSD.ORG Fri May 16 12:04:32 2014 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 937CEE79 for ; Fri, 16 May 2014 12:04:32 +0000 (UTC) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 7A2702785 for ; Fri, 16 May 2014 12:04:32 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 0ABFA3AE99; Fri, 16 May 2014 05:04:32 -0700 (PDT) From: "Ronald F. Guilmette" To: Warren Block Subject: Re: GEOM_PART: Integrity check failed (ada2, MBR) In-Reply-To: Date: Fri, 16 May 2014 05:04:32 -0700 Message-ID: <30896.1400241872@server1.tristatelogic.com> Cc: freebsd-geom@freebsd.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 12:04:32 -0000 The first 512 bytes of the drive in question are now available here: ftp://ftp.tristatelogic.com/pub/ada2-512 That file contains the actual bytes. From owner-freebsd-geom@FreeBSD.ORG Fri May 16 13:03:48 2014 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 A7077F46 for ; Fri, 16 May 2014 13:03:48 +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)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 83DA42C5A for ; Fri, 16 May 2014 13:03:48 +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 s4GD3lco074410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 May 2014 06:03:47 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s4GD3lK2074409; Fri, 16 May 2014 06:03:47 -0700 (PDT) (envelope-from jmg) Date: Fri, 16 May 2014 06:03:47 -0700 From: John-Mark Gurney To: "Ronald F. Guilmette" Subject: Re: GEOM_PART: Integrity check failed (ada2, MBR) Message-ID: <20140516130346.GB43976@funkthat.com> Mail-Followup-To: "Ronald F. Guilmette" , freebsd-geom@freebsd.org References: <1758.1400216600@server1.tristatelogic.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1758.1400216600@server1.tristatelogic.com> 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-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Fri, 16 May 2014 06:03:47 -0700 (PDT) Cc: freebsd-geom@freebsd.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 13:03:48 -0000 Ronald F. Guilmette wrote this message on Thu, May 15, 2014 at 22:03 -0700: > I am getting the failure message shown in the Subject: line. I have > no idea what is causing it or, more importantly, how to cure whatever > the actual problem is. > > I would appreciate some help. > > The situation is as follows... > > I have two primary "desktop" systems. Each one contains one of these > sATA hot-swap rack things: > > http://kingwin.com/products/cate/mobile/racks/images/sata/kf_252_bk/enlarge/KF_252_BK_enlarge4.jpg > > These have proven to be entirely reliable. > > I also have a relatively new 2.5" 1TB drive. I did the following with > this drive: > > 1) I placed the 1tb drive into my #2 system and then booted that system > using a recent vintage (0.18.2) version of the "Gparted Live" CD. > > 2) I used Gparted to create and initialize a GPT partition table on the > drive. > > 3) I used Gparted to create and initialize a single partition (containing > all free space on the drive) and had it (Gparted) create an ext3 filesystem > on that partition. > > 4) I then performed a clean shutdown of Gparted. > > 5) I then removed the new 1tb drive in question from my #2 desktop system > and moved it into the hot-swap rack of my main (FreeBSD 9.1-RELEASE) system > (which already contains two other drives, i.e. ada0 and ada1). > > 6) I used the power switch on the rack to power on the drive. > > The result of the above operations is as follows: > > May 15 21:53:33 segfault kernel: ada2 at ata5 bus 0 scbus5 target 0 lun 0 > May 15 21:53:33 segfault kernel: ada2: ATA-8 SATA 3.x device > May 15 21:53:33 segfault kernel: ada2: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes) > May 15 21:53:33 segfault kernel: ada2: 31MB (65134 512 byte sectors: 16H 63S/T 64C) Wow, I just noticed this... FreeBSD is only seeing it as a 31MB drive instead of a 1TB drive... This is probably the problem... What do "diskinfo /dev/ada2" and "camcontrol identify ada2" return? If it really does return that the disk is only 31MB, we need to track this down, and this is why we're failing the integrity check of the MBR.. Thanks. -- 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 Fri May 16 19:39:02 2014 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 C4D8923D for ; Fri, 16 May 2014 19:39:02 +0000 (UTC) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 2B211211B for ; Fri, 16 May 2014 19:39:01 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 211DA3ADD8; Fri, 16 May 2014 12:38:51 -0700 (PDT) From: "Ronald F. Guilmette" To: John-Mark Gurney Subject: Re: GEOM_PART: Integrity check failed (ada2, MBR) In-Reply-To: <20140516130346.GB43976@funkthat.com> Date: Fri, 16 May 2014 12:38:51 -0700 Message-ID: <97826.1400269131@server1.tristatelogic.com> Cc: freebsd-geom@freebsd.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 19:39:02 -0000 In message <20140516130346.GB43976@funkthat.com>, John-Mark Gurney wrote: >> The result of the above operations is as follows: >> >> May 15 21:53:33 segfault kernel: ada2 at ata5 bus 0 scbus5 target 0 lun 0 >> May 15 21:53:33 segfault kernel: ada2: AT >A-8 SATA 3.x device >> May 15 21:53:33 segfault kernel: ada2: 300.000MB/s transfers (SATA 2.x, UDMA >5, PIO 8192bytes) >> May 15 21:53:33 segfault kernel: ada2: 31MB (65134 512 byte sectors: 16H 63S >/T 64C) > >Wow, I just noticed this... FreeBSD is only seeing it as a 31MB drive >instead of a 1TB drive... This is probably the problem... OHHHHH! Wow! Yea. That is MESSED UP! Good eye there! I hadn't noticed THAT! >What do "diskinfo /dev/ada2" and "camcontrol identify ada2" return? I have created files containing those two outputs. Please fetch them here: ftp://ftp.tristatelogic.com/pub/ada2.diskinfo ftp://ftp.tristatelogic.com/pub/ada2.camcontrol >If it really does return that the disk is only 31MB, we need to track this >down, and this is why we're failing the integrity check of the MBR.. I don't know how to properly read/interpret these outputs, so your further guidance would be greatly appreciated. I will say however that it does appear to me that both programs _are_ indeed viewing the drive in question as (perhaps) containing only 31MB... which is indeed seriously messed up. (It is absolutely the case that the drive in question is indeed a 1TB drive.) From owner-freebsd-geom@FreeBSD.ORG Fri May 16 20:03:38 2014 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 8A6289F1 for ; Fri, 16 May 2014 20:03:38 +0000 (UTC) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 040502394 for ; Fri, 16 May 2014 20:03:37 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 65C283ADB8; Fri, 16 May 2014 13:03:34 -0700 (PDT) From: "Ronald F. Guilmette" To: John-Mark Gurney Subject: Re: GEOM_PART: Integrity check failed (ada2, MBR) In-Reply-To: <20140516130346.GB43976@funkthat.com> Date: Fri, 16 May 2014 13:03:34 -0700 Message-ID: <91697.1400270614@server1.tristatelogic.com> Cc: freebsd-geom@freebsd.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2014 20:03:38 -0000 In message <20140516130346.GB43976@funkthat.com>, you wrote: >Ronald F. Guilmette wrote this message on Thu, May 15, 2014 at 22:03 -0700: >> May 15 21:53:33 segfault kernel: ada2 at ata5 bus 0 scbus5 target 0 lun 0 >> May 15 21:53:33 segfault kernel: ada2: ATA-8 SATA 3.x device >> May 15 21:53:33 segfault kernel: ada2: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes) >> May 15 21:53:33 segfault kernel: ada2: 31MB (65134 512 byte sectors: 16H 63S/T 64C) For this exact same physical drive, Linux fdisk reports the following: 255 heads 63 sectors/track 121601 cylinders Capacity: 1000.2 GB (I checked that just now.) From owner-freebsd-geom@FreeBSD.ORG Sat May 17 16:25:15 2014 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 3C69032E for ; Sat, 17 May 2014 16:25:15 +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)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id F3CDB21CB for ; Sat, 17 May 2014 16:25:14 +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 s4HGPDAP096065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 17 May 2014 09:25:14 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s4HGPDPD096064; Sat, 17 May 2014 09:25:13 -0700 (PDT) (envelope-from jmg) Date: Sat, 17 May 2014 09:25:13 -0700 From: John-Mark Gurney To: "Ronald F. Guilmette" Subject: Re: GEOM_PART: Integrity check failed (ada2, MBR) Message-ID: <20140517162513.GG43976@funkthat.com> Mail-Followup-To: "Ronald F. Guilmette" , freebsd-geom@freebsd.org References: <20140516130346.GB43976@funkthat.com> <97826.1400269131@server1.tristatelogic.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <97826.1400269131@server1.tristatelogic.com> 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-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sat, 17 May 2014 09:25:14 -0700 (PDT) Cc: freebsd-geom@freebsd.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 May 2014 16:25:15 -0000 Ronald F. Guilmette wrote this message on Fri, May 16, 2014 at 12:38 -0700: > > In message <20140516130346.GB43976@funkthat.com>, > John-Mark Gurney wrote: > > >> The result of the above operations is as follows: > >> > >> May 15 21:53:33 segfault kernel: ada2 at ata5 bus 0 scbus5 target 0 lun 0 > >> May 15 21:53:33 segfault kernel: ada2: AT > >A-8 SATA 3.x device > >> May 15 21:53:33 segfault kernel: ada2: 300.000MB/s transfers (SATA 2.x, UDMA > >5, PIO 8192bytes) > >> May 15 21:53:33 segfault kernel: ada2: 31MB (65134 512 byte sectors: 16H 63S > >/T 64C) > > > >Wow, I just noticed this... FreeBSD is only seeing it as a 31MB drive > >instead of a 1TB drive... This is probably the problem... > > OHHHHH! Wow! Yea. That is MESSED UP! > > Good eye there! I hadn't noticed THAT! > > >What do "diskinfo /dev/ada2" and "camcontrol identify ada2" return? > > I have created files containing those two outputs. Please fetch them here: > > ftp://ftp.tristatelogic.com/pub/ada2.diskinfo > ftp://ftp.tristatelogic.com/pub/ada2.camcontrol > > >If it really does return that the disk is only 31MB, we need to track this > >down, and this is why we're failing the integrity check of the MBR.. > > I don't know how to properly read/interpret these outputs, so your further > guidance would be greatly appreciated. > > I will say however that it does appear to me that both programs _are_ > indeed viewing the drive in question as (perhaps) containing only 31MB... > which is indeed seriously messed up. > > (It is absolutely the case that the drive in question is indeed a 1TB drive.) Can you get a memstick of 11-CURRENT from: https://www.freebsd.org/snapshots/ and get the output of: camcontrol identify ada2 -v from a boot of the memstick? mav thinks that it might be an issue w/ HPA, and this should help track it down. Thanks. -- 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 Sun May 18 00:10:33 2014 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 9E146DC3 for ; Sun, 18 May 2014 00:10:33 +0000 (UTC) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 8020E2472 for ; Sun, 18 May 2014 00:10:32 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 022593AC90 for ; Sat, 17 May 2014 17:00:56 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-geom@freebsd.org Subject: Re: GEOM_PART: Integrity check failed (ada2, MBR) In-Reply-To: <20140517162513.GG43976@funkthat.com> Date: Sat, 17 May 2014 17:00:56 -0700 Message-ID: <73415.1400371256@server1.tristatelogic.com> X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 May 2014 00:10:33 -0000 In message <20140517162513.GG43976@funkthat.com>, John-Mark Gurney wrote: >Ronald F. Guilmette wrote this message on Fri, May 16, 2014 at 12:38 -0700: >> >> In message <20140516130346.GB43976@funkthat.com>, >> John-Mark Gurney wrote: >> >Wow, I just noticed this... FreeBSD is only seeing it as a 31MB drive >> >instead of a 1TB drive... This is probably the problem... >> >> OHHHHH! Wow! Yea. That is MESSED UP! >> ... >Can you get a memstick of 11-CURRENT from: >https://www.freebsd.org/snapshots/ >and get the output of: >camcontrol identify ada2 -v >from a boot of the memstick? mav thinks that it might be an issue w/ >HPA, and this should help track it down. I don't think that there is any need anymore for me to do the above steps. I am now convinced that I do know what has caused this rather remarkable (and remarkably annoying) problem. I had forgotten all about this, until now, but there is apparently a known problem where older (pre-2010) Gigabyte motherboards will in fact create a Host Protected Area (HPA) on the ``first'' ATA drive in a given system, *and* that in cases where the drive is 1TB or larger, the result will be a drive that self-identifies as being only 31 (or 32) megabytes big. (You can google for this known problem and you'll find a _lot_ of references to it.) The specific 1 TB drive on which I experienced this problem had been working just fine with no problems whatsoever on another system that I have here. However I made the mistake of trying to put it into my #2 desktop system, which is based on a vintage 2006 Gigabyte motherboard. I now firmly believe that this caused the specific form of corruption that now afflicts the drive in question. I already have sought, and have already been provided with the steps that I need to undertake in order to "repair" the apparent capacity of the drive in question, and I am already making plans to replace my *&^%$#@ Gigabyte motherboard with something different with all due haste. I will *never* purchase another Gigabyte motherboard as long as I live! (In addition to this extraordinarily problem, it also has had a number of obscure problems booting various things from USB-attached mass storage.) Anyway, my thanks to all involved for their time and effort considering my unfortunate plight. Who knew that just connecting an otherwise flawless hard drive to a specific kind of motherboard would instantly render it effectively brain dead? Regards, rfg From owner-freebsd-geom@FreeBSD.ORG Sun May 18 12:42:47 2014 Return-Path: Delivered-To: freebsd-geom@smarthost.ysv.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 B6DE7641; Sun, 18 May 2014 12:42:47 +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)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8C7462726; Sun, 18 May 2014 12:42:47 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s4ICgljI000950; Sun, 18 May 2014 12:42:47 GMT (envelope-from brueffer@freefall.freebsd.org) Received: (from brueffer@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s4ICgkcE000938; Sun, 18 May 2014 14:42:46 +0200 (CEST) (envelope-from brueffer) Date: Sun, 18 May 2014 14:42:46 +0200 (CEST) Message-Id: <201405181242.s4ICgkcE000938@freefall.freebsd.org> To: mattblists@icritical.com, brueffer@FreeBSD.org, freebsd-geom@FreeBSD.org From: brueffer@FreeBSD.org Subject: Re: kern/176744: [geom] [patch] BIO_FLUSH not recorded by devstats X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 May 2014 12:42:47 -0000 Synopsis: [geom] [patch] BIO_FLUSH not recorded by devstats State-Changed-From-To: feedback->patched State-Changed-By: brueffer State-Changed-When: Sun May 18 14:41:19 CEST 2014 State-Changed-Why: mav@ committed the necessary changes to HEAD in r266319. http://www.freebsd.org/cgi/query-pr.cgi?pr=176744 From owner-freebsd-geom@FreeBSD.ORG Mon May 19 11:06:45 2014 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 4913D35A for ; Mon, 19 May 2014 11:06:45 +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)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 31A7E2DAD for ; Mon, 19 May 2014 11:06:45 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s4JB6jsu080005 for ; Mon, 19 May 2014 11:06:45 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s4JB6iw2080003 for freebsd-geom@FreeBSD.org; Mon, 19 May 2014 11:06:44 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 19 May 2014 11:06:44 GMT Message-Id: <201405191106.s4JB6iw2080003@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.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 May 2014 11:06:45 -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/188754 geom [geom] GEOM Problem: gmirror gm0 destroyed on shutdown 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 p 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. 81 problems total. From owner-freebsd-geom@FreeBSD.ORG Tue May 20 18:59:38 2014 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 DFD03BF8 for ; Tue, 20 May 2014 18:59:37 +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)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BD7012566 for ; Tue, 20 May 2014 18:59:37 +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 s4KIxag9060824 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 May 2014 11:59:37 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s4KIxZEK060823; Tue, 20 May 2014 11:59:35 -0700 (PDT) (envelope-from jmg) Date: Tue, 20 May 2014 11:59:35 -0700 From: John-Mark Gurney To: "Ronald F. Guilmette" Subject: Re: GEOM_PART: Integrity check failed (ada2, MBR) Message-ID: <20140520185935.GS43976@funkthat.com> Mail-Followup-To: "Ronald F. Guilmette" , freebsd-geom@freebsd.org References: <20140517162513.GG43976@funkthat.com> <73415.1400371256@server1.tristatelogic.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <73415.1400371256@server1.tristatelogic.com> 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-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Tue, 20 May 2014 11:59:37 -0700 (PDT) Cc: freebsd-geom@freebsd.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 18:59:38 -0000 Ronald F. Guilmette wrote this message on Sat, May 17, 2014 at 17:00 -0700: > In message <20140517162513.GG43976@funkthat.com>, > John-Mark Gurney wrote: > > >Ronald F. Guilmette wrote this message on Fri, May 16, 2014 at 12:38 -0700: > >> > >> In message <20140516130346.GB43976@funkthat.com>, > >> John-Mark Gurney wrote: > >> >Wow, I just noticed this... FreeBSD is only seeing it as a 31MB drive > >> >instead of a 1TB drive... This is probably the problem... > >> > >> OHHHHH! Wow! Yea. That is MESSED UP! > >> ... > > >Can you get a memstick of 11-CURRENT from: > >https://www.freebsd.org/snapshots/ > >and get the output of: > >camcontrol identify ada2 -v > >from a boot of the memstick? mav thinks that it might be an issue w/ > >HPA, and this should help track it down. > > I don't think that there is any need anymore for me to do the above > steps. I am now convinced that I do know what has caused this rather > remarkable (and remarkably annoying) problem. > > I had forgotten all about this, until now, but there is apparently a > known problem where older (pre-2010) Gigabyte motherboards will in > fact create a Host Protected Area (HPA) on the ``first'' ATA drive > in a given system, *and* that in cases where the drive is 1TB or larger, > the result will be a drive that self-identifies as being only 31 (or 32) > megabytes big. (You can google for this known problem and you'll find a > _lot_ of references to it.) > > The specific 1 TB drive on which I experienced this problem had been > working just fine with no problems whatsoever on another system that I > have here. However I made the mistake of trying to put it into my #2 > desktop system, which is based on a vintage 2006 Gigabyte motherboard. > > I now firmly believe that this caused the specific form of corruption > that now afflicts the drive in question. > > I already have sought, and have already been provided with the steps > that I need to undertake in order to "repair" the apparent capacity of > the drive in question, and I am already making plans to replace my > *&^%$#@ Gigabyte motherboard with something different with all due > haste. > > I will *never* purchase another Gigabyte motherboard as long as I live! > (In addition to this extraordinarily problem, it also has had a number > of obscure problems booting various things from USB-attached mass > storage.) > > Anyway, my thanks to all involved for their time and effort considering > my unfortunate plight. Who knew that just connecting an otherwise > flawless hard drive to a specific kind of motherboard would instantly > render it effectively brain dead? Wow, this is sooo BAD... Motherboards should never touch a HD like this w/o consent from the user... Though of course the other thing is that Gigabyte's QA is soo bad that they didn't catch such a basic bug in testing... but this does sound like your issue though, glad you found it... And this is useful info for others too, Thanks. -- 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 Tue May 20 19:45:35 2014 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 2FDE399 for ; Tue, 20 May 2014 19:45:35 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id E84162A40 for ; Tue, 20 May 2014 19:45:34 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id 5C6BB20E7088D; Tue, 20 May 2014 19:45:32 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.multiplay.co.uk X-Spam-Level: ** X-Spam-Status: No, score=2.2 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1,HELO_NO_DOMAIN,RDNS_DYNAMIC,STOX_REPLY_TYPE autolearn=no version=3.3.1 Received: from r2d2 (82-69-141-170.dsl.in-addr.zen.co.uk [82.69.141.170]) by smtp1.multiplay.co.uk (Postfix) with ESMTPS id 1F3D620E7088A; Tue, 20 May 2014 19:45:27 +0000 (UTC) Message-ID: <90779722305645B99AA673EDA11C349F@multiplay.co.uk> From: "Steven Hartland" To: "Ronald F. Guilmette" , References: <73415.1400371256@server1.tristatelogic.com> Subject: Re: GEOM_PART: Integrity check failed (ada2, MBR) Date: Tue, 20 May 2014 20:45:28 +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.6157 X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 19:45:35 -0000 ----- Original Message ----- From: "Ronald F. Guilmette" > I already have sought, and have already been provided with the steps > that I need to undertake in order to "repair" the apparent capacity of > the drive in question, and I am already making plans to replace my > *&^%$#@ Gigabyte motherboard with something different with all due > haste. Just in case you or others are unaware later versions of camcontrol have the ability to see and edit / remove HPA. Regards Steve From owner-freebsd-geom@FreeBSD.ORG Tue May 20 20:17:34 2014 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 2217F2DE for ; Tue, 20 May 2014 20:17:34 +0000 (UTC) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id EFCD52E0B for ; Tue, 20 May 2014 20:17:33 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id EB03E3AE7F; Tue, 20 May 2014 13:17:32 -0700 (PDT) From: "Ronald F. Guilmette" To: John-Mark Gurney Subject: Re: GEOM_PART: Integrity check failed (ada2, MBR) In-Reply-To: <20140520185935.GS43976@funkthat.com> Date: Tue, 20 May 2014 13:17:32 -0700 Message-ID: <38378.1400617052@server1.tristatelogic.com> Cc: freebsd-geom@freebsd.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 20:17:34 -0000 In message <20140520185935.GS43976@funkthat.com>, John-Mark Gurney wrote: >Ronald F. Guilmette wrote this message on Sat, May 17, 2014 at 17:00 -0700: >> I had forgotten all about this, until now, but there is apparently a >> known problem where older (pre-2010) Gigabyte motherboards will in >> fact create a Host Protected Area (HPA) on the ``first'' ATA drive >> in a given system, *and* that in cases where the drive is 1TB or larger, >> the result will be a drive that self-identifies as being only 31 (or 32) >> megabytes big. (You can google for this known problem and you'll find a >> _lot_ of references to it.) >> ... > >Wow, this is sooo BAD... Yes. It is. Perfectly awful behavior. >Motherboards should never touch a HD like >this w/o consent from the user... I can only agree. >but this does sound like your issue though, glad you found it... > >And this is useful info for others too, Thanks. Here is some more useful info for others who find themselves faced with this problem, and who struggle, as I have, to try to get the affected/afflicted drive back to normal... There are a number of tools out there which claim to provide some assistance in dealing with this specific problem, but some of them are actually appearing to me to be non-useful at the present time. The first two of these, listed below, can, in theory, correct the problem by performing what's called a "secure erase" operation on the drive. This is a special feature of some (most?) newer vintage pATA and sATA drives. They have a built-in special ATA "secure erase" command which, I gather, when it can be made to work, should... as a side effect... also set the drive capacity back to equal the actual physical capacity. 1) HDDErase. This is a DOS-based tool which is provided either as a stand-alone DOS .EXE file or as a CD image (.ISO). I've used this is the past with great success, but it stopped being supported or updated in 2008, and I haven't used in in so long that I can't even figure out how to make the bootable CD image work anymore... and in fact it doesn't seem to work at all on my 2 main systems here. In short, this is a dead end. (However people more clever than me could probably still get it to work, even on newer motherboards.) 2) There is a commercial program called "Parted Magic" which also allegedly has a capability to perform the ATA "secure erase" operation, but the version that I have of this... which is integrated into the free "Ultimate Boot CD".. doesn't seem to actually have this working. When I tried to use this feature, no matter what drive I had installed the thing just kept telling me that the drive didn't support the feature. And I tried several different drives. (Perhaps I just need a updated copy of UBCD or else I need to pay for the commercial version of Parted Magic, although I'm not sure either of those would help any, quite frankly.) 3) There is also the standard Linux program called "hdparm" which has a special -N option for dealing with these kinds of problems. Using -N with no options is supposed to show you the supposed current capacity of the drive and then also the actual physical size of the drive. And then you can re-invoke "hdparm -N' with an argument for the -N option which will cause the supposed current capacity of the drive to be set to anything you want. But when I ran the program (which fortunately is accessible from within a shell window in the Gparted LiveCD) it told me that the logical and physical sector counts for my goofed up drive were exactly the same! So I'm suspicious that this doesn't work right either. The good news is that if anybody figures out how to make this work properly, then, in theory, one should be able to reset the drive capacity to the real capacity *without* having to do a "secure erase" operation, which can take up to several hours for a large drive. 4) Finally, there is a free program out there called HDAT2 which seems to me to be dedicated to dealing with low-level disk issues exactly like this. It has built-in functionality to entirely remove either a Host Protected Area (HPA) or a Device Configuration Overlay (DCO) or both from a drive. I seem to be having some trouble getting that to work right just now, but that may be because I've been (foolishly) trying to use it on the same *&^%$#@ bloody Gigabyte-based system that caused the bleedin' problem in the first place. Sigh. I'll have to take down my main server in order to try running HDAT2 again, on that system, and against the specific corrupted 1TB drive that, for the moment, still remains all goofed up. (Note that HDAT2 is also an option that does not necessitate performing a time consuming "secure erase" operation on the drive.) In short, of all of the above options for getting the drive un-hosed, HDAT2 appears the most promising at the present time, but I need to investigate further. And I don't have time for that at the moment. I wanted to post all of the above info for the benefit of others who, like me, get bitten by this sort of problem and then... as I have... spend hours and hours googling and flailing around, looking for a way to just simply get the drive back to normal. I still haven't succeeded at that, but neither have I given up. And I won't, because I have no intention of throwing an otherwise perfectly good and near-new 1TB drive into the trash. I'm gonna fix that drive, come hell or high water. I just need to find the time... Regards, rfg From owner-freebsd-geom@FreeBSD.ORG Tue May 20 20:20:00 2014 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 CE895453 for ; Tue, 20 May 2014 20:20:00 +0000 (UTC) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id B5C8D2E2B for ; Tue, 20 May 2014 20:20:00 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 92CEF3ADCF; Tue, 20 May 2014 13:20:00 -0700 (PDT) From: "Ronald F. Guilmette" To: "Steven Hartland" , freebsd-geom@freebsd.org Subject: Re: GEOM_PART: Integrity check failed (ada2, MBR) In-Reply-To: <90779722305645B99AA673EDA11C349F@multiplay.co.uk> Date: Tue, 20 May 2014 13:20:00 -0700 Message-ID: <38408.1400617200@server1.tristatelogic.com> X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 20:20:00 -0000 In message <90779722305645B99AA673EDA11C349F@multiplay.co.uk>, "Steven Hartland" wrote: >----- Original Message ----- >From: "Ronald F. Guilmette" > >> I already have sought, and have already been provided with the steps >> that I need to undertake in order to "repair" the apparent capacity of >> the drive in question, and I am already making plans to replace my >> *&^%$#@ Gigabyte motherboard with something different with all due >> haste. > >Just in case you or others are unaware later versions of camcontrol have >the ability to see and edit / remove HPA. I, for one, was most certainly *not* aware of that. Could I ask you to please elaborate? How would this be done... using camcontrol? From owner-freebsd-geom@FreeBSD.ORG Tue May 20 20:50:07 2014 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 16C8E14C for ; Tue, 20 May 2014 20:50:07 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id CF2FF213B for ; Tue, 20 May 2014 20:50:06 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id 580F920E7088C; Tue, 20 May 2014 20:50:04 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.multiplay.co.uk X-Spam-Level: ** X-Spam-Status: No, score=2.8 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1, HELO_NO_DOMAIN, RDNS_DYNAMIC, STOX_REPLY_TYPE, TVD_FINGER_02 autolearn=no version=3.3.1 Received: from r2d2 (82-69-141-170.dsl.in-addr.zen.co.uk [82.69.141.170]) by smtp1.multiplay.co.uk (Postfix) with ESMTPS id 69CC020E7088A; Tue, 20 May 2014 20:50:00 +0000 (UTC) Message-ID: From: "Steven Hartland" To: "Ronald F. Guilmette" , References: <38408.1400617200@server1.tristatelogic.com> Subject: Re: GEOM_PART: Integrity check failed (ada2, MBR) Date: Tue, 20 May 2014 21:49:54 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; 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.6157 X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 20:50:07 -0000 ----- Original Message ----- From: "Ronald F. Guilmette" To: "Steven Hartland" ; Sent: Tuesday, May 20, 2014 9:20 PM Subject: Re: GEOM_PART: Integrity check failed (ada2, MBR) > > In message <90779722305645B99AA673EDA11C349F@multiplay.co.uk>, > "Steven Hartland" wrote: > >>----- Original Message ----- >>From: "Ronald F. Guilmette" >> >>> I already have sought, and have already been provided with the steps >>> that I need to undertake in order to "repair" the apparent capacity of >>> the drive in question, and I am already making plans to replace my >>> *&^%$#@ Gigabyte motherboard with something different with all due >>> haste. >> >>Just in case you or others are unaware later versions of camcontrol have >>the ability to see and edit / remove HPA. > > I, for one, was most certainly *not* aware of that. > > Could I ask you to please elaborate? How would this be done... using > camcontrol? > >From memory, as its been a while since I wrote it, first use identify to see the details: camcontrol identify ata0 You'll see the details of HPA at the bottom e.g. Host Protected Area (HPA) yes yes 33554432/250069680 HPA - Security no If you're disk has HPA enabled you can remove it by configuring the max sectors to the full disk size (the number on the right) If the drive doesn't have security (a password set) as above: camcontrol hpa ada0 -s 250069680 -P If it is locked you need to specify the password to unlock it. camcontrol hpa ada0 -s 250069680 -P -U For more details see man camcontrol. Hope this helps. Regards Steve From owner-freebsd-geom@FreeBSD.ORG Tue May 20 20:59:19 2014 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 9121527B for ; Tue, 20 May 2014 20:59:19 +0000 (UTC) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 6A0082226 for ; Tue, 20 May 2014 20:59:18 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id DA52F3AD36; Tue, 20 May 2014 13:59:18 -0700 (PDT) From: "Ronald F. Guilmette" To: "Steven Hartland" Subject: Re: GEOM_PART: Integrity check failed (ada2, MBR) In-Reply-To: Date: Tue, 20 May 2014 13:59:18 -0700 Message-ID: <64314.1400619558@server1.tristatelogic.com> Cc: freebsd-geom@freebsd.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 20:59:19 -0000 In message , "Steven Hartland" wrote: >>From memory, as its been a while since I wrote it, first use identify to >see the details: >camcontrol identify ata0 I sorry to report that I am not seeing whatever ist is that you are talking about. Is this perhaps because i am still running 9.1-RELEASE? >You'll see the details of HPA at the bottom e.g. >Host Protected Area (HPA) yes yes 33554432/250069680 >HPA - Security no I'm not seeing anything even remotely like that... =================================================================== # camcontrol identify ada2 pass5: ATA-8 SATA 3.x device pass5: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes) protocol ATA/ATAPI-8 SATA 3.x device model Hitachi HTS541010A9E680 firmware revision JA0OA480 serial number JB40001MGBHX2D WWN 5000cca6c6c53bca cylinders 64 heads 16 sectors/track 63 sector size logical 512, physical 4096, offset 0 LBA supported 65134 sectors LBA48 supported 65134 sectors PIO supported PIO4 DMA supported WDMA2 UDMA6 media RPM 5400 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 yes yes 16512/0x4080 automatic acoustic management no no media status notification no no power-up in Standby yes no write-read-verify no no unload yes yes free-fall no no data set management (TRIM) no From owner-freebsd-geom@FreeBSD.ORG Tue May 20 21:23:36 2014 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 AD709166 for ; Tue, 20 May 2014 21:23:36 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id 715F3250D for ; Tue, 20 May 2014 21:23:36 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id 0DCC520E7088C; Tue, 20 May 2014 21:23:35 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.multiplay.co.uk X-Spam-Level: ** X-Spam-Status: No, score=2.8 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1, HELO_NO_DOMAIN, RDNS_DYNAMIC, STOX_REPLY_TYPE, TVD_FINGER_02 autolearn=no version=3.3.1 Received: from r2d2 (82-69-141-170.dsl.in-addr.zen.co.uk [82.69.141.170]) by smtp1.multiplay.co.uk (Postfix) with ESMTPS id 3CD5F20E7088A; Tue, 20 May 2014 21:23:31 +0000 (UTC) Message-ID: <7AAB053193784DEB9840B2758CD37681@multiplay.co.uk> From: "Steven Hartland" To: "Ronald F. Guilmette" References: <64314.1400619558@server1.tristatelogic.com> Subject: Re: GEOM_PART: Integrity check failed (ada2, MBR) Date: Tue, 20 May 2014 22:23:32 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; 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.6157 Cc: freebsd-geom@freebsd.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 21:23:36 -0000 ----- Original Message ----- From: "Ronald F. Guilmette" To: "Steven Hartland" Cc: Sent: Tuesday, May 20, 2014 9:59 PM Subject: Re: GEOM_PART: Integrity check failed (ada2, MBR) > > In message , > "Steven Hartland" wrote: > >>>From memory, as its been a while since I wrote it, first use identify to >>see the details: >>camcontrol identify ata0 > > I sorry to report that I am not seeing whatever ist is that you > are talking about. Is this perhaps because i am still running > 9.1-RELEASE? Correct you'll need 9.2 or later I'm afraid. You could boot to a ISO etc such as the ones which can be grabbed from http://mfsbsd.vx.sk which are small and useful for things like this. Regards Steve From owner-freebsd-geom@FreeBSD.ORG Tue May 20 21:53:25 2014 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 0EB5A7A4 for ; Tue, 20 May 2014 21:53:25 +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)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DBB1E27C4 for ; Tue, 20 May 2014 21:53:24 +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 s4KLrNlk063103 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 May 2014 14:53:23 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s4KLrN6H063102; Tue, 20 May 2014 14:53:23 -0700 (PDT) (envelope-from jmg) Date: Tue, 20 May 2014 14:53:23 -0700 From: John-Mark Gurney To: "Ronald F. Guilmette" Subject: Re: GEOM_PART: Integrity check failed (ada2, MBR) Message-ID: <20140520215323.GV43976@funkthat.com> Mail-Followup-To: "Ronald F. Guilmette" , freebsd-geom@freebsd.org References: <20140520185935.GS43976@funkthat.com> <38378.1400617052@server1.tristatelogic.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <38378.1400617052@server1.tristatelogic.com> 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-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Tue, 20 May 2014 14:53:23 -0700 (PDT) Cc: freebsd-geom@freebsd.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 21:53:25 -0000 Ronald F. Guilmette wrote this message on Tue, May 20, 2014 at 13:17 -0700: > > In message <20140520185935.GS43976@funkthat.com>, > John-Mark Gurney wrote: > > >Ronald F. Guilmette wrote this message on Sat, May 17, 2014 at 17:00 -0700: > >> I had forgotten all about this, until now, but there is apparently a > >> known problem where older (pre-2010) Gigabyte motherboards will in > >> fact create a Host Protected Area (HPA) on the ``first'' ATA drive > >> in a given system, *and* that in cases where the drive is 1TB or larger, > >> the result will be a drive that self-identifies as being only 31 (or 32) > >> megabytes big. (You can google for this known problem and you'll find a > >> _lot_ of references to it.) > >> ... > > > >Wow, this is sooo BAD... > > Yes. It is. Perfectly awful behavior. > > >Motherboards should never touch a HD like > >this w/o consent from the user... > > I can only agree. > > >but this does sound like your issue though, glad you found it... > > > >And this is useful info for others too, Thanks. > > Here is some more useful info for others who find themselves faced > with this problem, and who struggle, as I have, to try to get the > affected/afflicted drive back to normal... > > There are a number of tools out there which claim to provide some > assistance in dealing with this specific problem, but some of them > are actually appearing to me to be non-useful at the present time. > > The first two of these, listed below, can, in theory, correct the problem > by performing what's called a "secure erase" operation on the drive. > This is a special feature of some (most?) newer vintage pATA and sATA > drives. They have a built-in special ATA "secure erase" command which, > I gather, when it can be made to work, should... as a side effect... > also set the drive capacity back to equal the actual physical capacity. [...] > I wanted to post all of the above info for the benefit of others who, > like me, get bitten by this sort of problem and then... as I have... > spend hours and hours googling and flailing around, looking for a way > to just simply get the drive back to normal. > > I still haven't succeeded at that, but neither have I given up. And > I won't, because I have no intention of throwing an otherwise perfectly > good and near-new 1TB drive into the trash. I'm gonna fix that drive, > come hell or high water. I just need to find the time... Have you tried camcontrol on FreeBSD-HEAD... It may also be in 10.0-R, as the manpage for camcontrol has it too: hpa Update or report Host Protected Area details. By default camcontrol will print out the HPA support and associated set- tings of the device. The hpa command takes several optional arguments: https://www.freebsd.org/cgi/man.cgi?query=camcontrol&manpath=FreeBSD+10.0-RELEASE There are memstick images to make testing this out easier... It also looks like camcontrol has the option to do the secure erase you were talking about... If the bios does some of this, it may be easiest to hot plug the drive so the BIOS never gets a chance to touch it before you run the commands... -- 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 May 22 22:03:59 2014 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 7CC9CC28 for ; Thu, 22 May 2014 22:03:59 +0000 (UTC) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 6016E207B for ; Thu, 22 May 2014 22:03:58 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 21BCC3AD92 for ; Thu, 22 May 2014 15:03:58 -0700 (PDT) From: "Ronald F. Guilmette" To: freebsd-geom@freebsd.org Subject: Re: GEOM_PART: Integrity check failed (ada2, MBR) In-Reply-To: <38378.1400617052@server1.tristatelogic.com> Date: Thu, 22 May 2014 15:03:58 -0700 Message-ID: <1801.1400796238@server1.tristatelogic.com> X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 22:03:59 -0000 For the benefit of posterity, I though that I should mention here (so that it goes into the archives) that after much fumbling around I did finally salvage the 1TB drive that I have that was apparently goofed up by my 2006 vintage Gigabyte motherboard. (As I had pre- viously reported, older Gigabyte motherboards can, apparently, screw up a 1TB drive in such a way as to make it appear to only have a capacity of 31 MB... or 32 MB... or 33.3 MB, depending on what tool is doing the counting.) The tool that I used for this repair task, in the end, was HDAT2, which is apparently a very powerful tool with a lot of features. Unortunately, whereas HDAT2 has lots of capabilities for fiddling lots of low-level disk settings, its fine feature set is somewhat compensated for by the fact that its user interface is, um, rather sub-optimal. Thus, it was not immediately apparent how to achieve the goal while using HDAT2. Here is the short version of how to do it: 1) On the main menu, use the up/down arrow keys to select (highlight) which drive you want to perform the operation on. Then hit enter or return. 2) On the next menu that comes up, use the up/down arrow keys again to select the "HPA" sub-menu. Hit enter/return. 3) On the HPA sub-menu select "Set Max Address" and hit enter/return. 4) On the next screen you see, there should be various well-labeled numbers displayed, in particular the drive's current real (physical) capacity and also the current logical capacity. Also, there are two fields where you can indicate how many sectors you want, in future, to be in the "user" area and how many in the "hidden" area. These should by default already be set to (a) the actual number of physical sectors and (b) zero, respectively. If not, then set them to whatever you want them to be. 5) Hit the "S" (Set) key. (This was the part that was less than entirely obvious.) 6) Hit the ESC key a few times until you find yourself back at a command prompt. 7) Power down the machine. 8) You are now done and your drive has been fixed. Live in harmony and happiness for the rest of your days, or at least until some other motherboard manufacturer decides to give it to you without even the benefit of Vaseline. Regards, rfg From owner-freebsd-geom@FreeBSD.ORG Mon May 26 11:06:45 2014 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 C1E25D96 for ; Mon, 26 May 2014 11:06:45 +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)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ADFBA24D9 for ; Mon, 26 May 2014 11:06:45 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s4QB6j9j032010 for ; Mon, 26 May 2014 11:06:45 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s4QB6j4E032007 for freebsd-geom@FreeBSD.org; Mon, 26 May 2014 11:06:45 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 26 May 2014 11:06:45 GMT Message-Id: <201405261106.s4QB6j4E032007@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.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 11:06:45 -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/188754 geom [geom] GEOM Problem: gmirror gm0 destroyed on shutdown 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 p 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. 81 problems total. From owner-freebsd-geom@FreeBSD.ORG Wed May 28 15:15:14 2014 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 E68399DE for ; Wed, 28 May 2014 15:15:14 +0000 (UTC) Received: from srv00.inetstat.net (srv00.inetstat.net [91.121.154.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "srv00.inetstat.net", Issuer "srv00.inetstat.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AC15B21A1 for ; Wed, 28 May 2014 15:15:14 +0000 (UTC) Received: from srv00.inetstat.net (localhost [127.0.0.1]) by srv00.inetstat.net (Postfix) with ESMTP id BC85C3ACD9 for ; Wed, 28 May 2014 15:15:05 +0000 (UTC) X-Virus-Scanned: amavisd-new at inetstat.net Received: from srv00.inetstat.net ([IPv6:::1]) by srv00.inetstat.net (srv00.inetstat.net [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id MSFLJIcSd0ha; Wed, 28 May 2014 15:15:05 +0000 (UTC) Received: by srv00.inetstat.net (Postfix, from userid 1001) id 2AE813ACD8; Wed, 28 May 2014 15:15:05 +0000 (UTC) Date: Wed, 28 May 2014 15:15:05 +0000 From: Paul J Murphy To: freebsd-geom@freebsd.org Subject: Re: conf/190152: [patch] [rc] gmirror savecore support Message-ID: <20140528151505.GA42484@srv00.inetstat.net> References: <5c0c75150aa4e34ba25db65258052128@lhaven.homeip.net> <20140528111156.GA42016@srv00.inetstat.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140528111156.GA42016@srv00.inetstat.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 15:15:15 -0000 http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/190152 Hi geom-people, a friendly heads-up on the above PR. I'm seeking validation of my belief that there's no changes necessary to /etc/rc.d/dumpon, only /etc/rc.d/savecore. The kernel will always deterministically pick a single physical device within the mirror, and we just need to use "prefer" to force the same determinism when savecore runs, right? (With the obvious caveat that failed and replaced devices, or other changes to the devices and their priorities that make up the mirror, will change the results of the determinism.) Any feedback on my patch in conf/190152 is welcome. Its aim is to at least cover the common and simple cases with gmirrored system disks. See also http://www.freebsd.org/cgi/query-pr.cgi?pr=docs/178818 which initially was attempting the fix via dumpon alone. Thanks, Paul. From owner-freebsd-geom@FreeBSD.ORG Sun Jun 1 14:17:32 2014 Return-Path: Delivered-To: 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 BE0399D7; Sun, 1 Jun 2014 14:17:32 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 73D0D2044; Sun, 1 Jun 2014 14:17:29 +0000 (UTC) Received: from [192.168.200.102] (c-50-131-4-11.hsd1.ca.comcast.net [50.131.4.11]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 34705193D9B; Sun, 1 Jun 2014 14:17:27 +0000 (UTC) Subject: Re: diskid documentation From: Sean Bruno Reply-To: sbruno@freebsd.org To: "Michael W. Lucas" In-Reply-To: <20140601134147.GA99583@bewilderbeast.blackhelicopters.org> References: <20140601134147.GA99583@bewilderbeast.blackhelicopters.org> Content-Type: text/plain; charset="us-ascii" Date: Sun, 01 Jun 2014 07:17:25 -0700 Message-ID: <1401632245.1113.8.camel@bruno> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: geom@freebsd.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jun 2014 14:17:32 -0000 On Sun, 2014-06-01 at 09:41 -0400, Michael W. Lucas wrote: > Hi, > > I'm trying to track down the documentation for the /dev/diskid/blah > device nodes. Is there a man page? > > It appears that this is a current-only thing, so I'm asking here? (At > least, none of my 9.x or 10.x machines have /dev/diskid.) > > Thanks, > ==ml > > > I'm afraid not. In this case sys/geom/label/g_label_disk_ident.c *is* the documentation. sean bcc current@ cc geom@ From owner-freebsd-geom@FreeBSD.ORG Mon Jun 2 02:58:13 2014 Return-Path: Delivered-To: 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 6D266E33; Mon, 2 Jun 2014 02:58:13 +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)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 49CD92D12; Mon, 2 Jun 2014 02:58:12 +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 s522wAGc011255 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Jun 2014 19:58:11 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s522wAq5011254; Sun, 1 Jun 2014 19:58:10 -0700 (PDT) (envelope-from jmg) Date: Sun, 1 Jun 2014 19:58:10 -0700 From: John-Mark Gurney To: sbruno@freebsd.org Subject: Re: diskid documentation Message-ID: <20140602025810.GW43976@funkthat.com> Mail-Followup-To: sbruno@freebsd.org, "Michael W. Lucas" , geom@freebsd.org, ivoras@FreeBSD.org References: <20140601134147.GA99583@bewilderbeast.blackhelicopters.org> <1401632245.1113.8.camel@bruno> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1401632245.1113.8.camel@bruno> 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-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sun, 01 Jun 2014 19:58:11 -0700 (PDT) Cc: geom@freebsd.org, ivoras@freebsd.org, "Michael W. Lucas" X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 02:58:13 -0000 Sean Bruno wrote this message on Sun, Jun 01, 2014 at 07:17 -0700: > On Sun, 2014-06-01 at 09:41 -0400, Michael W. Lucas wrote: > > I'm trying to track down the documentation for the /dev/diskid/blah > > device nodes. Is there a man page? > > > > It appears that this is a current-only thing, so I'm asking here? (At > > least, none of my 9.x or 10.x machines have /dev/diskid.) > > I'm afraid not. In this case sys/geom/label/g_label_disk_ident.c *is* > the documentation. Doesn't mean it shouldn't be... Ivan, Please update the glabel man page to document the diskid feature that you added. Thanks. -- 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 Mon Jun 2 13:26:10 2014 Return-Path: Delivered-To: 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 D24EBF42; Mon, 2 Jun 2014 13:26:10 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id B019024A0; Mon, 2 Jun 2014 13:26:09 +0000 (UTC) Received: from [192.168.1.70] (d206-75-77-44.abhsia.telus.net [206.75.77.44]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id E414B7CCD1; Mon, 2 Jun 2014 13:26:08 +0000 (UTC) Message-ID: <538C7B71.20109@freebsd.org> Date: Mon, 02 Jun 2014 09:26:09 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: diskid documentation References: <20140601134147.GA99583@bewilderbeast.blackhelicopters.org> In-Reply-To: <20140601134147.GA99583@bewilderbeast.blackhelicopters.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: geom@freebsd.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 13:26:10 -0000 On 2014-06-01 09:41, Michael W. Lucas wrote: > Hi, > > I'm trying to track down the documentation for the /dev/diskid/blah > device nodes. Is there a man page? > > It appears that this is a current-only thing, so I'm asking here? (At > least, none of my 9.x or 10.x machines have /dev/diskid.) > > Thanks, > ==ml > > > diskid (also called disk_ident in sysctl, which is confusing) It also tends to sometimes hide the gpt label provider on me (not sure in which cases it does this, but it is annoying) I usually disable it, especially to make my 'zpool status' output prettier kern.geom.label.disk_ident.enable=0 kern.geom.label.gptid.enable=0 -- Allan Jude From owner-freebsd-geom@FreeBSD.ORG Mon Jun 2 14:45:54 2014 Return-Path: Delivered-To: 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 559111CA; Mon, 2 Jun 2014 14:45:54 +0000 (UTC) Received: from mail-oa0-x235.google.com (mail-oa0-x235.google.com [IPv6:2607:f8b0:4003:c02::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 07FC22DF2; Mon, 2 Jun 2014 14:45:53 +0000 (UTC) Received: by mail-oa0-f53.google.com with SMTP id m1so4730835oag.40 for ; Mon, 02 Jun 2014 07:45:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZlVQoCnHbdKrHeHRhOjVJvHJjHpqWQPJC2SuYARWt68=; b=Y6dY7ta4xUWWP9cLLJJ9ZmvOVYanHo16WecB63RxF8SFC5mfe3UletHxMLJRH2ZKmQ lk9cTIAb5l/dAJQ2wrLLVTQ0S+g7eUHtp0BR5YrhBotXY3NXTlRQ96si4EbAsw/6Rl4b QvSIvkBd4kOQv8I+raL0uwaZVTV+lOy8Dr9j6coVhyq8aGyn56yiA8utdaQhHsSR3puj 95Be1obLMRJYPxl6BOScLOk/YV7HEE6K9UhxAXZf7vsi+5pSKtLureaM/Db3FjbxOjOw H2toRHvLQEzrlPBD5PJ9tOo3e2M1Z75crcN1RLW4OD0Cam72Kc56xT8X0cpCjCGlrrvT ndMQ== MIME-Version: 1.0 X-Received: by 10.60.179.138 with SMTP id dg10mr38657666oec.13.1401720353030; Mon, 02 Jun 2014 07:45:53 -0700 (PDT) Received: by 10.76.23.130 with HTTP; Mon, 2 Jun 2014 07:45:52 -0700 (PDT) In-Reply-To: <538C7B71.20109@freebsd.org> References: <20140601134147.GA99583@bewilderbeast.blackhelicopters.org> <538C7B71.20109@freebsd.org> Date: Mon, 2 Jun 2014 10:45:52 -0400 Message-ID: Subject: Re: diskid documentation From: Ryan Stone To: Allan Jude Content-Type: text/plain; charset=UTF-8 Cc: geom@freebsd.org, FreeBSD Current X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 14:45:54 -0000 On Mon, Jun 2, 2014 at 9:26 AM, Allan Jude wrote: > It also tends to sometimes hide the gpt label provider on me (not sure > in which cases it does this, but it is annoying) This happens when something (e.g. zfs) happens to open the diskid provider instead of the gpt label. For me this ended up being a bit more than annoying; my swap was mounted in /etc/fstab via a gpt label so I silently lost my swap when I did an upgrade. From owner-freebsd-geom@FreeBSD.ORG Mon Jun 2 15:07:04 2014 Return-Path: Delivered-To: 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 EFAD8D1F; Mon, 2 Jun 2014 15:07:04 +0000 (UTC) Received: from mail-ve0-x22c.google.com (mail-ve0-x22c.google.com [IPv6:2607:f8b0:400c:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8D6CB2079; Mon, 2 Jun 2014 15:07:04 +0000 (UTC) Received: by mail-ve0-f172.google.com with SMTP id oz11so5405118veb.3 for ; Mon, 02 Jun 2014 08:07:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=dFK5Aad+WpGXrZOJ/1hAlLfw16D1jCuUjZNt7kg4h5Q=; b=krZ2PlQv8OMx7TGVup8zMszz5SCHn3gwJz30mBCtZ1uZUtfiy1w/5htBsPA1b/BowS y9SZfC/C/1cR8/2Xx09TKMS3m66sbei70KS6d7PYetwPYbt4HgIdV46QQXfjmx8Mlo5D lYkv8MzVXGiXvVK3cuB2yk4/BuSXsseYsTdxr3mE2oCo2NhJhWkboIRat5uo21rFyRJg bXmayK4lqGOLQIxTWHCeCyqT25mS3xbx8WkuRTuAIONcTCwWv2tyISZfZNI4fbxnd3TF NoZ7NVa5uSftnXTeapLaM1iHeGOFZVwWdYdOOsFXBlZ55T3aysySSQDEA1WJEu4uEbyV qrkA== X-Received: by 10.58.209.233 with SMTP id mp9mr4236162vec.30.1401721623533; Mon, 02 Jun 2014 08:07:03 -0700 (PDT) MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.58.24.72 with HTTP; Mon, 2 Jun 2014 08:06:23 -0700 (PDT) In-Reply-To: <20140602025810.GW43976@funkthat.com> References: <20140601134147.GA99583@bewilderbeast.blackhelicopters.org> <1401632245.1113.8.camel@bruno> <20140602025810.GW43976@funkthat.com> From: Ivan Voras Date: Mon, 2 Jun 2014 17:06:23 +0200 X-Google-Sender-Auth: hFpsRaGT90sb-38HJgNsm9Mb73w Message-ID: Subject: Re: diskid documentation To: Sean Bruno , "Michael W. Lucas" , geom@freebsd.org, Ivan Voras Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 15:07:05 -0000 Thanks for the reminder! I've added diskid and even more documentation in http://svnweb.freebsd.org/changeset/base/266972 On 2 June 2014 04:58, John-Mark Gurney wrote: > Sean Bruno wrote this message on Sun, Jun 01, 2014 at 07:17 -0700: >> On Sun, 2014-06-01 at 09:41 -0400, Michael W. Lucas wrote: >> > I'm trying to track down the documentation for the /dev/diskid/blah >> > device nodes. Is there a man page? >> > >> > It appears that this is a current-only thing, so I'm asking here? (At >> > least, none of my 9.x or 10.x machines have /dev/diskid.) >> >> I'm afraid not. In this case sys/geom/label/g_label_disk_ident.c *is* >> the documentation. > > Doesn't mean it shouldn't be... > > Ivan, > > Please update the glabel man page to document the diskid feature that > you added. > > Thanks. > > -- > 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 Mon Jun 2 15:37:02 2014 Return-Path: Delivered-To: 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 C862AA3B; Mon, 2 Jun 2014 15:37:02 +0000 (UTC) Received: from bewilderbeast.blackhelicopters.org (mwlucas-2-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:b9c::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 88C862383; Mon, 2 Jun 2014 15:37:02 +0000 (UTC) Received: from bewilderbeast.blackhelicopters.org (localhost [127.0.0.1]) by bewilderbeast.blackhelicopters.org (8.14.7/8.14.7) with ESMTP id s52FapL6004151; Mon, 2 Jun 2014 11:37:01 -0400 (EDT) (envelope-from mwlucas@bewilderbeast.blackhelicopters.org) Received: (from mwlucas@localhost) by bewilderbeast.blackhelicopters.org (8.14.7/8.14.7/Submit) id s52Fap0h004150; Mon, 2 Jun 2014 11:36:51 -0400 (EDT) (envelope-from mwlucas) Date: Mon, 2 Jun 2014 11:36:51 -0400 From: "Michael W. Lucas" To: Ryan Stone Subject: Re: diskid documentation Message-ID: <20140602153651.GB4116@bewilderbeast.blackhelicopters.org> References: <20140601134147.GA99583@bewilderbeast.blackhelicopters.org> <538C7B71.20109@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.22 (2013-10-16) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (bewilderbeast.blackhelicopters.org [127.0.0.1]); Mon, 02 Jun 2014 11:37:01 -0400 (EDT) Cc: geom@freebsd.org, FreeBSD Current , Allan Jude X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 15:37:02 -0000 On Mon, Jun 02, 2014 at 10:45:52AM -0400, Ryan Stone wrote: > On Mon, Jun 2, 2014 at 9:26 AM, Allan Jude wrote: > > It also tends to sometimes hide the gpt label provider on me (not sure > > in which cases it does this, but it is annoying) > > This happens when something (e.g. zfs) happens to open the diskid > provider instead of the gpt label. For me this ended up being a bit > more than annoying; my swap was mounted in /etc/fstab via a gpt label > so I silently lost my swap when I did an upgrade. Wait-- one type of one label can hide another? I thought a big point of labels was to remove ambiguity... ==ml -- Michael W. Lucas - mwlucas@michaelwlucas.com, Twitter @mwlauthor http://www.MichaelWLucas.com/, http://blather.MichaelWLucas.com/ From owner-freebsd-geom@FreeBSD.ORG Mon Jun 2 15:47:46 2014 Return-Path: Delivered-To: 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 13EF1E28; Mon, 2 Jun 2014 15:47:46 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wonkity.com", Issuer "wonkity.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B61C12471; Mon, 2 Jun 2014 15:47:45 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.8/8.14.8) with ESMTP id s52Flhlu009463 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 2 Jun 2014 09:47:44 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.8/8.14.8/Submit) with ESMTP id s52FlhEQ009460; Mon, 2 Jun 2014 09:47:43 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Mon, 2 Jun 2014 09:47:43 -0600 (MDT) From: Warren Block To: "Michael W. Lucas" Subject: Re: diskid documentation In-Reply-To: <20140602153651.GB4116@bewilderbeast.blackhelicopters.org> Message-ID: References: <20140601134147.GA99583@bewilderbeast.blackhelicopters.org> <538C7B71.20109@freebsd.org> <20140602153651.GB4116@bewilderbeast.blackhelicopters.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Mon, 02 Jun 2014 09:47:44 -0600 (MDT) Cc: geom@freebsd.org, FreeBSD Current , Ryan Stone , Allan Jude X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 15:47:46 -0000 On Mon, 2 Jun 2014, Michael W. Lucas wrote: > On Mon, Jun 02, 2014 at 10:45:52AM -0400, Ryan Stone wrote: >> On Mon, Jun 2, 2014 at 9:26 AM, Allan Jude wrote: >>> It also tends to sometimes hide the gpt label provider on me (not sure >>> in which cases it does this, but it is annoying) >> >> This happens when something (e.g. zfs) happens to open the diskid >> provider instead of the gpt label. For me this ended up being a bit >> more than annoying; my swap was mounted in /etc/fstab via a gpt label >> so I silently lost my swap when I did an upgrade. > > Wait-- one type of one label can hide another? > > I thought a big point of labels was to remove ambiguity... Can't get more unambiguous than only having one label! The word to look for here is "wither". When a device label name is opened exclusively (like mounting a device), other labels for that device are supposed to "wither" and disappear from view. (My understanding of this is incomplete. Garrett Wollman sent me a very nice explanation of how this works, which I have read but not enough times yet.) From owner-freebsd-geom@FreeBSD.ORG Mon Jun 2 18:01:17 2014 Return-Path: Delivered-To: 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 E1EBA67F; Mon, 2 Jun 2014 18:01:17 +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)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A1D20231B; Mon, 2 Jun 2014 18:01:17 +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 s52I18YO023225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Jun 2014 11:01:09 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s52I183H023224; Mon, 2 Jun 2014 11:01:08 -0700 (PDT) (envelope-from jmg) Date: Mon, 2 Jun 2014 11:01:08 -0700 From: John-Mark Gurney To: "Michael W. Lucas" Subject: Re: diskid documentation Message-ID: <20140602180108.GX43976@funkthat.com> Mail-Followup-To: "Michael W. Lucas" , Ryan Stone , geom@freebsd.org, FreeBSD Current , Allan Jude References: <20140601134147.GA99583@bewilderbeast.blackhelicopters.org> <538C7B71.20109@freebsd.org> <20140602153651.GB4116@bewilderbeast.blackhelicopters.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140602153651.GB4116@bewilderbeast.blackhelicopters.org> 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-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Mon, 02 Jun 2014 11:01:09 -0700 (PDT) Cc: geom@freebsd.org, FreeBSD Current , Ryan Stone , Allan Jude X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 18:01:18 -0000 Michael W. Lucas wrote this message on Mon, Jun 02, 2014 at 11:36 -0400: > On Mon, Jun 02, 2014 at 10:45:52AM -0400, Ryan Stone wrote: > > On Mon, Jun 2, 2014 at 9:26 AM, Allan Jude wrote: > > > It also tends to sometimes hide the gpt label provider on me (not sure > > > in which cases it does this, but it is annoying) > > > > This happens when something (e.g. zfs) happens to open the diskid > > provider instead of the gpt label. For me this ended up being a bit > > more than annoying; my swap was mounted in /etc/fstab via a gpt label > > so I silently lost my swap when I did an upgrade. > > Wait-- one type of one label can hide another? > > I thought a big point of labels was to remove ambiguity... Surprisingly, yes... I didn't think about this, but it's true... A disk will get exported via two different devices, diskid and normal da/ada... The tasting will go through and create all the necessary sub devices, but the problem is that we now have two different paths, and if something opens the diskid path, then the da/ada paths all disappear... This sounds like we need to fix geom to "bind" the two together so that when one opens, the other doesn't disappear... The problem is that geom views them as two separate disks when in fact they are the same... someone who knows geom well should think about how to solve this problem, as diskid isn't the first time this has happened, just most prevalent w/ ZFS and diskid. -- 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 Mon Jun 2 20:23:30 2014 Return-Path: Delivered-To: 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 F3BD5337; Mon, 2 Jun 2014 20:23:29 +0000 (UTC) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id B6D8020C8; Mon, 2 Jun 2014 20:23:28 +0000 (UTC) Received: from localhost (89-78-109-105.dynamic.chello.pl [89.78.109.105]) by mail.dawidek.net (Postfix) with ESMTPSA id C4B841C5; Mon, 2 Jun 2014 22:23:20 +0200 (CEST) Date: Mon, 2 Jun 2014 22:26:39 +0200 From: Pawel Jakub Dawidek To: jmg@FreeBSD.org Subject: Re: diskid documentation Message-ID: <20140602202639.GA1668@garage.freebsd.pl> References: <20140601134147.GA99583@bewilderbeast.blackhelicopters.org> <538C7B71.20109@freebsd.org> <20140602153651.GB4116@bewilderbeast.blackhelicopters.org> <20140602180108.GX43976@funkthat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="M9NhX3UHpAaciwkO" Content-Disposition: inline In-Reply-To: <20140602180108.GX43976@funkthat.com> X-OS: FreeBSD 11.0-CURRENT amd64 User-Agent: Mutt/1.5.22 (2013-10-16) Cc: geom@freebsd.org, FreeBSD Current , Ryan Stone , Allan Jude , "Michael W. Lucas" X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 20:23:30 -0000 --M9NhX3UHpAaciwkO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 02, 2014 at 11:01:08AM -0700, John-Mark Gurney wrote: > Michael W. Lucas wrote this message on Mon, Jun 02, 2014 at 11:36 -0400: > > On Mon, Jun 02, 2014 at 10:45:52AM -0400, Ryan Stone wrote: > > > On Mon, Jun 2, 2014 at 9:26 AM, Allan Jude wr= ote: > > > > It also tends to sometimes hide the gpt label provider on me (not s= ure > > > > in which cases it does this, but it is annoying) > > >=20 > > > This happens when something (e.g. zfs) happens to open the diskid > > > provider instead of the gpt label. For me this ended up being a bit > > > more than annoying; my swap was mounted in /etc/fstab via a gpt label > > > so I silently lost my swap when I did an upgrade. > >=20 > > Wait-- one type of one label can hide another? > >=20 > > I thought a big point of labels was to remove ambiguity... >=20 > Surprisingly, yes... I didn't think about this, but it's true... >=20 > A disk will get exported via two different devices, diskid and normal > da/ada... The tasting will go through and create all the necessary > sub devices, but the problem is that we now have two different paths, > and if something opens the diskid path, then the da/ada paths all > disappear... >=20 > This sounds like we need to fix geom to "bind" the two together so > that when one opens, the other doesn't disappear... The problem is > that geom views them as two separate disks when in fact they are the > same... someone who knows geom well should think about how to solve > this problem, as diskid isn't the first time this has happened, just > most prevalent w/ ZFS and diskid. The problem is that GPT labels (or GPT IDs for that matter) should not be implemented within GLABEL. This is wrong. It should be implemented as part of GPART, so that GPART would create ada0p1, gpt/label and gptid/whatever. Opening one of those should not make the others disappear then. Only opening ada0 for writting would make them disappear. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com --M9NhX3UHpAaciwkO Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iEYEARECAAYFAlOM3f8ACgkQForvXbEpPzRXRQCfbsUELlDNxBWilZ/z3MZqXA4K oaUAnjBo1EEECt0LuBmoa2UeVVBt3GKr =mi4Q -----END PGP SIGNATURE----- --M9NhX3UHpAaciwkO-- From owner-freebsd-geom@FreeBSD.ORG Mon Jun 2 20:32:21 2014 Return-Path: Delivered-To: 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 2FB0E861; Mon, 2 Jun 2014 20:32:21 +0000 (UTC) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 130D621AD; Mon, 2 Jun 2014 20:32:20 +0000 (UTC) Received: from zeppelin.tachypleus.net (airbears2-136-152-142-17.AirBears2.Berkeley.EDU [136.152.142.17]) (authenticated bits=0) by d.mail.sonic.net (8.14.4/8.14.4) with ESMTP id s52KWEJg026752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 2 Jun 2014 13:32:14 -0700 Message-ID: <538CDF4E.8050703@freebsd.org> Date: Mon, 02 Jun 2014 13:32:14 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Pawel Jakub Dawidek , jmg@freebsd.org Subject: Re: diskid documentation References: <20140601134147.GA99583@bewilderbeast.blackhelicopters.org> <538C7B71.20109@freebsd.org> <20140602153651.GB4116@bewilderbeast.blackhelicopters.org> <20140602180108.GX43976@funkthat.com> <20140602202639.GA1668@garage.freebsd.pl> In-Reply-To: <20140602202639.GA1668@garage.freebsd.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;6Oxl+5Tq4xGQE8UoeQW9yA== M;QmOQ+5Tq4xGQE8UoeQW9yA== Cc: geom@freebsd.org, FreeBSD Current , Ryan Stone , "Michael W. Lucas" , Allan Jude X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 20:32:21 -0000 On 06/02/14 13:26, Pawel Jakub Dawidek wrote: > On Mon, Jun 02, 2014 at 11:01:08AM -0700, John-Mark Gurney wrote: >> Michael W. Lucas wrote this message on Mon, Jun 02, 2014 at 11:36 -0400: >>> On Mon, Jun 02, 2014 at 10:45:52AM -0400, Ryan Stone wrote: >>>> On Mon, Jun 2, 2014 at 9:26 AM, Allan Jude wrote: >>>>> It also tends to sometimes hide the gpt label provider on me (not sure >>>>> in which cases it does this, but it is annoying) >>>> This happens when something (e.g. zfs) happens to open the diskid >>>> provider instead of the gpt label. For me this ended up being a bit >>>> more than annoying; my swap was mounted in /etc/fstab via a gpt label >>>> so I silently lost my swap when I did an upgrade. >>> Wait-- one type of one label can hide another? >>> >>> I thought a big point of labels was to remove ambiguity... >> Surprisingly, yes... I didn't think about this, but it's true... >> >> A disk will get exported via two different devices, diskid and normal >> da/ada... The tasting will go through and create all the necessary >> sub devices, but the problem is that we now have two different paths, >> and if something opens the diskid path, then the da/ada paths all >> disappear... >> >> This sounds like we need to fix geom to "bind" the two together so >> that when one opens, the other doesn't disappear... The problem is >> that geom views them as two separate disks when in fact they are the >> same... someone who knows geom well should think about how to solve >> this problem, as diskid isn't the first time this has happened, just >> most prevalent w/ ZFS and diskid. > The problem is that GPT labels (or GPT IDs for that matter) should not > be implemented within GLABEL. This is wrong. It should be implemented as > part of GPART, so that GPART would create ada0p1, gpt/label and > gptid/whatever. Opening one of those should not make the others > disappear then. Only opening ada0 for writting would make them disappear. > Indeed. This would also fix some tasting races, allow programmatic retrieval of the label device from gpart, and expand label device support from GPT to all partition schemes supported by gpart (APM, for instance). -Nathan From owner-freebsd-geom@FreeBSD.ORG Mon Jun 2 22:27:07 2014 Return-Path: Delivered-To: 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 C346790A; Mon, 2 Jun 2014 22:27: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)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 986102B79; Mon, 2 Jun 2014 22:27: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 s52MR6eR026764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Jun 2014 15:27:06 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s52MR6hL026763; Mon, 2 Jun 2014 15:27:06 -0700 (PDT) (envelope-from jmg) Date: Mon, 2 Jun 2014 15:27:06 -0700 From: John-Mark Gurney To: Pawel Jakub Dawidek Subject: Re: diskid documentation Message-ID: <20140602222706.GA43976@funkthat.com> Mail-Followup-To: Pawel Jakub Dawidek , geom@freebsd.org, FreeBSD Current , Ryan Stone , Allan Jude , "Michael W. Lucas" References: <20140601134147.GA99583@bewilderbeast.blackhelicopters.org> <538C7B71.20109@freebsd.org> <20140602153651.GB4116@bewilderbeast.blackhelicopters.org> <20140602180108.GX43976@funkthat.com> <20140602202639.GA1668@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140602202639.GA1668@garage.freebsd.pl> 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-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Mon, 02 Jun 2014 15:27:07 -0700 (PDT) Cc: geom@freebsd.org, FreeBSD Current , Ryan Stone , "Michael W. Lucas" , Allan Jude X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 22:27:08 -0000 Pawel Jakub Dawidek wrote this message on Mon, Jun 02, 2014 at 22:26 +0200: > On Mon, Jun 02, 2014 at 11:01:08AM -0700, John-Mark Gurney wrote: > > Michael W. Lucas wrote this message on Mon, Jun 02, 2014 at 11:36 -0400: > > > On Mon, Jun 02, 2014 at 10:45:52AM -0400, Ryan Stone wrote: > > > > On Mon, Jun 2, 2014 at 9:26 AM, Allan Jude wrote: > > > > > It also tends to sometimes hide the gpt label provider on me (not sure > > > > > in which cases it does this, but it is annoying) > > > > > > > > This happens when something (e.g. zfs) happens to open the diskid > > > > provider instead of the gpt label. For me this ended up being a bit > > > > more than annoying; my swap was mounted in /etc/fstab via a gpt label > > > > so I silently lost my swap when I did an upgrade. > > > > > > Wait-- one type of one label can hide another? > > > > > > I thought a big point of labels was to remove ambiguity... > > > > Surprisingly, yes... I didn't think about this, but it's true... > > > > A disk will get exported via two different devices, diskid and normal > > da/ada... The tasting will go through and create all the necessary > > sub devices, but the problem is that we now have two different paths, > > and if something opens the diskid path, then the da/ada paths all > > disappear... > > > > This sounds like we need to fix geom to "bind" the two together so > > that when one opens, the other doesn't disappear... The problem is > > that geom views them as two separate disks when in fact they are the > > same... someone who knows geom well should think about how to solve > > this problem, as diskid isn't the first time this has happened, just > > most prevalent w/ ZFS and diskid. > > The problem is that GPT labels (or GPT IDs for that matter) should not > be implemented within GLABEL. This is wrong. It should be implemented as > part of GPART, so that GPART would create ada0p1, gpt/label and > gptid/whatever. Opening one of those should not make the others > disappear then. Only opening ada0 for writting would make them disappear. even gpart would be wrong IMO... What happens if there is another provider like GPART, but different, do they need to implement diskid creation too to prevent the same issue? Shouldn't geom be updated to say, this ident is an alias, everything you do w/ this, it's exactly the same as the other one? This would also have the advantage of possibly removing one layer in the call chain when dealing w/ IO. (or does GEOM has a pass-through flag that says, I don't do anything, just skip me?) -- 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 Tue Jun 3 09:56:22 2014 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 8E0E1384 for ; Tue, 3 Jun 2014 09:56:22 +0000 (UTC) Received: from design24.letzebuerg.net (design24.letzebuerg.net [144.76.164.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DCFB256C for ; Tue, 3 Jun 2014 09:56:22 +0000 (UTC) Received: from [88.207.186.31] (port=42920 helo=[192.168.0.32]) by design24.letzebuerg.net with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WrlS6-0000zw-Vz for freebsd-geom@freebsd.org; Tue, 03 Jun 2014 11:56:19 +0200 Message-ID: <538D9BC3.6040509@metrico.lu> Date: Tue, 03 Jun 2014 11:56:19 +0200 From: Frank Broniewski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-geom@freebsd.org Subject: Geom stripe bottleneck X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - design24.letzebuerg.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - metrico.lu X-Get-Message-Sender-Via: design24.letzebuerg.net: authenticated_id: brfr@metrico.lu X-Source: X-Source-Args: X-Source-Dir: X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 09:56:22 -0000 Hi all, I have a stripe (RAID0) geom setup for my database's data. Currently I am applying some large updates on the data and I think the performance of my stripe could be better. But I am uncertain and so I thought I'd request some interpretation help from the community :) The stripe consists of two disks (WD Velociraptor with 10.000 rpm): >diskinfo -v ada2 ada2 512 # sectorsize 600127266816 # mediasize in bytes (558G) 1172123568 # mediasize in sectors 0 # stripesize 0 # stripeoffset 1162821 # Cylinders according to firmware. 16 # Heads according to firmware. 63 # Sectors according to firmware. WD-WXH1E61ASNX9 # Disk ident. and /var/log/dmesg.boot # snip ada2 at ahcich2 bus 0 scbus2 target 0 lun 0 ada2: ATA-8 SATA 3.x device ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada2: Command Queueing enabled ada2: 572325MB (1172123568 512 byte sectors: 16H 63S/T 16383C) ada2: Previously was known as ad8 ada3 at ahcich3 bus 0 scbus3 target 0 lun 0 ada3: ATA-8 SATA 3.x device ada3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada3: Command Queueing enabled ada3: 572325MB (1172123568 512 byte sectors: 16H 63S/T 16383C) ada3: Previously was known as ad10 #snap And here's some iostat -d -w 10 ada0 ada1 ada2 ada3 example output #snip ada0 ada1 ada2 ada3 KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s 0.00 0 0.00 0.00 0 0.00 19.33 176 3.32 19.33 176 3.32 16.25 0 0.01 16.25 0 0.01 16.87 133 2.20 16.87 133 2.20 0.00 0 0.00 0.00 0 0.00 16.77 146 2.40 16.77 147 2.40 0.00 0 0.00 0.00 0 0.00 19.46 170 3.24 19.45 170 3.23 21.50 0 0.01 21.50 0 0.01 17.00 125 2.08 17.00 125 2.08 0.50 0 0.00 0.50 0 0.00 16.88 145 2.38 16.88 145 2.38 0.00 0 0.00 0.00 0 0.00 16.96 125 2.07 16.97 125 2.07 0.00 0 0.00 0.00 0 0.00 19.82 158 3.06 19.81 158 3.07 28.77 1 0.03 28.77 1 0.03 16.83 133 2.19 16.82 133 2.19 #snap I think the MB/s output is rather low for such a disk. To gain further insight I started gstat: dT: 1.001s w: 1.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name 0 27 0 0 0.0 27 2226 4.8 7.0| ada0 0 28 1 32 23.9 27 2226 1.3 3.9| ada1 2 120 115 1838 6.4 5 96 0.2 74.3| ada2 2 121 116 1854 6.3 5 96 0.4 72.9| ada3 0 28 1 32 24.0 27 2226 5.0 8.7| mirror/gm 2 121 116 3708 7.9 5 192 0.4 92.2| stripe/gs 0 28 1 32 24.0 27 2226 5.0 8.7| mirror/gms1 0 12 0 0 0.0 12 1343 9.1 6.9| mirror/gms1a 0 0 0 0 0.0 0 0 0.0 0.0| mirror/gms1b 0 0 0 0 0.0 0 0 0.0 0.0| mirror/gms1d 0 0 0 0 0.0 0 0 0.0 0.0| mirror/gms1e 0 16 1 32 24.0 15 883 1.7 2.9| mirror/gms1f What bothers me here is that the stripe/gs is 92% busy while the disks themselves are only at 74/72%. This lead me to my post here and seek some advice, since I don't know enough about the mechanics and so I can't really find the problem, if there is any at all. Btw, here's the output from geom stripe list: # geom stripe list Geom name: gs State: UP Status: Total=2, Online=2 Type: AUTOMATIC Stripesize: 8192 ID: 1042782665 Providers: 1. Name: stripe/gs Mediasize: 1200254517248 (1.1T) Sectorsize: 512 Stripesize: 8192 Stripeoffset: 0 Mode: r1w1e1 Consumers: 1. Name: ada2 Mediasize: 600127266816 (558G) Sectorsize: 512 Mode: r1w1e2 Number: 0 2. Name: ada3 Mediasize: 600127266816 (558G) Sectorsize: 512 Mode: r1w1e2 Number: 1 So is there some bottleneck or I am just worrying about nothing? Many thanks, Frank -- Frank BRONIEWSKI METRICO s.à r.l. géomètres technologies d'information géographique rue des Romains 36 L-5433 NIEDERDONVEN tél.: +352 26 74 94 - 28 fax.: +352 26 74 94 99 http://www.metrico.lu From owner-freebsd-geom@FreeBSD.ORG Tue Jun 3 20:48:16 2014 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 1918FED5 for ; Tue, 3 Jun 2014 20:48:16 +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)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E60B0290A for ; Tue, 3 Jun 2014 20:48:15 +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 s53KmDTW045637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jun 2014 13:48:13 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s53KmB6u045636; Tue, 3 Jun 2014 13:48:11 -0700 (PDT) (envelope-from jmg) Date: Tue, 3 Jun 2014 13:48:11 -0700 From: John-Mark Gurney To: Frank Broniewski Subject: Re: Geom stripe bottleneck Message-ID: <20140603204811.GJ31367@funkthat.com> Mail-Followup-To: Frank Broniewski , freebsd-geom@freebsd.org References: <538D9BC3.6040509@metrico.lu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <538D9BC3.6040509@metrico.lu> 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-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Tue, 03 Jun 2014 13:48:13 -0700 (PDT) Cc: freebsd-geom@freebsd.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 20:48:16 -0000 Frank Broniewski wrote this message on Tue, Jun 03, 2014 at 11:56 +0200: > I have a stripe (RAID0) geom setup for my database's data. Currently I > am applying some large updates on the data and I think the performance > of my stripe could be better. But I am uncertain and so I thought I'd > request some interpretation help from the community :) > > The stripe consists of two disks (WD Velociraptor with 10.000 rpm): > >diskinfo -v ada2 > ada2 > 512 # sectorsize > 600127266816 # mediasize in bytes (558G) > 1172123568 # mediasize in sectors > 0 # stripesize > 0 # stripeoffset > 1162821 # Cylinders according to firmware. > > 16 # Heads according to firmware. > > 63 # Sectors according to firmware. > > WD-WXH1E61ASNX9 # Disk ident. > > > and /var/log/dmesg.boot > # snip > ada2 at ahcich2 bus 0 scbus2 target 0 lun 0 > ada2: ATA-8 SATA 3.x device > ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > ada2: Command Queueing enabled > ada2: 572325MB (1172123568 512 byte sectors: 16H 63S/T 16383C) > ada2: Previously was known as ad8 > ada3 at ahcich3 bus 0 scbus3 target 0 lun 0 > ada3: ATA-8 SATA 3.x device > ada3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > ada3: Command Queueing enabled > ada3: 572325MB (1172123568 512 byte sectors: 16H 63S/T 16383C) > ada3: Previously was known as ad10 > #snap > > > And here's some iostat -d -w 10 ada0 ada1 ada2 ada3 example output > #snip > ada0 ada1 ada2 ada3 > KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s > 0.00 0 0.00 0.00 0 0.00 19.33 176 3.32 19.33 176 3.32 > 16.25 0 0.01 16.25 0 0.01 16.87 133 2.20 16.87 133 2.20 > 0.00 0 0.00 0.00 0 0.00 16.77 146 2.40 16.77 147 2.40 > 0.00 0 0.00 0.00 0 0.00 19.46 170 3.24 19.45 170 3.23 > 21.50 0 0.01 21.50 0 0.01 17.00 125 2.08 17.00 125 2.08 > 0.50 0 0.00 0.50 0 0.00 16.88 145 2.38 16.88 145 2.38 > 0.00 0 0.00 0.00 0 0.00 16.96 125 2.07 16.97 125 2.07 > 0.00 0 0.00 0.00 0 0.00 19.82 158 3.06 19.81 158 3.07 > 28.77 1 0.03 28.77 1 0.03 16.83 133 2.19 16.82 133 2.19 > #snap The key here is the tps... Spining drives have a limited number of tps... first you have moving the heads, which on average will be ~4ms, then you have to wait, on average half a rotation, which for a 10k RPM drive is ~3ms, so each seek will take around 7ms, so, as you can see, your best number is 176 TPS, or ~8ms/transaction... so, it looks like your drives are performing as they should... > I think the MB/s output is rather low for such a disk. To gain further > insight I started gstat: > dT: 1.001s w: 1.000s > L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name > 0 27 0 0 0.0 27 2226 4.8 7.0| ada0 > 0 28 1 32 23.9 27 2226 1.3 3.9| ada1 > 2 120 115 1838 6.4 5 96 0.2 74.3| ada2 > 2 121 116 1854 6.3 5 96 0.4 72.9| ada3 > 0 28 1 32 24.0 27 2226 5.0 8.7| mirror/gm > 2 121 116 3708 7.9 5 192 0.4 92.2| stripe/gs > 0 28 1 32 24.0 27 2226 5.0 8.7| mirror/gms1 > 0 12 0 0 0.0 12 1343 9.1 6.9| mirror/gms1a > 0 0 0 0 0.0 0 0 0.0 0.0| mirror/gms1b > 0 0 0 0 0.0 0 0 0.0 0.0| mirror/gms1d > 0 0 0 0 0.0 0 0 0.0 0.0| mirror/gms1e > 0 16 1 32 24.0 15 883 1.7 2.9| mirror/gms1f > > > What bothers me here is that the stripe/gs is 92% busy while the disks > themselves are only at 74/72%. This lead me to my post here and seek > some advice, since I don't know enough about the mechanics and so I > can't really find the problem, if there is any at all. This is because the stripe has to wait for both drives to return data before moving the data up... If you're just running a single threaded benchmark, there isn't multiple IO's in flight, and there for the remaining time is spent in your application before it sends another request down to the stripe... the different between stripe and the drives is the fact each of them is sometimes faster than the other, so again, won't have work to do until another IO is submitted... Try sending more IO at it, like doing 4 or more dd read's such that the between the latency of one IO, there is other IO to server... Also, make sure that you're using NCQ where the OS can submit multiple IO's to the drives at once, this should improve things, but won't change the results you see above as it requires multiple IO's outstanding... -- 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 Tue Jun 3 22:27:42 2014 Return-Path: Delivered-To: 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 AD9BC61F; Tue, 3 Jun 2014 22:27:42 +0000 (UTC) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id 6B27F2249; Tue, 3 Jun 2014 22:27:41 +0000 (UTC) Received: from localhost (89-78-109-105.dynamic.chello.pl [89.78.109.105]) by mail.dawidek.net (Postfix) with ESMTPSA id 7D5FF667; Wed, 4 Jun 2014 00:17:34 +0200 (CEST) Date: Wed, 4 Jun 2014 00:20:53 +0200 From: Pawel Jakub Dawidek To: geom@freebsd.org Subject: Re: diskid documentation Message-ID: <20140603222053.GA1673@garage.freebsd.pl> References: <20140601134147.GA99583@bewilderbeast.blackhelicopters.org> <538C7B71.20109@freebsd.org> <20140602153651.GB4116@bewilderbeast.blackhelicopters.org> <20140602180108.GX43976@funkthat.com> <20140602202639.GA1668@garage.freebsd.pl> <20140602222706.GA43976@funkthat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+QahgC5+KEYLbs62" Content-Disposition: inline In-Reply-To: <20140602222706.GA43976@funkthat.com> X-OS: FreeBSD 11.0-CURRENT amd64 User-Agent: Mutt/1.5.22 (2013-10-16) Cc: FreeBSD Current , Ryan Stone , "Michael W. Lucas" , Allan Jude X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 22:27:42 -0000 --+QahgC5+KEYLbs62 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 02, 2014 at 03:27:06PM -0700, John-Mark Gurney wrote: > Pawel Jakub Dawidek wrote this message on Mon, Jun 02, 2014 at 22:26 +020= 0: > > The problem is that GPT labels (or GPT IDs for that matter) should not > > be implemented within GLABEL. This is wrong. It should be implemented as > > part of GPART, so that GPART would create ada0p1, gpt/label and > > gptid/whatever. Opening one of those should not make the others > > disappear then. Only opening ada0 for writting would make them disappea= r. >=20 > even gpart would be wrong IMO... What happens if there is another > provider like GPART, but different, do they need to implement diskid > creation too to prevent the same issue? >=20 > Shouldn't geom be updated to say, this ident is an alias, everything > you do w/ this, it's exactly the same as the other one? This would > also have the advantage of possibly removing one layer in the call > chain when dealing w/ IO. (or does GEOM has a pass-through flag that > says, I don't do anything, just skip me?) As for disk IDs it definitely shouldn't be implemented in GPART or GLABEL. IMHO the right place is the DISK class - both ada0 and diskid-of-ada0 should exist on the same rights (two providers of one geom). This also would address your concern about additional layer. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com --+QahgC5+KEYLbs62 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iEYEARECAAYFAlOOSkUACgkQForvXbEpPzR3XwCgiwMgRoi6Sa+5RUjHfv1A2pWh 8UkAn2fzJmdbmuiI/K4mhck1s3xJLEgW =LBL6 -----END PGP SIGNATURE----- --+QahgC5+KEYLbs62-- From owner-freebsd-geom@FreeBSD.ORG Wed Jun 4 08:00:13 2014 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 39BAD1DE for ; Wed, 4 Jun 2014 08:00:13 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 25FEB2247 for ; Wed, 4 Jun 2014 08:00:13 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.8/8.14.8) with ESMTP id s5480Dck049322 for ; Wed, 4 Jun 2014 09:00:13 +0100 (BST) (envelope-from bz-noreply@freebsd.org) Message-Id: <201406040800.s5480Dck049322@kenobi.freebsd.org> From: bz-noreply@freebsd.org To: freebsd-geom@FreeBSD.org Subject: [Bugzilla] Commit Needs MFC MIME-Version: 1.0 X-Bugzilla-Type: whine X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated Date: Wed, 04 Jun 2014 08:00:13 +0000 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 08:00:13 -0000 Hi, You have a bug in the "Needs MFC" state which has not been touched in 7 days. This email serves as a reminder that you may want to MFC this bug or marked it as completed. In the event you have a longer MFC timeout you may update this bug with a comment and I won't remind you again for 7 days. This reminder is an experimental feature. Please file a bug or mail bugmeister@ with concerns. This search was scheduled by eadler@FreeBSD.org. (2 bugs) Bug 158398: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=158398 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-geom@FreeBSD.org Status: Needs MFC Resolution: Summary: [headers] [patch] includes gratuitously Bug 176744: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=176744 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-geom@FreeBSD.org Status: Needs MFC Resolution: Summary: [geom] [patch] BIO_FLUSH not recorded by devstats From owner-freebsd-geom@FreeBSD.ORG Wed Jun 4 08:38:47 2014 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 D7200DDC for ; Wed, 4 Jun 2014 08:38:47 +0000 (UTC) Received: from design24.letzebuerg.net (design24.letzebuerg.net [144.76.164.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 91AB12608 for ; Wed, 4 Jun 2014 08:38:46 +0000 (UTC) Received: from [88.207.159.192] (port=43519 helo=[192.168.0.32]) by design24.letzebuerg.net with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Ws6iU-0006Wo-7M for freebsd-geom@freebsd.org; Wed, 04 Jun 2014 10:38:38 +0200 Message-ID: <538EDB11.6090507@metrico.lu> Date: Wed, 04 Jun 2014 10:38:41 +0200 From: Frank Broniewski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-geom@freebsd.org Subject: Re: Geom stripe bottleneck References: <538D9BC3.6040509@metrico.lu> <20140603204811.GJ31367@funkthat.com> In-Reply-To: <20140603204811.GJ31367@funkthat.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - design24.letzebuerg.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - metrico.lu X-Get-Message-Sender-Via: design24.letzebuerg.net: authenticated_id: brfr@metrico.lu X-Source: X-Source-Args: X-Source-Dir: X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 08:38:47 -0000 Hey, thank you very much for your verbose and very helpful answer! I think that clears things out for me. I've got a question concerning NCQ though: # grep ahci /var/run/dmesg.boot ahci0: port 0xb000-0xb007,0xa000-0xa003,0x9000-0x9007,0x8000-0x8003,0x7000-0x700f mem 0xfaffe400-0xfaffe7ff irq 22 at device 17.0 on pci0 ahci0: AHCI v1.10 with 4 3Gbps ports, Port Multiplier supported ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich2: at channel 2 on ahci0 ahcich3: at channel 3 on ahci0 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 ada2 at ahcich2 bus 0 scbus2 target 0 lun 0 ada3 at ahcich3 bus 0 scbus3 target 0 lun 0 and: # camcontrol identify ada3 pass3: ATA-8 SATA 3.x device pass3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) protocol ATA/ATAPI-8 SATA 3.x device model WDC WD6000HLHX-01JJPV0 firmware revision 04.05G04 serial number WD-WXL1E61PWAL2 WWN 50014ee7aaab0118 cylinders 16383 heads 16 sectors/track 63 sector size logical 512, physical 512, offset 0 LBA supported 268435455 sectors LBA48 supported 1172123568 sectors PIO supported PIO4 DMA supported WDMA2 UDMA6 media RPM 10000 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 yes yes 128/0x80 automatic acoustic management no no media status notification no no power-up in Standby yes no write-read-verify no no unload yes yes free-fall no no Data Set Management (DSM/TRIM) no Host Protected Area (HPA) yes no 1172123568/1172123568 HPA - Security no is NCQ now enabled? The corresponding line in the camcontrol identify output doesn't tell me that explicitly but also doesn't deny that ... but the dmesg.boot may hint that the ahci module is loaded ... I'm confused :-) I do not have a ahci_load=YES in /boot/loader.conf (this is on FreeBSD 9.2-p6) and I don't know if that's still necessary or not. Searching the internet turned up mostly rather old (2010,2011) results. Am 2014-06-03 22:48, schrieb John-Mark Gurney: > Frank Broniewski wrote this message on Tue, Jun 03, 2014 at 11:56 +0200: >> I have a stripe (RAID0) geom setup for my database's data. Currently I >> am applying some large updates on the data and I think the performance >> of my stripe could be better. But I am uncertain and so I thought I'd >> request some interpretation help from the community :) >> >> The stripe consists of two disks (WD Velociraptor with 10.000 rpm): >>> diskinfo -v ada2 >> ada2 >> 512 # sectorsize >> 600127266816 # mediasize in bytes (558G) >> 1172123568 # mediasize in sectors >> 0 # stripesize >> 0 # stripeoffset >> 1162821 # Cylinders according to firmware. >> >> 16 # Heads according to firmware. >> >> 63 # Sectors according to firmware. >> >> WD-WXH1E61ASNX9 # Disk ident. >> >> >> and /var/log/dmesg.boot >> # snip >> ada2 at ahcich2 bus 0 scbus2 target 0 lun 0 >> ada2: ATA-8 SATA 3.x device >> ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) >> ada2: Command Queueing enabled >> ada2: 572325MB (1172123568 512 byte sectors: 16H 63S/T 16383C) >> ada2: Previously was known as ad8 >> ada3 at ahcich3 bus 0 scbus3 target 0 lun 0 >> ada3: ATA-8 SATA 3.x device >> ada3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) >> ada3: Command Queueing enabled >> ada3: 572325MB (1172123568 512 byte sectors: 16H 63S/T 16383C) >> ada3: Previously was known as ad10 >> #snap >> >> >> And here's some iostat -d -w 10 ada0 ada1 ada2 ada3 example output >> #snip >> ada0 ada1 ada2 ada3 >> KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s >> 0.00 0 0.00 0.00 0 0.00 19.33 176 3.32 19.33 176 3.32 >> 16.25 0 0.01 16.25 0 0.01 16.87 133 2.20 16.87 133 2.20 >> 0.00 0 0.00 0.00 0 0.00 16.77 146 2.40 16.77 147 2.40 >> 0.00 0 0.00 0.00 0 0.00 19.46 170 3.24 19.45 170 3.23 >> 21.50 0 0.01 21.50 0 0.01 17.00 125 2.08 17.00 125 2.08 >> 0.50 0 0.00 0.50 0 0.00 16.88 145 2.38 16.88 145 2.38 >> 0.00 0 0.00 0.00 0 0.00 16.96 125 2.07 16.97 125 2.07 >> 0.00 0 0.00 0.00 0 0.00 19.82 158 3.06 19.81 158 3.07 >> 28.77 1 0.03 28.77 1 0.03 16.83 133 2.19 16.82 133 2.19 >> #snap > > The key here is the tps... Spining drives have a limited number of > tps... first you have moving the heads, which on average will be ~4ms, > then you have to wait, on average half a rotation, which for a 10k RPM > drive is ~3ms, so each seek will take around 7ms, so, as you can see, > your best number is 176 TPS, or ~8ms/transaction... so, it looks like > your drives are performing as they should... > >> I think the MB/s output is rather low for such a disk. To gain further >> insight I started gstat: >> dT: 1.001s w: 1.000s >> L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name >> 0 27 0 0 0.0 27 2226 4.8 7.0| ada0 >> 0 28 1 32 23.9 27 2226 1.3 3.9| ada1 >> 2 120 115 1838 6.4 5 96 0.2 74.3| ada2 >> 2 121 116 1854 6.3 5 96 0.4 72.9| ada3 >> 0 28 1 32 24.0 27 2226 5.0 8.7| mirror/gm >> 2 121 116 3708 7.9 5 192 0.4 92.2| stripe/gs >> 0 28 1 32 24.0 27 2226 5.0 8.7| mirror/gms1 >> 0 12 0 0 0.0 12 1343 9.1 6.9| mirror/gms1a >> 0 0 0 0 0.0 0 0 0.0 0.0| mirror/gms1b >> 0 0 0 0 0.0 0 0 0.0 0.0| mirror/gms1d >> 0 0 0 0 0.0 0 0 0.0 0.0| mirror/gms1e >> 0 16 1 32 24.0 15 883 1.7 2.9| mirror/gms1f >> >> >> What bothers me here is that the stripe/gs is 92% busy while the disks >> themselves are only at 74/72%. This lead me to my post here and seek >> some advice, since I don't know enough about the mechanics and so I >> can't really find the problem, if there is any at all. > > This is because the stripe has to wait for both drives to return data > before moving the data up... If you're just running a single threaded > benchmark, there isn't multiple IO's in flight, and there for the > remaining time is spent in your application before it sends another > request down to the stripe... the different between stripe and the > drives is the fact each of them is sometimes faster than the other, > so again, won't have work to do until another IO is submitted... > > Try sending more IO at it, like doing 4 or more dd read's such that > the between the latency of one IO, there is other IO to server... > > Also, make sure that you're using NCQ where the OS can submit multiple > IO's to the drives at once, this should improve things, but won't > change the results you see above as it requires multiple IO's > outstanding... > -- Frank BRONIEWSKI METRICO s.à r.l. géomètres technologies d'information géographique rue des Romains 36 L-5433 NIEDERDONVEN tél.: +352 26 74 94 - 28 fax.: +352 26 74 94 99 http://www.metrico.lu From owner-freebsd-geom@FreeBSD.ORG Wed Jun 4 11:14:25 2014 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 3D131DC1 for ; Wed, 4 Jun 2014 11:14:25 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E8E8D2508 for ; Wed, 4 Jun 2014 11:14:24 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Ws995-0002qt-Io for freebsd-geom@freebsd.org; Wed, 04 Jun 2014 13:14:15 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 04 Jun 2014 13:14:15 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 04 Jun 2014 13:14:15 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-geom@freebsd.org From: Ivan Voras Subject: Re: Geom stripe bottleneck Date: Wed, 04 Jun 2014 13:14:02 +0200 Lines: 40 Message-ID: References: <538D9BC3.6040509@metrico.lu> <20140603204811.GJ31367@funkthat.com> <538EDB11.6090507@metrico.lu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eRInOfdD3fBUQP8jTulD489aX1POTm7JP" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 In-Reply-To: <538EDB11.6090507@metrico.lu> X-Enigmail-Version: 1.6 X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 11:14:25 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --eRInOfdD3fBUQP8jTulD489aX1POTm7JP Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 04/06/2014 10:38, Frank Broniewski wrote: > Tagged Command Queuing (TCQ) no no > Native Command Queuing (NCQ) yes 32 tags > is NCQ now enabled? The corresponding line in the camcontrol identify > output doesn't tell me that explicitly but also doesn't deny that ... > but the dmesg.boot may hint that the ahci module is loaded ... I'm > confused :-) I think this is normal (unless mav says otherwise :) ) - I get the same on all my systems. Using "camcontrol tags ada3" is a quick way to see the number of tags supported. If NCQ is not enabled, this value is "1". --eRInOfdD3fBUQP8jTulD489aX1POTm7JP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iKYEARECAGYFAlOO/3pfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldDYxNDE4MkQ3ODMwNDAwMDJFRUIzNDhFNUZE MDhENTA2M0RGRjFEMkMACgkQ/QjVBj3/HSyxPwCeJ7TyDbGTnAlBQ7dDRUcSrfpy daMAn3AQbJwzsTwhkXwxkOm0llTT5DAl =RGqX -----END PGP SIGNATURE----- --eRInOfdD3fBUQP8jTulD489aX1POTm7JP-- From owner-freebsd-geom@FreeBSD.ORG Wed Jun 4 16:30:44 2014 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 45AD66AC for ; Wed, 4 Jun 2014 16:30:44 +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)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id F36A32528 for ; Wed, 4 Jun 2014 16:30:43 +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 s54GUfOH063361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Jun 2014 09:30:42 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s54GUeMa063360; Wed, 4 Jun 2014 09:30:40 -0700 (PDT) (envelope-from jmg) Date: Wed, 4 Jun 2014 09:30:40 -0700 From: John-Mark Gurney To: Frank Broniewski Subject: Re: Geom stripe bottleneck Message-ID: <20140604163040.GQ31367@funkthat.com> Mail-Followup-To: Frank Broniewski , freebsd-geom@freebsd.org References: <538D9BC3.6040509@metrico.lu> <20140603204811.GJ31367@funkthat.com> <538EDB11.6090507@metrico.lu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <538EDB11.6090507@metrico.lu> 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-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Wed, 04 Jun 2014 09:30:42 -0700 (PDT) Cc: freebsd-geom@freebsd.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 16:30:44 -0000 Frank Broniewski wrote this message on Wed, Jun 04, 2014 at 10:38 +0200: > thank you very much for your verbose and very helpful answer! I think > that clears things out for me. You're welcome... > I've got a question concerning NCQ though: > > # grep ahci /var/run/dmesg.boot > ahci0: port > 0xb000-0xb007,0xa000-0xa003,0x9000-0x9007,0x8000-0x8003,0x7000-0x700f > mem 0xfaffe400-0xfaffe7ff irq 22 at device 17.0 on pci0 > ahci0: AHCI v1.10 with 4 3Gbps ports, Port Multiplier supported > ahcich0: at channel 0 on ahci0 > ahcich1: at channel 1 on ahci0 > ahcich2: at channel 2 on ahci0 > ahcich3: at channel 3 on ahci0 > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 > ada2 at ahcich2 bus 0 scbus2 target 0 lun 0 > ada3 at ahcich3 bus 0 scbus3 target 0 lun 0 try doing a grep ada0, as mine shows: ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-9 SATA 3.x device ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 2861588MB (5860533168 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad0 You should probably see something similar... > and: > > # camcontrol identify ada3 > pass3: ATA-8 SATA 3.x device > pass3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > > protocol ATA/ATAPI-8 SATA 3.x > device model WDC WD6000HLHX-01JJPV0 > firmware revision 04.05G04 > serial number WD-WXL1E61PWAL2 > WWN 50014ee7aaab0118 > cylinders 16383 > heads 16 > sectors/track 63 > sector size logical 512, physical 512, offset 0 > LBA supported 268435455 sectors > LBA48 supported 1172123568 sectors > PIO supported PIO4 > DMA supported WDMA2 UDMA6 > media RPM 10000 > > 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 yes yes 128/0x80 > automatic acoustic management no no > media status notification no no > power-up in Standby yes no > write-read-verify no no > unload yes yes > free-fall no no > Data Set Management (DSM/TRIM) no > Host Protected Area (HPA) yes no 1172123568/1172123568 > HPA - Security no > > > is NCQ now enabled? The corresponding line in the camcontrol identify > output doesn't tell me that explicitly but also doesn't deny that ... > but the dmesg.boot may hint that the ahci module is loaded ... I'm > confused :-) > > I do not have a ahci_load=YES in /boot/loader.conf (this is on FreeBSD > 9.2-p6) and I don't know if that's still necessary or not. Searching the > internet turned up mostly rather old (2010,2011) results. > > > Am 2014-06-03 22:48, schrieb John-Mark Gurney: > > Frank Broniewski wrote this message on Tue, Jun 03, 2014 at 11:56 +0200: > >> I have a stripe (RAID0) geom setup for my database's data. Currently I > >> am applying some large updates on the data and I think the performance > >> of my stripe could be better. But I am uncertain and so I thought I'd > >> request some interpretation help from the community :) > >> > >> The stripe consists of two disks (WD Velociraptor with 10.000 rpm): > >>> diskinfo -v ada2 > >> ada2 > >> 512 # sectorsize > >> 600127266816 # mediasize in bytes (558G) > >> 1172123568 # mediasize in sectors > >> 0 # stripesize > >> 0 # stripeoffset > >> 1162821 # Cylinders according to firmware. > >> > >> 16 # Heads according to firmware. > >> > >> 63 # Sectors according to firmware. > >> > >> WD-WXH1E61ASNX9 # Disk ident. > >> > >> > >> and /var/log/dmesg.boot > >> # snip > >> ada2 at ahcich2 bus 0 scbus2 target 0 lun 0 > >> ada2: ATA-8 SATA 3.x device > >> ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > >> ada2: Command Queueing enabled > >> ada2: 572325MB (1172123568 512 byte sectors: 16H 63S/T 16383C) > >> ada2: Previously was known as ad8 > >> ada3 at ahcich3 bus 0 scbus3 target 0 lun 0 > >> ada3: ATA-8 SATA 3.x device > >> ada3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > >> ada3: Command Queueing enabled > >> ada3: 572325MB (1172123568 512 byte sectors: 16H 63S/T 16383C) > >> ada3: Previously was known as ad10 > >> #snap > >> > >> > >> And here's some iostat -d -w 10 ada0 ada1 ada2 ada3 example output > >> #snip > >> ada0 ada1 ada2 ada3 > >> KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s > >> 0.00 0 0.00 0.00 0 0.00 19.33 176 3.32 19.33 176 3.32 > >> 16.25 0 0.01 16.25 0 0.01 16.87 133 2.20 16.87 133 2.20 > >> 0.00 0 0.00 0.00 0 0.00 16.77 146 2.40 16.77 147 2.40 > >> 0.00 0 0.00 0.00 0 0.00 19.46 170 3.24 19.45 170 3.23 > >> 21.50 0 0.01 21.50 0 0.01 17.00 125 2.08 17.00 125 2.08 > >> 0.50 0 0.00 0.50 0 0.00 16.88 145 2.38 16.88 145 2.38 > >> 0.00 0 0.00 0.00 0 0.00 16.96 125 2.07 16.97 125 2.07 > >> 0.00 0 0.00 0.00 0 0.00 19.82 158 3.06 19.81 158 3.07 > >> 28.77 1 0.03 28.77 1 0.03 16.83 133 2.19 16.82 133 2.19 > >> #snap > > > > The key here is the tps... Spining drives have a limited number of > > tps... first you have moving the heads, which on average will be ~4ms, > > then you have to wait, on average half a rotation, which for a 10k RPM > > drive is ~3ms, so each seek will take around 7ms, so, as you can see, > > your best number is 176 TPS, or ~8ms/transaction... so, it looks like > > your drives are performing as they should... > > > >> I think the MB/s output is rather low for such a disk. To gain further > >> insight I started gstat: > >> dT: 1.001s w: 1.000s > >> L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name > >> 0 27 0 0 0.0 27 2226 4.8 7.0| ada0 > >> 0 28 1 32 23.9 27 2226 1.3 3.9| ada1 > >> 2 120 115 1838 6.4 5 96 0.2 74.3| ada2 > >> 2 121 116 1854 6.3 5 96 0.4 72.9| ada3 > >> 0 28 1 32 24.0 27 2226 5.0 8.7| mirror/gm > >> 2 121 116 3708 7.9 5 192 0.4 92.2| stripe/gs > >> 0 28 1 32 24.0 27 2226 5.0 8.7| mirror/gms1 > >> 0 12 0 0 0.0 12 1343 9.1 6.9| mirror/gms1a > >> 0 0 0 0 0.0 0 0 0.0 0.0| mirror/gms1b > >> 0 0 0 0 0.0 0 0 0.0 0.0| mirror/gms1d > >> 0 0 0 0 0.0 0 0 0.0 0.0| mirror/gms1e > >> 0 16 1 32 24.0 15 883 1.7 2.9| mirror/gms1f > >> > >> > >> What bothers me here is that the stripe/gs is 92% busy while the disks > >> themselves are only at 74/72%. This lead me to my post here and seek > >> some advice, since I don't know enough about the mechanics and so I > >> can't really find the problem, if there is any at all. > > > > This is because the stripe has to wait for both drives to return data > > before moving the data up... If you're just running a single threaded > > benchmark, there isn't multiple IO's in flight, and there for the > > remaining time is spent in your application before it sends another > > request down to the stripe... the different between stripe and the > > drives is the fact each of them is sometimes faster than the other, > > so again, won't have work to do until another IO is submitted... > > > > Try sending more IO at it, like doing 4 or more dd read's such that > > the between the latency of one IO, there is other IO to server... > > > > Also, make sure that you're using NCQ where the OS can submit multiple > > IO's to the drives at once, this should improve things, but won't > > change the results you see above as it requires multiple IO's > > outstanding... -- 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 Jun 5 08:00:11 2014 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 B9741789 for ; Thu, 5 Jun 2014 08:00:11 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A89872B47 for ; Thu, 5 Jun 2014 08:00:11 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.8/8.14.8) with ESMTP id s5580B6a038749 for ; Thu, 5 Jun 2014 09:00:11 +0100 (BST) (envelope-from bz-noreply@freebsd.org) Message-Id: <201406050800.s5580B6a038749@kenobi.freebsd.org> From: bz-noreply@freebsd.org To: freebsd-geom@FreeBSD.org Subject: [Bugzilla] Commit Needs MFC MIME-Version: 1.0 X-Bugzilla-Type: whine X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated Date: Thu, 05 Jun 2014 08:00:11 +0000 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 08:00:11 -0000 Hi, You have a bug in the "Needs MFC" state which has not been touched in 7 days. This email serves as a reminder that you may want to MFC this bug or marked it as completed. In the event you have a longer MFC timeout you may update this bug with a comment and I won't remind you again for 7 days. This reminder is an experimental feature. Please file a bug or mail bugmeister@ with concerns. This search was scheduled by eadler@FreeBSD.org. (2 bugs) Bug 158398: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=158398 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-geom@FreeBSD.org Status: Needs MFC Resolution: Summary: [headers] [patch] includes gratuitously Bug 176744: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=176744 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-geom@FreeBSD.org Status: Needs MFC Resolution: Summary: [geom] [patch] BIO_FLUSH not recorded by devstats From owner-freebsd-geom@FreeBSD.ORG Fri Jun 6 08:00:12 2014 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 DDDCB401 for ; Fri, 6 Jun 2014 08:00:11 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CCE7921BF for ; Fri, 6 Jun 2014 08:00:11 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.8/8.14.8) with ESMTP id s5680BoV090599 for ; Fri, 6 Jun 2014 09:00:11 +0100 (BST) (envelope-from bz-noreply@freebsd.org) Message-Id: <201406060800.s5680BoV090599@kenobi.freebsd.org> From: bz-noreply@freebsd.org To: freebsd-geom@FreeBSD.org Subject: [Bugzilla] Commit Needs MFC MIME-Version: 1.0 X-Bugzilla-Type: whine X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated Date: Fri, 06 Jun 2014 08:00:11 +0000 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 08:00:12 -0000 Hi, You have a bug in the "Needs MFC" state which has not been touched in 7 days. This email serves as a reminder that you may want to MFC this bug or marked it as completed. In the event you have a longer MFC timeout you may update this bug with a comment and I won't remind you again for 7 days. This reminder is an experimental feature. Please file a bug or mail bugmeister@ with concerns. This search was scheduled by eadler@FreeBSD.org. (2 bugs) Bug 158398: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=158398 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-geom@FreeBSD.org Status: Needs MFC Resolution: Summary: [headers] [patch] includes gratuitously Bug 176744: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=176744 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-geom@FreeBSD.org Status: Needs MFC Resolution: Summary: [geom] [patch] BIO_FLUSH not recorded by devstats From owner-freebsd-geom@FreeBSD.ORG Fri Jun 6 09:38:57 2014 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:1900:2254:206a::19:2]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9FB97F78; Fri, 6 Jun 2014 09:38:57 +0000 (UTC) Received: from butcher-nb.yandex.net (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) by mx2.freebsd.org (Postfix) with ESMTP id A38C13412; Fri, 6 Jun 2014 09:38:55 +0000 (UTC) Message-ID: <53918C0B.5060706@FreeBSD.org> Date: Fri, 06 Jun 2014 13:38:19 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-geom@FreeBSD.org, FreeBSD Hackers Subject: [RFC][RFT] disklabel64 support for GEOM_PART X-Enigmail-Version: 1.6 Content-Type: multipart/mixed; boundary="------------040101090305050600040806" X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 09:38:57 -0000 This is a multi-part message in MIME format. --------------040101090305050600040806 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi All, I've added disklabel64 support for GEOM_PART class. This partitioning scheme is used in DragonFlyBSD. It has the following features: * no part of its metadata is addressable via a partition access; * all offsets are 64-bit; * supports 16 partitions by default (can be extended) * has reserved location for backup label (not yet implemented). If you are able to test compatibility of our implementation and dragonfly's, I'd like to see the results. Currently we have no bootcode that supports this type of disklabel, so it can be only used for data partitions or for access to DragonflyBSD's UFS partitions. There are two patches. The first one add dflybsd's partition types, the second is the disklabel64 implementation. Also, I published them in our phabricator: https://phabric.freebsd.org/D168 https://phabric.freebsd.org/D169 -- WBR, Andrey V. Elsukov --------------040101090305050600040806 Content-Type: text/plain; charset=UTF-8; name="bsd64.diff.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="bsd64.diff.txt" Index: head/sys/geom/part/g_part_bsd64.c =================================================================== --- head/sys/geom/part/g_part_bsd64.c (revision 0) +++ head/sys/geom/part/g_part_bsd64.c (working copy) @@ -0,0 +1,666 @@ +/*- + * Copyright (c) 2014 Andrey V. Elsukov + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. + * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + */ + +#include +__FBSDID("$FreeBSD$"); + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "g_part_if.h" + +FEATURE(geom_part_bsd64, "GEOM partitioning class for 64-bit BSD disklabels"); + +/* XXX: move this to sys/disklabel64.h */ +#define DISKMAGIC64 ((uint32_t)0xc4464c59) +#define MAXPARTITIONS64 16 +#define RESPARTITIONS64 32 + +struct disklabel64 { + char d_reserved0[512]; /* reserved or unused */ + u_int32_t d_magic; /* the magic number */ + u_int32_t d_crc; /* crc32() d_magic thru last part */ + u_int32_t d_align; /* partition alignment requirement */ + u_int32_t d_npartitions; /* number of partitions */ + struct uuid d_stor_uuid; /* unique uuid for label */ + + u_int64_t d_total_size; /* total size incl everything (bytes) */ + u_int64_t d_bbase; /* boot area base offset (bytes) */ + /* boot area is pbase - bbase */ + u_int64_t d_pbase; /* first allocatable offset (bytes) */ + u_int64_t d_pstop; /* last allocatable offset+1 (bytes) */ + u_int64_t d_abase; /* location of backup copy if not 0 */ + + u_char d_packname[64]; + u_char d_reserved[64]; + + /* + * Note: offsets are relative to the base of the slice, NOT to + * d_pbase. Unlike 32 bit disklabels the on-disk format for + * a 64 bit disklabel remains slice-relative. + * + * An uninitialized partition has a p_boffset and p_bsize of 0. + * + * If p_fstype is not supported for a live partition it is set + * to FS_OTHER. This is typically the case when the filesystem + * is identified by its uuid. + */ + struct partition64 { /* the partition table */ + u_int64_t p_boffset; /* slice relative offset, in bytes */ + u_int64_t p_bsize; /* size of partition, in bytes */ + u_int8_t p_fstype; + u_int8_t p_unused01; /* reserved, must be 0 */ + u_int8_t p_unused02; /* reserved, must be 0 */ + u_int8_t p_unused03; /* reserved, must be 0 */ + u_int32_t p_unused04; /* reserved, must be 0 */ + u_int32_t p_unused05; /* reserved, must be 0 */ + u_int32_t p_unused06; /* reserved, must be 0 */ + struct uuid p_type_uuid;/* mount type as UUID */ + struct uuid p_stor_uuid;/* unique uuid for storage */ + } d_partitions[MAXPARTITIONS64];/* actually may be more */ +}; + +struct g_part_bsd64_table { + struct g_part_table base; + + uint32_t d_align; + uint64_t d_bbase; + uint64_t d_abase; + struct uuid d_stor_uuid; + char d_reserved0[512]; + u_char d_packname[64]; + u_char d_reserved[64]; +}; + +struct g_part_bsd64_entry { + struct g_part_entry base; + + uint8_t fstype; + struct uuid type_uuid; + struct uuid stor_uuid; +}; + +static int g_part_bsd64_add(struct g_part_table *, struct g_part_entry *, + struct g_part_parms *); +static int g_part_bsd64_bootcode(struct g_part_table *, struct g_part_parms *); +static int g_part_bsd64_create(struct g_part_table *, struct g_part_parms *); +static int g_part_bsd64_destroy(struct g_part_table *, struct g_part_parms *); +static void g_part_bsd64_dumpconf(struct g_part_table *, struct g_part_entry *, + struct sbuf *, const char *); +static int g_part_bsd64_dumpto(struct g_part_table *, struct g_part_entry *); +static int g_part_bsd64_modify(struct g_part_table *, struct g_part_entry *, + struct g_part_parms *); +static const char *g_part_bsd64_name(struct g_part_table *, struct g_part_entry *, + char *, size_t); +static int g_part_bsd64_probe(struct g_part_table *, struct g_consumer *); +static int g_part_bsd64_read(struct g_part_table *, struct g_consumer *); +static const char *g_part_bsd64_type(struct g_part_table *, struct g_part_entry *, + char *, size_t); +static int g_part_bsd64_write(struct g_part_table *, struct g_consumer *); +static int g_part_bsd64_resize(struct g_part_table *, struct g_part_entry *, + struct g_part_parms *); + +static kobj_method_t g_part_bsd64_methods[] = { + KOBJMETHOD(g_part_add, g_part_bsd64_add), + KOBJMETHOD(g_part_bootcode, g_part_bsd64_bootcode), + KOBJMETHOD(g_part_create, g_part_bsd64_create), + KOBJMETHOD(g_part_destroy, g_part_bsd64_destroy), + KOBJMETHOD(g_part_dumpconf, g_part_bsd64_dumpconf), + KOBJMETHOD(g_part_dumpto, g_part_bsd64_dumpto), + KOBJMETHOD(g_part_modify, g_part_bsd64_modify), + KOBJMETHOD(g_part_resize, g_part_bsd64_resize), + KOBJMETHOD(g_part_name, g_part_bsd64_name), + KOBJMETHOD(g_part_probe, g_part_bsd64_probe), + KOBJMETHOD(g_part_read, g_part_bsd64_read), + KOBJMETHOD(g_part_type, g_part_bsd64_type), + KOBJMETHOD(g_part_write, g_part_bsd64_write), + { 0, 0 } +}; + +static struct g_part_scheme g_part_bsd64_scheme = { + "BSD64", + g_part_bsd64_methods, + sizeof(struct g_part_bsd64_table), + .gps_entrysz = sizeof(struct g_part_bsd64_entry), + .gps_minent = MAXPARTITIONS64, + .gps_maxent = MAXPARTITIONS64 +}; +G_PART_SCHEME_DECLARE(g_part_bsd64); + +#define EQUUID(a, b) (memcmp(a, b, sizeof(struct uuid)) == 0) +static struct uuid bsd64_uuid_unused = GPT_ENT_TYPE_UNUSED; +static struct uuid bsd64_uuid_dfbsd_swap = GPT_ENT_TYPE_DRAGONFLY_SWAP; +static struct uuid bsd64_uuid_dfbsd_ufs1 = GPT_ENT_TYPE_DRAGONFLY_UFS1; +static struct uuid bsd64_uuid_dfbsd_vinum = GPT_ENT_TYPE_DRAGONFLY_VINUM; +static struct uuid bsd64_uuid_dfbsd_ccd = GPT_ENT_TYPE_DRAGONFLY_CCD; +static struct uuid bsd64_uuid_dfbsd_legacy = GPT_ENT_TYPE_DRAGONFLY_LEGACY; +static struct uuid bsd64_uuid_dfbsd_hammer = GPT_ENT_TYPE_DRAGONFLY_HAMMER; +static struct uuid bsd64_uuid_dfbsd_hammer2 = GPT_ENT_TYPE_DRAGONFLY_HAMMER2; +static struct uuid bsd64_uuid_freebsd_boot = GPT_ENT_TYPE_FREEBSD_BOOT; +static struct uuid bsd64_uuid_freebsd_nandfs = GPT_ENT_TYPE_FREEBSD_NANDFS; +static struct uuid bsd64_uuid_freebsd_swap = GPT_ENT_TYPE_FREEBSD_SWAP; +static struct uuid bsd64_uuid_freebsd_ufs = GPT_ENT_TYPE_FREEBSD_UFS; +static struct uuid bsd64_uuid_freebsd_vinum = GPT_ENT_TYPE_FREEBSD_VINUM; +static struct uuid bsd64_uuid_freebsd_zfs = GPT_ENT_TYPE_FREEBSD_ZFS; + +struct bsd64_uuid_alias { + struct uuid *uuid; + uint8_t fstype; + int alias; +}; +static struct bsd64_uuid_alias dfbsd_alias_match[] = { + { &bsd64_uuid_dfbsd_swap, FS_SWAP, G_PART_ALIAS_DFBSD_SWAP }, + { &bsd64_uuid_dfbsd_ufs1, FS_BSDFFS, G_PART_ALIAS_DFBSD_UFS }, + { &bsd64_uuid_dfbsd_vinum, FS_VINUM, G_PART_ALIAS_DFBSD_VINUM }, + { &bsd64_uuid_dfbsd_ccd, FS_CCD, G_PART_ALIAS_DFBSD_CCD }, + { &bsd64_uuid_dfbsd_legacy, FS_OTHER, G_PART_ALIAS_DFBSD_LEGACY }, + { &bsd64_uuid_dfbsd_hammer, FS_HAMMER, G_PART_ALIAS_DFBSD_HAMMER }, + { &bsd64_uuid_dfbsd_hammer2, FS_HAMMER2, G_PART_ALIAS_DFBSD_HAMMER2 }, + { NULL, 0, 0} +}; +static struct bsd64_uuid_alias fbsd_alias_match[] = { + { &bsd64_uuid_freebsd_boot, FS_OTHER, G_PART_ALIAS_FREEBSD_BOOT }, + { &bsd64_uuid_freebsd_swap, FS_OTHER, G_PART_ALIAS_FREEBSD_SWAP }, + { &bsd64_uuid_freebsd_ufs, FS_OTHER, G_PART_ALIAS_FREEBSD_UFS }, + { &bsd64_uuid_freebsd_zfs, FS_OTHER, G_PART_ALIAS_FREEBSD_ZFS }, + { &bsd64_uuid_freebsd_vinum, FS_OTHER, G_PART_ALIAS_FREEBSD_VINUM }, + { &bsd64_uuid_freebsd_nandfs, FS_OTHER, G_PART_ALIAS_FREEBSD_NANDFS }, + { NULL, 0, 0} +}; + +static int +bsd64_parse_type(const char *type, struct g_part_bsd64_entry *entry) +{ + struct uuid tmp; + const struct bsd64_uuid_alias *uap; + const char *alias; + char *p; + long lt; + int error; + + if (type[0] == '!') { + if (type[1] == '\0') + return (EINVAL); + lt = strtol(type + 1, &p, 0); + /* The type specified as number */ + if (*p == '\0') { + if (lt <= 0 || lt > 255) + return (EINVAL); + entry->fstype = lt; + entry->type_uuid = bsd64_uuid_unused; + return (0); + } + /* The type specified as uuid */ + error = parse_uuid(type + 1, &tmp); + if (error != 0) + return (error); + if (EQUUID(&tmp, &bsd64_uuid_unused)) + return (EINVAL); + for (uap = &dfbsd_alias_match[0]; uap->uuid != NULL; uap++) { + if (EQUUID(&tmp, uap->uuid)) { + /* Prefer fstype for known uuids */ + entry->type_uuid = bsd64_uuid_unused; + entry->fstype = uap->fstype; + return (0); + } + } + entry->type_uuid = tmp; + entry->fstype = FS_OTHER; + return (0); + } + /* The type specified as symbolic alias name */ + for (uap = &fbsd_alias_match[0]; uap->uuid != NULL; uap++) { + alias = g_part_alias_name(uap->alias); + if (!strcasecmp(type, alias)) { + entry->type_uuid = *uap->uuid; + entry->fstype = uap->fstype; + return (0); + } + } + for (uap = &dfbsd_alias_match[0]; uap->uuid != NULL; uap++) { + alias = g_part_alias_name(uap->alias); + if (!strcasecmp(type, alias)) { + entry->type_uuid = bsd64_uuid_unused; + entry->fstype = uap->fstype; + return (0); + } + } + return (EINVAL); +} + +static int +g_part_bsd64_add(struct g_part_table *basetable, struct g_part_entry *baseentry, + struct g_part_parms *gpp) +{ + struct g_part_bsd64_entry *entry; + + if (gpp->gpp_parms & G_PART_PARM_LABEL) + return (EINVAL); + + entry = (struct g_part_bsd64_entry *)baseentry; + if (bsd64_parse_type(gpp->gpp_type, entry) != 0) + return (EINVAL); + kern_uuidgen(&entry->stor_uuid, 1); + return (0); +} + +static int +g_part_bsd64_bootcode(struct g_part_table *basetable, struct g_part_parms *gpp) +{ + + return (EOPNOTSUPP); +} + +#define PALIGN_SIZE (1024 * 1024) +#define PALIGN_MASK (PALIGN_SIZE - 1) +#define BLKSIZE (4 * 1024) +#define BOOTSIZE (32 * 1024) +#define DALIGN_SIZE (32 * 1024) +static int +g_part_bsd64_create(struct g_part_table *basetable, struct g_part_parms *gpp) +{ + struct g_part_bsd64_table *table; + struct g_part_entry *baseentry; + struct g_provider *pp; + uint64_t blkmask, pbase; + uint32_t blksize, ressize; + + pp = gpp->gpp_provider; + if (pp->mediasize < 2* PALIGN_SIZE) + return (ENOSPC); + + /* + * Use at least 4KB block size. Blksize is stored in the d_align. + * XXX: Actually it is used just for calculate d_bbase and used + * for better alignment in bsdlabel64(8). + */ + blksize = pp->sectorsize < BLKSIZE ? BLKSIZE: pp->sectorsize; + blkmask = blksize - 1; + /* Reserve enough space for RESPARTITIONS64 partitions. */ + ressize = offsetof(struct disklabel64, d_partitions[RESPARTITIONS64]); + ressize = (ressize + blkmask) & ~blkmask; + /* + * Reserve enough space for bootcode and align first allocatable + * offset to PALIGN_SIZE. + * XXX: Currently DragonFlyBSD has 32KB bootcode, but the size could + * be bigger, because it is possible change it (it is equal pbase-bbase) + * in the bsdlabel64(8). + */ + pbase = ressize + ((BOOTSIZE + blkmask) & ~blkmask); + pbase = (pbase + PALIGN_MASK) & ~PALIGN_MASK; + /* + * Take physical offset into account and make first allocatable + * offset 32KB aligned to the start of the physical disk. + * XXX: Actually there are no such restrictions, this is how + * DragonFlyBSD behaves. + */ + pbase += DALIGN_SIZE - pp->stripeoffset % DALIGN_SIZE; + + table = (struct g_part_bsd64_table *)basetable; + table->d_align = blksize; + table->d_bbase = ressize / pp->sectorsize; + table->d_abase = ((pp->mediasize - ressize) & + ~blkmask) / pp->sectorsize; + kern_uuidgen(&table->d_stor_uuid, 1); + basetable->gpt_first = pbase / pp->sectorsize; + basetable->gpt_last = table->d_abase - 1; /* XXX */ + /* + * Create 'c' partition and make it internal, so user will not be + * able use it. + */ + baseentry = g_part_new_entry(basetable, RAW_PART + 1, 0, 0); + baseentry->gpe_internal = 1; + return (0); +} + +static int +g_part_bsd64_destroy(struct g_part_table *basetable, struct g_part_parms *gpp) +{ + struct g_provider *pp; + + pp = LIST_FIRST(&basetable->gpt_gp->consumer)->provider; + if (pp->sectorsize > offsetof(struct disklabel64, d_magic)) + basetable->gpt_smhead |= 1; + else + basetable->gpt_smhead |= 3; + return (0); +} + +static void +g_part_bsd64_dumpconf(struct g_part_table *basetable, + struct g_part_entry *baseentry, struct sbuf *sb, const char *indent) +{ + struct g_part_bsd64_table *table; + struct g_part_bsd64_entry *entry; + char buf[sizeof(table->d_packname)]; + + entry = (struct g_part_bsd64_entry *)baseentry; + if (indent == NULL) { + /* conftxt: libdisk compatibility */ + sbuf_printf(sb, " xs BSD64 xt %u", entry->fstype); + } else if (entry != NULL) { + /* confxml: partition entry information */ + sbuf_printf(sb, "%s%u\n", indent, + entry->fstype); + if (!EQUUID(&bsd64_uuid_unused, &entry->type_uuid)) { + sbuf_printf(sb, "%s", indent); + sbuf_printf_uuid(sb, &entry->type_uuid); + sbuf_printf(sb, "\n"); + } + sbuf_printf(sb, "%s", indent); + sbuf_printf_uuid(sb, &entry->stor_uuid); + sbuf_printf(sb, "\n"); + } else { + /* confxml: scheme information */ + table = (struct g_part_bsd64_table *)basetable; + sbuf_printf(sb, "%s%ju\n", indent, + (uintmax_t)table->d_bbase); + if (table->d_abase) + sbuf_printf(sb, "%s%ju\n", + indent, (uintmax_t)table->d_abase); + sbuf_printf(sb, "%s", indent); + sbuf_printf_uuid(sb, &table->d_stor_uuid); + sbuf_printf(sb, "\n"); + sbuf_printf(sb, "%s\n"); + } +} + +static int +g_part_bsd64_dumpto(struct g_part_table *table, struct g_part_entry *baseentry) +{ + struct g_part_bsd64_entry *entry; + + /* Allow dumping to a swap partition. */ + entry = (struct g_part_bsd64_entry *)baseentry; + if (entry->fstype == FS_SWAP || + EQUUID(&entry->type_uuid, &bsd64_uuid_dfbsd_swap) || + EQUUID(&entry->type_uuid, &bsd64_uuid_freebsd_swap)) + return (1); + return (0); +} + +static int +g_part_bsd64_modify(struct g_part_table *basetable, + struct g_part_entry *baseentry, struct g_part_parms *gpp) +{ + struct g_part_bsd64_entry *entry; + + if (gpp->gpp_parms & G_PART_PARM_LABEL) + return (EINVAL); + + entry = (struct g_part_bsd64_entry *)baseentry; + if (gpp->gpp_parms & G_PART_PARM_TYPE) + return (bsd64_parse_type(gpp->gpp_type, entry)); + return (0); +} + +static int +g_part_bsd64_resize(struct g_part_table *basetable, + struct g_part_entry *baseentry, struct g_part_parms *gpp) +{ + struct g_part_bsd64_table *table; + struct g_provider *pp; + + if (baseentry == NULL) { + pp = LIST_FIRST(&basetable->gpt_gp->consumer)->provider; + table = (struct g_part_bsd64_table *)basetable; + table->d_abase = ((pp->mediasize - + table->d_bbase * pp->sectorsize) & ~(table->d_align - 1)) / + pp->sectorsize; + basetable->gpt_last = table->d_abase - 1; + return (0); + } + baseentry->gpe_end = baseentry->gpe_start + gpp->gpp_size - 1; + return (0); +} + +static const char * +g_part_bsd64_name(struct g_part_table *table, struct g_part_entry *baseentry, + char *buf, size_t bufsz) +{ + + snprintf(buf, bufsz, "%c", 'a' + baseentry->gpe_index - 1); + return (buf); +} + +static int +g_part_bsd64_probe(struct g_part_table *table, struct g_consumer *cp) +{ + struct g_provider *pp; + uint32_t v; + int error; + u_char *buf; + + pp = cp->provider; + if (pp->mediasize < 2 * PALIGN_SIZE) + return (ENOSPC); + v = (pp->sectorsize + + offsetof(struct disklabel64, d_magic)) & ~(pp->sectorsize - 1); + buf = g_read_data(cp, 0, v, &error); + if (buf == NULL) + return (error); + v = le32dec(buf + offsetof(struct disklabel64, d_magic)); + g_free(buf); + return (v == DISKMAGIC64 ? G_PART_PROBE_PRI_HIGH: ENXIO); +} + +static int +g_part_bsd64_read(struct g_part_table *basetable, struct g_consumer *cp) +{ + struct g_part_bsd64_table *table; + struct g_part_bsd64_entry *entry; + struct g_part_entry *baseentry; + struct g_provider *pp; + struct disklabel64 *dlp; + uint64_t v64, sz; + uint32_t v32; + int error, index; + u_char *buf; + + pp = cp->provider; + table = (struct g_part_bsd64_table *)basetable; + v32 = (pp->sectorsize + + sizeof(struct disklabel64) - 1) & ~(pp->sectorsize - 1); + buf = g_read_data(cp, 0, v32, &error); + if (buf == NULL) + return (error); + + dlp = (struct disklabel64 *)buf; + basetable->gpt_entries = le32toh(dlp->d_npartitions); + if (basetable->gpt_entries > MAXPARTITIONS64) + goto invalid_label; + v32 = le32toh(dlp->d_crc); + dlp->d_crc = 0; + if (crc32(&dlp->d_magic, offsetof(struct disklabel64, + d_partitions[basetable->gpt_entries]) - + offsetof(struct disklabel64, d_magic)) != v32) + goto invalid_label; + table->d_align = le32toh(dlp->d_align); + if (table->d_align == 0 || (table->d_align & (pp->sectorsize - 1))) + goto invalid_label; + if (le64toh(dlp->d_total_size) > pp->mediasize) + goto invalid_label; + v64 = le64toh(dlp->d_pbase); + if (v64 % pp->sectorsize) + goto invalid_label; + basetable->gpt_first = v64 / pp->sectorsize; + v64 = le64toh(dlp->d_pstop); + if (v64 % pp->sectorsize) + goto invalid_label; + basetable->gpt_last = v64 / pp->sectorsize; + basetable->gpt_isleaf = 1; + v64 = le64toh(dlp->d_bbase); + if (v64 % pp->sectorsize) + goto invalid_label; + table->d_bbase = v64 / pp->sectorsize; + v64 = le64toh(dlp->d_abase); + if (v64 % pp->sectorsize) + goto invalid_label; + table->d_abase = v64 / pp->sectorsize; + le_uuid_dec(&dlp->d_stor_uuid, &table->d_stor_uuid); + for (index = basetable->gpt_entries - 1; index >= 0; index--) { + if (index == RAW_PART) { + /* Skip 'c' partition. */ + baseentry = g_part_new_entry(basetable, + index + 1, 0, 0); + baseentry->gpe_internal = 1; + continue; + } + v64 = le64toh(dlp->d_partitions[index].p_boffset); + sz = le64toh(dlp->d_partitions[index].p_bsize); + if (sz == 0 && v64 == 0) + continue; + if (sz == 0 || (v64 % pp->sectorsize) || (sz % pp->sectorsize)) + goto invalid_label; + baseentry = g_part_new_entry(basetable, index + 1, + v64 / pp->sectorsize, (v64 + sz) / pp->sectorsize - 1); + entry = (struct g_part_bsd64_entry *)baseentry; + le_uuid_dec(&dlp->d_partitions[index].p_type_uuid, + &entry->type_uuid); + le_uuid_dec(&dlp->d_partitions[index].p_stor_uuid, + &entry->stor_uuid); + entry->fstype = dlp->d_partitions[index].p_fstype; + if (index == RAW_PART) + baseentry->gpe_internal = 1; + } + bcopy(dlp->d_reserved0, table->d_reserved0, + sizeof(table->d_reserved0)); + bcopy(dlp->d_packname, table->d_packname, sizeof(table->d_packname)); + bcopy(dlp->d_reserved, table->d_reserved, sizeof(table->d_reserved)); + g_free(buf); + return (0); + +invalid_label: + g_free(buf); + return (EINVAL); +} + +static const char * +g_part_bsd64_type(struct g_part_table *basetable, struct g_part_entry *baseentry, + char *buf, size_t bufsz) +{ + struct g_part_bsd64_entry *entry; + struct bsd64_uuid_alias *uap; + + entry = (struct g_part_bsd64_entry *)baseentry; + if (entry->fstype != FS_OTHER) { + for (uap = &dfbsd_alias_match[0]; uap->uuid != NULL; uap++) + if (uap->fstype == entry->fstype) + return (g_part_alias_name(uap->alias)); + } else { + for (uap = &fbsd_alias_match[0]; uap->uuid != NULL; uap++) + if (EQUUID(uap->uuid, &entry->type_uuid)) + return (g_part_alias_name(uap->alias)); + for (uap = &dfbsd_alias_match[0]; uap->uuid != NULL; uap++) + if (EQUUID(uap->uuid, &entry->type_uuid)) + return (g_part_alias_name(uap->alias)); + } + if (EQUUID(&bsd64_uuid_unused, &entry->type_uuid)) + snprintf(buf, bufsz, "!%d", entry->fstype); + else { + buf[0] = '!'; + snprintf_uuid(buf + 1, bufsz - 1, &entry->type_uuid); + } + return (buf); +} + +static int +g_part_bsd64_write(struct g_part_table *basetable, struct g_consumer *cp) +{ + struct g_provider *pp; + struct g_part_entry *baseentry; + struct g_part_bsd64_entry *entry; + struct g_part_bsd64_table *table; + struct disklabel64 *dlp; + uint32_t v, sz; + int error, index; + + pp = cp->provider; + table = (struct g_part_bsd64_table *)basetable; + sz = (pp->sectorsize + + sizeof(struct disklabel64) - 1) & ~(pp->sectorsize - 1); + dlp = g_malloc(sz, M_WAITOK | M_ZERO); + + memcpy(dlp->d_reserved0, table->d_reserved0, + sizeof(table->d_reserved0)); + memcpy(dlp->d_packname, table->d_packname, sizeof(table->d_packname)); + memcpy(dlp->d_reserved, table->d_reserved, sizeof(table->d_reserved)); + le32enc(&dlp->d_magic, DISKMAGIC64); + le32enc(&dlp->d_align, table->d_align); + le32enc(&dlp->d_npartitions, basetable->gpt_entries); + le_uuid_enc(&dlp->d_stor_uuid, &table->d_stor_uuid); + le64enc(&dlp->d_total_size, pp->mediasize); + le64enc(&dlp->d_bbase, table->d_bbase * pp->sectorsize); + le64enc(&dlp->d_pbase, basetable->gpt_first * pp->sectorsize); + le64enc(&dlp->d_pstop, basetable->gpt_last * pp->sectorsize); + le64enc(&dlp->d_abase, table->d_abase * pp->sectorsize); + + LIST_FOREACH(baseentry, &basetable->gpt_entry, gpe_entry) { + if (baseentry->gpe_deleted) + continue; + index = baseentry->gpe_index - 1; + entry = (struct g_part_bsd64_entry *)baseentry; + if (index == RAW_PART) + continue; + le64enc(&dlp->d_partitions[index].p_boffset, + baseentry->gpe_start * pp->sectorsize); + le64enc(&dlp->d_partitions[index].p_bsize, pp->sectorsize * + (baseentry->gpe_end - baseentry->gpe_start + 1)); + dlp->d_partitions[index].p_fstype = entry->fstype; + le_uuid_enc(&dlp->d_partitions[index].p_type_uuid, + &entry->type_uuid); + le_uuid_enc(&dlp->d_partitions[index].p_stor_uuid, + &entry->stor_uuid); + } + /* Calculate checksum. */ + v = offsetof(struct disklabel64, + d_partitions[basetable->gpt_entries]) - + offsetof(struct disklabel64, d_magic); + le32enc(&dlp->d_crc, crc32(&dlp->d_magic, v)); + error = g_write_data(cp, 0, dlp, sz); + g_free(dlp); + return (error); +} Property changes on: head/sys/geom/part/g_part_bsd64.c ___________________________________________________________________ Added: svn:eol-style ## -0,0 +1 ## +native \ No newline at end of property Added: svn:mime-type ## -0,0 +1 ## +text/plain \ No newline at end of property Added: svn:keywords ## -0,0 +1 ## +FreeBSD=%H \ No newline at end of property Index: head/sys/conf/NOTES =================================================================== --- head/sys/conf/NOTES (revision 267040) +++ head/sys/conf/NOTES (working copy) @@ -162,6 +162,7 @@ options GEOM_MULTIPATH # Disk multipath options GEOM_NOP # Test class. options GEOM_PART_APM # Apple partitioning options GEOM_PART_BSD # BSD disklabel +options GEOM_PART_BSD64 # BSD disklabel64 options GEOM_PART_EBR # Extended Boot Records options GEOM_PART_EBR_COMPAT # Backward compatible partition names options GEOM_PART_GPT # GPT partitioning Index: head/sys/conf/files =================================================================== --- head/sys/conf/files (revision 267040) +++ head/sys/conf/files (working copy) @@ -2756,6 +2756,7 @@ geom/part/g_part.c standard geom/part/g_part_if.m standard geom/part/g_part_apm.c optional geom_part_apm geom/part/g_part_bsd.c optional geom_part_bsd +geom/part/g_part_bsd64.c optional geom_part_bsd64 geom/part/g_part_ebr.c optional geom_part_ebr geom/part/g_part_gpt.c optional geom_part_gpt geom/part/g_part_ldm.c optional geom_part_ldm Index: head/sys/conf/options =================================================================== --- head/sys/conf/options (revision 267040) +++ head/sys/conf/options (working copy) @@ -111,6 +111,7 @@ GEOM_MULTIPATH opt_geom.h GEOM_NOP opt_geom.h GEOM_PART_APM opt_geom.h GEOM_PART_BSD opt_geom.h +GEOM_PART_BSD64 opt_geom.h GEOM_PART_EBR opt_geom.h GEOM_PART_EBR_COMPAT opt_geom.h GEOM_PART_GPT opt_geom.h Index: head/sys/modules/geom/geom_part/Makefile =================================================================== --- head/sys/modules/geom/geom_part/Makefile (revision 267040) +++ head/sys/modules/geom/geom_part/Makefile (working copy) @@ -2,6 +2,7 @@ SUBDIR= geom_part_apm \ geom_part_bsd \ + geom_part_bsd64 \ geom_part_ebr \ geom_part_gpt \ geom_part_ldm \ Index: head/sys/modules/geom/geom_part/geom_part_bsd64/Makefile =================================================================== --- head/sys/modules/geom/geom_part/geom_part_bsd64/Makefile (revision 0) +++ head/sys/modules/geom/geom_part/geom_part_bsd64/Makefile (working copy) @@ -0,0 +1,12 @@ +# $FreeBSD$ + +.PATH: ${.CURDIR}/../../../../geom/part + +KMOD= geom_part_bsd64 +SRCS= g_part_bsd64.c + +SRCS+= bus_if.h device_if.h g_part_if.h + +MFILES= kern/bus_if.m kern/device_if.m geom/part/g_part_if.m + +.include Property changes on: head/sys/modules/geom/geom_part/geom_part_bsd64/Makefile ___________________________________________________________________ Added: svn:mime-type ## -0,0 +1 ## +text/plain \ No newline at end of property Added: svn:keywords ## -0,0 +1 ## +FreeBSD=%H \ No newline at end of property Added: svn:eol-style ## -0,0 +1 ## +native \ No newline at end of property Index: head/sbin/geom/class/part/gpart.8 =================================================================== --- head/sbin/geom/class/part/gpart.8 (revision 267040) +++ head/sbin/geom/class/part/gpart.8 (working copy) @@ -491,6 +491,12 @@ called Requires the .Cm GEOM_PART_BSD kernel option. +.It Cm BSD64 +64-bit implementation of BSD disklabel used in DragonFlyBSD to subdivide MBR +or GPT partitions. +Requires the +.Cm GEOM_PART_BSD64 +kernel option. .It Cm LDM The Logical Disk Manager is an implementation of volume manager for Microsoft Windows NT. --------------040101090305050600040806 Content-Type: text/plain; charset=UTF-8; name="dfbsd-types.diff.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dfbsd-types.diff.txt" Index: head/sys/sys/disklabel.h =================================================================== --- head/sys/sys/disklabel.h (revision 267040) +++ head/sys/sys/disklabel.h (working copy) @@ -229,6 +229,8 @@ static const char *dktypenames[] = { #define FS_NTFS 18 /* Windows/NT file system */ #define FS_CCD 20 /* concatenated disk component */ #define FS_JFS2 21 /* IBM JFS2 */ +#define FS_HAMMER 22 /* DragonFlyBSD Hammer FS */ +#define FS_HAMMER2 23 /* DragonFlyBSD Hammer2 FS */ #define FS_UDF 24 /* UDF */ #define FS_EFS 26 /* SGI's Extent File system */ #define FS_ZFS 27 /* Sun's ZFS */ @@ -258,8 +260,8 @@ static const char *fstypenames[] = { "?", "ccd", "jfs", - "?", - "?", + "HAMMER", + "HAMMER2", "UDF", "?", "EFS", Index: head/sys/sys/gpt.h =================================================================== --- head/sys/sys/gpt.h (revision 267040) +++ head/sys/sys/gpt.h (working copy) @@ -161,6 +161,25 @@ struct gpt_ent { #define GPT_ENT_TYPE_NETBSD_CGD \ {0x2db519ec,0xb10f,0x11dc,0xb9,0x9b,{0x00,0x19,0xd1,0x87,0x96,0x48}} +#define GPT_ENT_TYPE_DRAGONFLY_LABEL32 \ + {0x9d087404,0x1ca5,0x11dc,0x88,0x17,{0x01,0x30,0x1b,0xb8,0xa9,0xf5}} +#define GPT_ENT_TYPE_DRAGONFLY_SWAP \ + {0x9d58fdbd,0x1ca5,0x11dc,0x88,0x17,{0x01,0x30,0x1b,0xb8,0xa9,0xf5}} +#define GPT_ENT_TYPE_DRAGONFLY_UFS1 \ + {0x9d94ce7c,0x1ca5,0x11dc,0x88,0x17,{0x01,0x30,0x1b,0xb8,0xa9,0xf5}} +#define GPT_ENT_TYPE_DRAGONFLY_VINUM \ + {0x9dd4478f,0x1ca5,0x11dc,0x88,0x17,{0x01,0x30,0x1b,0xb8,0xa9,0xf5}} +#define GPT_ENT_TYPE_DRAGONFLY_CCD \ + {0xdbd5211b,0x1ca5,0x11dc,0x88,0x17,{0x01,0x30,0x1b,0xb8,0xa9,0xf5}} +#define GPT_ENT_TYPE_DRAGONFLY_LABEL64 \ + {0x3d48ce54,0x1d16,0x11dc,0x86,0x96,{0x01,0x30,0x1b,0xb8,0xa9,0xf5}} +#define GPT_ENT_TYPE_DRAGONFLY_LEGACY \ + {0xbd215ab2,0x1d16,0x11dc,0x86,0x96,{0x01,0x30,0x1b,0xb8,0xa9,0xf5}} +#define GPT_ENT_TYPE_DRAGONFLY_HAMMER \ + {0x61dc63ac,0x6e38,0x11dc,0x85,0x13,{0x01,0x30,0x1b,0xb8,0xa9,0xf5}} +#define GPT_ENT_TYPE_DRAGONFLY_HAMMER2 \ + {0x5cbb9ad1,0x862d,0x11dc,0xa9,0x4d,{0x01,0x30,0x1b,0xb8,0xa9,0xf5}} + /* * Boot partition used by GRUB 2. */ Index: head/sys/geom/part/g_part.c =================================================================== --- head/sys/geom/part/g_part.c (revision 267040) +++ head/sys/geom/part/g_part.c (working copy) @@ -108,6 +108,15 @@ struct g_part_alias_list { { "vmware-vmkdiag", G_PART_ALIAS_VMKDIAG }, { "vmware-reserved", G_PART_ALIAS_VMRESERVED }, { "vmware-vsanhdr", G_PART_ALIAS_VMVSANHDR }, + { "dragonfly-label32", G_PART_ALIAS_DFBSD }, + { "dragonfly-label64", G_PART_ALIAS_DFBSD64 }, + { "dragonfly-swap", G_PART_ALIAS_DFBSD_SWAP }, + { "dragonfly-ufs", G_PART_ALIAS_DFBSD_UFS }, + { "dragonfly-vinum", G_PART_ALIAS_DFBSD_VINUM }, + { "dragonfly-ccd", G_PART_ALIAS_DFBSD_CCD }, + { "dragonfly-legacy", G_PART_ALIAS_DFBSD_LEGACY }, + { "dragonfly-hammer", G_PART_ALIAS_DFBSD_HAMMER }, + { "dragonfly-hammer2", G_PART_ALIAS_DFBSD_HAMMER2 }, }; SYSCTL_DECL(_kern_geom); Index: head/sys/geom/part/g_part.h =================================================================== --- head/sys/geom/part/g_part.h (revision 267040) +++ head/sys/geom/part/g_part.h (working copy) @@ -75,6 +75,15 @@ enum g_part_alias { G_PART_ALIAS_VMKDIAG, /* A VMware vmkDiagnostic partition entry */ G_PART_ALIAS_VMRESERVED, /* A VMware reserved partition entry */ G_PART_ALIAS_VMVSANHDR, /* A VMware vSAN header partition entry */ + G_PART_ALIAS_DFBSD, /* A DfBSD label32 partition entry */ + G_PART_ALIAS_DFBSD64, /* A DfBSD label64 partition entry */ + G_PART_ALIAS_DFBSD_SWAP, /* A DfBSD swap partition entry */ + G_PART_ALIAS_DFBSD_UFS, /* A DfBSD UFS partition entry */ + G_PART_ALIAS_DFBSD_VINUM, /* A DfBSD Vinum partition entry */ + G_PART_ALIAS_DFBSD_CCD, /* A DfBSD CCD partition entry */ + G_PART_ALIAS_DFBSD_LEGACY, /* A DfBSD legacy partition entry */ + G_PART_ALIAS_DFBSD_HAMMER, /* A DfBSD HAMMER FS partition entry */ + G_PART_ALIAS_DFBSD_HAMMER2, /* A DfBSD HAMMER2 FS partition entry */ /* Keep the following last */ G_PART_ALIAS_COUNT }; Index: head/sys/geom/part/g_part_bsd.c =================================================================== --- head/sys/geom/part/g_part_bsd.c (revision 267040) +++ head/sys/geom/part/g_part_bsd.c (working copy) @@ -112,6 +112,19 @@ static struct g_part_scheme g_part_bsd_scheme = { }; G_PART_SCHEME_DECLARE(g_part_bsd); +static struct g_part_bsd_alias { + uint8_t type; + int alias; +} bsd_alias_match[] = { + { FS_BSDFFS, G_PART_ALIAS_FREEBSD_UFS }, + { FS_SWAP, G_PART_ALIAS_FREEBSD_SWAP }, + { FS_ZFS, G_PART_ALIAS_FREEBSD_ZFS }, + { FS_VINUM, G_PART_ALIAS_FREEBSD_VINUM }, + { FS_NANDFS, G_PART_ALIAS_FREEBSD_NANDFS }, + { FS_HAMMER, G_PART_ALIAS_DFBSD_HAMMER }, + { FS_HAMMER2, G_PART_ALIAS_DFBSD_HAMMER2 }, +}; + static int bsd_parse_type(const char *type, uint8_t *fstype) { @@ -118,6 +131,7 @@ bsd_parse_type(const char *type, uint8_t *fstype) const char *alias; char *endp; long lt; + int i; if (type[0] == '!') { lt = strtol(type + 1, &endp, 0); @@ -126,31 +140,14 @@ bsd_parse_type(const char *type, uint8_t *fstype) *fstype = (u_int)lt; return (0); } - alias = g_part_alias_name(G_PART_ALIAS_FREEBSD_NANDFS); - if (!strcasecmp(type, alias)) { - *fstype = FS_NANDFS; - return (0); + for (i = 0; + i < sizeof(bsd_alias_match) / sizeof(bsd_alias_match[0]); i++) { + alias = g_part_alias_name(bsd_alias_match[i].alias); + if (strcasecmp(type, alias) == 0) { + *fstype = bsd_alias_match[i].type; + return (0); + } } - alias = g_part_alias_name(G_PART_ALIAS_FREEBSD_SWAP); - if (!strcasecmp(type, alias)) { - *fstype = FS_SWAP; - return (0); - } - alias = g_part_alias_name(G_PART_ALIAS_FREEBSD_UFS); - if (!strcasecmp(type, alias)) { - *fstype = FS_BSDFFS; - return (0); - } - alias = g_part_alias_name(G_PART_ALIAS_FREEBSD_VINUM); - if (!strcasecmp(type, alias)) { - *fstype = FS_VINUM; - return (0); - } - alias = g_part_alias_name(G_PART_ALIAS_FREEBSD_ZFS); - if (!strcasecmp(type, alias)) { - *fstype = FS_ZFS; - return (0); - } return (EINVAL); } Index: head/sys/geom/part/g_part_gpt.c =================================================================== --- head/sys/geom/part/g_part_gpt.c (revision 267040) +++ head/sys/geom/part/g_part_gpt.c (working copy) @@ -181,6 +181,15 @@ static struct uuid gpt_uuid_netbsd_raid = GPT_ENT_ static struct uuid gpt_uuid_netbsd_swap = GPT_ENT_TYPE_NETBSD_SWAP; static struct uuid gpt_uuid_mbr = GPT_ENT_TYPE_MBR; static struct uuid gpt_uuid_unused = GPT_ENT_TYPE_UNUSED; +static struct uuid gpt_uuid_dfbsd_swap = GPT_ENT_TYPE_DRAGONFLY_SWAP; +static struct uuid gpt_uuid_dfbsd_ufs1 = GPT_ENT_TYPE_DRAGONFLY_UFS1; +static struct uuid gpt_uuid_dfbsd_vinum = GPT_ENT_TYPE_DRAGONFLY_VINUM; +static struct uuid gpt_uuid_dfbsd_ccd = GPT_ENT_TYPE_DRAGONFLY_CCD; +static struct uuid gpt_uuid_dfbsd_legacy = GPT_ENT_TYPE_DRAGONFLY_LEGACY; +static struct uuid gpt_uuid_dfbsd_hammer = GPT_ENT_TYPE_DRAGONFLY_HAMMER; +static struct uuid gpt_uuid_dfbsd_hammer2 = GPT_ENT_TYPE_DRAGONFLY_HAMMER2; +static struct uuid gpt_uuid_dfbsd_label32 = GPT_ENT_TYPE_DRAGONFLY_LABEL32; +static struct uuid gpt_uuid_dfbsd_label64 = GPT_ENT_TYPE_DRAGONFLY_LABEL64; static struct g_part_uuid_alias { struct uuid *uuid; @@ -222,6 +231,15 @@ static struct g_part_uuid_alias { { &gpt_uuid_netbsd_lfs, G_PART_ALIAS_NETBSD_LFS, 0 }, { &gpt_uuid_netbsd_raid, G_PART_ALIAS_NETBSD_RAID, 0 }, { &gpt_uuid_netbsd_swap, G_PART_ALIAS_NETBSD_SWAP, 0 }, + { &gpt_uuid_dfbsd_swap, G_PART_ALIAS_DFBSD_SWAP, 0 }, + { &gpt_uuid_dfbsd_ufs1, G_PART_ALIAS_DFBSD_UFS, 0 }, + { &gpt_uuid_dfbsd_vinum, G_PART_ALIAS_DFBSD_VINUM, 0 }, + { &gpt_uuid_dfbsd_ccd, G_PART_ALIAS_DFBSD_CCD, 0 }, + { &gpt_uuid_dfbsd_legacy, G_PART_ALIAS_DFBSD_LEGACY, 0 }, + { &gpt_uuid_dfbsd_hammer, G_PART_ALIAS_DFBSD_HAMMER, 0 }, + { &gpt_uuid_dfbsd_hammer2, G_PART_ALIAS_DFBSD_HAMMER2, 0 }, + { &gpt_uuid_dfbsd_label32, G_PART_ALIAS_DFBSD, 0xa5 }, + { &gpt_uuid_dfbsd_label64, G_PART_ALIAS_DFBSD64, 0xa5 }, { NULL, 0, 0 } }; --------------040101090305050600040806-- From owner-freebsd-geom@FreeBSD.ORG Mon Jun 9 08:00:11 2014 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 6C0CB63C for ; Mon, 9 Jun 2014 08:00:11 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5B06727DE for ; Mon, 9 Jun 2014 08:00:11 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.8/8.14.8) with ESMTP id s5980BNI056985 for ; Mon, 9 Jun 2014 09:00:11 +0100 (BST) (envelope-from bz-noreply@freebsd.org) Message-Id: <201406090800.s5980BNI056985@kenobi.freebsd.org> From: bz-noreply@freebsd.org To: freebsd-geom@FreeBSD.org Subject: [Bugzilla] Commit Needs MFC MIME-Version: 1.0 X-Bugzilla-Type: whine X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated Date: Mon, 09 Jun 2014 08:00:11 +0000 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 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 Jun 2014 08:00:11 -0000 Hi, You have a bug in the "Needs MFC" state which has not been touched in 7 or more days. This email serves as a reminder that you may want to MFC this bug or marked it as completed. In the event you have a longer MFC timeout you may update this bug with a comment and I won't remind you again for 7 days. This reminder is only sent on Mondays. Please file a bug about concerns you may have. This search was scheduled by eadler@FreeBSD.org. (2 bugs) Bug 158398: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=158398 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-geom@FreeBSD.org Status: Needs MFC Resolution: Summary: [headers] [patch] includes gratuitously Bug 176744: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=176744 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-geom@FreeBSD.org Status: Needs MFC Resolution: Summary: [geom] [patch] BIO_FLUSH not recorded by devstats From owner-freebsd-geom@FreeBSD.ORG Sat Jun 14 08:45:39 2014 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 7BFCA2D8 for ; Sat, 14 Jun 2014 08:45:39 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 63D032BF8 for ; Sat, 14 Jun 2014 08:45:39 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.8/8.14.8) with ESMTP id s5E8jd9F091872 for ; Sat, 14 Jun 2014 09:45:39 +0100 (BST) (envelope-from bz-noreply@freebsd.org) From: bz-noreply@freebsd.org To: freebsd-geom@FreeBSD.org Subject: [Bug 152609] [geli] geli onetime on gzero panics Date: Sat, 14 Jun 2014 08:45:39 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 8.2-PRERELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: kvedulv@kvedulv.de X-Bugzilla-Status: Issue Resolved X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: pjd@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status assigned_to resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jun 2014 08:45:39 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=152609 pjd@FreeBSD.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CONFIRMED |patched Assignee|freebsd-geom@FreeBSD.org |pjd@FreeBSD.org kvedulv@kvedulv.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs MFC |Issue Resolved Resolution|--- |FIXED --- Comment #2 from pjd@FreeBSD.org --- State Changed From-To: open->patched Fixed in HEAD, thanks. --- Comment #3 from pjd@FreeBSD.org --- Responsible Changed From-To: freebsd-geom->pjd I'll take this one. --- Comment #4 from kvedulv@kvedulv.de --- This is fixed in 9/10/CURRENT and not easy to fix on 8, so IMHO this can be closed. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-geom@FreeBSD.ORG Mon Jun 16 08:00:12 2014 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 1572E176 for ; Mon, 16 Jun 2014 08:00:12 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 033332316 for ; Mon, 16 Jun 2014 08:00:12 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.8/8.14.8) with ESMTP id s5G80BWf071785 for ; Mon, 16 Jun 2014 09:00:11 +0100 (BST) (envelope-from bz-noreply@freebsd.org) Message-Id: <201406160800.s5G80BWf071785@kenobi.freebsd.org> From: bz-noreply@freebsd.org To: freebsd-geom@FreeBSD.org Subject: [Bugzilla] Commit Needs MFC MIME-Version: 1.0 X-Bugzilla-Type: whine X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated Date: Mon, 16 Jun 2014 08:00:11 +0000 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 08:00:12 -0000 Hi, You have a bug in the "Needs MFC" state which has not been touched in 7 or more days. This email serves as a reminder that you may want to MFC this bug or marked it as completed. In the event you have a longer MFC timeout you may update this bug with a comment and I won't remind you again for 7 days. This reminder is only sent on Mondays. Please file a bug about concerns you may have. This search was scheduled by eadler@FreeBSD.org. (2 bugs) Bug 158398: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=158398 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-geom@FreeBSD.org Status: Needs MFC Resolution: Summary: [headers] [patch] includes gratuitously Bug 176744: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=176744 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-geom@FreeBSD.org Status: Needs MFC Resolution: Summary: [geom] [patch] BIO_FLUSH not recorded by devstats From owner-freebsd-geom@FreeBSD.ORG Mon Jun 23 08:00:12 2014 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 7B6B9706 for ; Mon, 23 Jun 2014 08:00:12 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 69CA02939 for ; Mon, 23 Jun 2014 08:00:12 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.8/8.14.8) with ESMTP id s5N80CES086961 for ; Mon, 23 Jun 2014 09:00:12 +0100 (BST) (envelope-from bugzilla-noreply@freebsd.org) Message-Id: <201406230800.s5N80CES086961@kenobi.freebsd.org> From: bugzilla-noreply@freebsd.org To: freebsd-geom@FreeBSD.org Subject: [Bugzilla] Commit Needs MFC MIME-Version: 1.0 X-Bugzilla-Type: whine X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated Date: Mon, 23 Jun 2014 08:00:12 +0000 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 08:00:12 -0000 Hi, You have a bug in the "Needs MFC" state which has not been touched in 7 or more days. This email serves as a reminder that you may want to MFC this bug or marked it as completed. In the event you have a longer MFC timeout you may update this bug with a comment and I won't remind you again for 7 days. This reminder is only sent on Mondays. Please file a bug about concerns you may have. This search was scheduled by eadler@FreeBSD.org. (2 bugs) Bug 158398: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=158398 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-geom@FreeBSD.org Status: Needs MFC Resolution: Summary: [headers] [patch] includes gratuitously Bug 176744: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=176744 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-geom@FreeBSD.org Status: Needs MFC Resolution: Summary: [geom] [patch] BIO_FLUSH not recorded by devstats From owner-freebsd-geom@FreeBSD.ORG Thu Jun 26 11:53:02 2014 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 A131A8AF for ; Thu, 26 Jun 2014 11:53:02 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 87E4A2FCC for ; Thu, 26 Jun 2014 11:53:02 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.8/8.14.8) with ESMTP id s5QBr2k6053138 for ; Thu, 26 Jun 2014 12:53:02 +0100 (BST) (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-geom@FreeBSD.org Subject: [Bug 167562] [geli] geli cannot use gpt labels in loader.conf Date: Thu, 26 Jun 2014 11:53:02 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 8.3-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: vsjcfm@gmail.com X-Bugzilla-Status: Issue Resolved X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: pjd@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status assigned_to resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 11:53:02 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=167562 pjd@FreeBSD.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CONFIRMED |RESOLVED Assignee|freebsd-geom@FreeBSD.org |pjd@FreeBSD.org vsjcfm@gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Discussion |Issue Resolved Resolution|--- |Works As Intended --- Comment #5 from pjd@FreeBSD.org --- State Changed From-To: open->feedback You should be able to use any variable name prefix for the keyfiles, you just have to have all three variables: _load="YES" _type=":geli_keyfile0" _name="/path/to/your/keyfile" Those three tells the loader to load the given file. GELI uses what's in _type to find keyfiles. If you have gpt/foo provider you have to be sure to put it into _type's value, but you can use any prefix you like, eg. doesntmatter_load="YES" doesntmatter_type="gpt/foo:geli_keyfile0" doesntmatter_name="/boot/keys/key" --- Comment #6 from pjd@FreeBSD.org --- Responsible Changed From-To: freebsd-geom->pjd I'll take this one. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-geom@FreeBSD.ORG Fri Jun 27 00:06:25 2014 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 5B0AC28C; Fri, 27 Jun 2014 00:06:25 +0000 (UTC) Received: from mail-ve0-x234.google.com (mail-ve0-x234.google.com [IPv6:2607:f8b0:400c:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E6A702788; Fri, 27 Jun 2014 00:06:24 +0000 (UTC) Received: by mail-ve0-f180.google.com with SMTP id jw12so4559214veb.11 for ; Thu, 26 Jun 2014 17:06:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gjX70HQmike0Uwf48vLilPNrbQPCd+rwWKbDLMdvWAg=; b=o/Yu9bLfqgXjwxhtwanZoWFkdIqj62rlW11WPgJ9vCMlyS+/0hMcFmw55O1nz5Xsy/ p4l1Kgvmuf0YfzsYZeV/tuepXUwK0+n5ByrX6nfKcRln2hfrF25cc/jr4PSZd1blgaBa B6PgWitZNGfl1xeHcxygHtJewHZv7Lk6HduK9UTmET6O83Nw81QAdsTOE+Ql4QPZGPys /BUVXDvQfu9ku/OWJxDEWY1IL2OXrH7/E+OzeOZk91u2Nk9pSZGyJE5e33DCSkKid+ln pwS5JI5DpI2REYXsstHjeAJ1JFmuWwv4Q8OssC37CA/Xz8yN9JxuQ0mqcy4T1aqo7kla FW1g== MIME-Version: 1.0 X-Received: by 10.52.29.236 with SMTP id n12mr13934395vdh.38.1403827583825; Thu, 26 Jun 2014 17:06:23 -0700 (PDT) Received: by 10.221.65.198 with HTTP; Thu, 26 Jun 2014 17:06:23 -0700 (PDT) In-Reply-To: References: <53A25FC7.5040105@connotech.com> <53A2E91B.8060802@av8n.com> <20140619134829.5d7bd14a@jabberwock.cb.piermont.com> <1403207567.1908.23.camel@excessive.dsl.static.sonic.net> <20140619170644.34e6ddf0@jabberwock.cb.piermont.com> <20140620090421.0cb08f1a@jabberwock.cb.piermont.com> Date: Thu, 26 Jun 2014 20:06:23 -0400 Message-ID: Subject: Fwd: [Cryptography] hardware vs software FDE (was Re: Shredding a file on a flash-based file system?) From: grarpamp To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=UTF-8 Cc: freebsd-security@freebsd.org, freebsd-geom@freebsd.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 00:06:25 -0000 Links regarding fde implementations, relevant re geli / gbde. ---------- Forwarded message ---------- From: Darren Lasko Date: Thu, Jun 26, 2014 at 6:03 PM Subject: Re: [Cryptography] hardware vs software FDE (was Re: Shredding a file on a flash-based file system?) To: "Perry E. Metzger" Cc: cryptography@metzdowd.com Hi Perry, Sorry for the very slow reply; I was away on vacation. On Fri, Jun 20, 2014 at 9:04 AM, Perry E. Metzger wrote: > > On Thu, 19 Jun 2014 23:37:04 -0400 Darren Lasko > wrote: > > On Thu, Jun 19, 2014 at 5:06 PM, Perry E. Metzger > > wrote: > > > > > It is different in a vital respect -- in the software > > > implementation, you can more or less check that everything is > > > working as expected, and you don't have to trust that the drive > > > isn't sabotaging you. That's quite different -- vitally so, I > > > think. > [...] > > However, to your point that "in the software implementation, you > > can more or less check that everything is working as expected," > > this only holds true if it's open-source (and as we have found > > recently, this is still no guarantee against nasty security > > "flaws"), or if you're willing to reverse-engineer a closed-source > > product (which you could also do with a hardware-based product, > > though likely at a greater expense). > > No. You are missing a very vital point. > I really don't think I missed your point. I even acknowledged that point in my previous post. My counter-point is merely that the actual media encryption part, while vitally important, is only a small part of the overall FDE solution. The other parts of the solution are equally important, much harder to get right, and not readily verifiable in *either* a hardware solution or a closed-source software solution. I would argue that if you don't trust hard drives with built-in encryption, then you also shouldn't trust closed-source software drive encryption products (and maybe you don't). In fact, even the actual media encryption part is probably much harder to verify in a closed-source software implementation than you might be thinking... > If the sectors on the drive are encrypted with some particular > algorithm using some particular key, I can check, in a software only > solution, that the sectors are indeed encrypted in that key using > that algorithm. Getting "that key" out of a closed-source software FDE product will require reverse-engineering the product or employing something like the techniques used in the Princeton "cold boot attack". And once you have the key, you also need to know the encryption algorithm and cipher mode being used (which is usually specified in the product documentation) *plus* the product's algorithm for generating IVs/tweaks for the cipher mode (probably only discoverable by reverse-engineering, since I've never seen a closed-source implementation give this level of detail in its documentation). This is why I said in my previous post, "you can take a look at the ciphertext and verify that you see random-looking bits, and maybe verify through experimentation that it's not using a poor choice of cipher mode like ECB." Anything more than that will require you to dive deep into the inner workings of the product. [...] > > It is actually much worse than that since the hardware implementation > could be doing things like stashing keys in hidden sectors, but one > need not go so far as to worry about that because even the most basic > audit is impossible. > Software-only products are capable of implementing equivalent levels of malfeasance, for example by obfuscating the plaintext media encryption key and stashing it in the area of the drive they reserve for their pre-boot code and metadata. They could even encrypt the media key using a public key to which the developers (or their "partners") hold the private key. > > > While it's true that even with a closed-source product you can take > > a look at the ciphertext and verify that you see random-looking > > bits, > > No, if they say "this is using AES-256 GCM" I can do more than that. > Again, not without the key. > > If your closed source vendor is not telling you what algorithm and > mode they are using, they are of course also doing something > unacceptable and should be excluded from your purchases. It is > acceptable (though not even remotely optimal) if the encryption > implementation is closed source, but it is utterly unacceptable if > its method of operation is not fully disclosed. > Your original comment was about "checking/verifying", not "disclosure". If you look at the datasheets for self-encrypting drives from just about any respectable manufacturer, they disclose the encryption algorithm/mode: http://www.intel.com/content/dam/www/public/us/en/documents/product-specifications/ssd-pro-1500-series-sata-specification.pdf (XTS-AES-256, FIPS 197 certified) http://www.micron.com/-/media/documents/products/data%20sheet/ssd/m550_2_5_ssd.pdf (AES-256 CBC) Seagate has FIPS 140-2 certification on various models, so even more information can be gleaned from their public security policies (e.g. http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp2119.pdf) and CAVP certifications (e.g. AES cert #1974 for XTS, CBC, and EBC) Just to reiterate, checking that the actual media encryption is implemented correctly in a closed-source software product is not a straightforward task (even though you can easily "see" the ciphertext). We haven't even discussed how you would verify the other (and trickier, IMO) bits of the product, such as entropy source & RNG for generating media keys, how passwords are "strengthened", how the media key(s) are cryptographically protected with the "strengthened" authentication credentials, how the "key blobs" are sanitized from the drive (especially on flash-based storage devices), etc. I think it's fair to say that hardware-based FDE solutions aren't any more "untrustworthy" than their closed-source software counterparts, and I think one could even argue that open-sourced isn't a silver bullet (http://underhanded.xcott.com/). Even in software implementations, there are a variety of components that are just as difficult to verify everything is working as expected; and as such a high level of faith is required that the software isn't sabotaging you. Regards, Darren _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography From owner-freebsd-geom@FreeBSD.ORG Mon Jun 30 08:00:12 2014 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 723A9800 for ; Mon, 30 Jun 2014 08:00:12 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 607C12921 for ; Mon, 30 Jun 2014 08:00:12 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.8/8.14.8) with ESMTP id s5U80Ca3003859 for ; Mon, 30 Jun 2014 09:00:12 +0100 (BST) (envelope-from bugzilla-noreply@freebsd.org) Message-Id: <201406300800.s5U80Ca3003859@kenobi.freebsd.org> From: bugzilla-noreply@freebsd.org To: freebsd-geom@FreeBSD.org Subject: [Bugzilla] Commit Needs MFC MIME-Version: 1.0 X-Bugzilla-Type: whine X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated Date: Mon, 30 Jun 2014 08:00:12 +0000 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 08:00:12 -0000 Hi, You have a bug in the "Needs MFC" state which has not been touched in 7 or more days. This email serves as a reminder that you may want to MFC this bug or marked it as completed. In the event you have a longer MFC timeout you may update this bug with a comment and I won't remind you again for 7 days. This reminder is only sent on Mondays. Please file a bug about concerns you may have. This search was scheduled by eadler@FreeBSD.org. (2 bugs) Bug 158398: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=158398 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-geom@FreeBSD.org Status: Needs MFC Resolution: Summary: [headers] [patch] includes gratuitously Bug 176744: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=176744 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-geom@FreeBSD.org Status: Needs MFC Resolution: Summary: [geom] [patch] BIO_FLUSH not recorded by devstats From owner-freebsd-geom@FreeBSD.ORG Thu Jul 3 14:42:54 2014 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 177CA79C for ; Thu, 3 Jul 2014 14:42:54 +0000 (UTC) Received: from host.volga-rast.ru (host.volga-rast.ru [213.234.29.165]) by mx1.freebsd.org (Postfix) with ESMTP id 7CE652068 for ; Thu, 3 Jul 2014 14:42:52 +0000 (UTC) Received: by host.volga-rast.ru (Postfix, from userid 554) id CE49C1EBBA40; Thu, 3 Jul 2014 18:42:41 +0400 (VOLT) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on host.volga-rast.ru X-Spam-Level: X-Spam-Status: No, score=-92.6 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, FH_DATE_PAST_20XX,FUZZY_MONEY,HTML_MESSAGE,SARE_OBFU_PART_OFF, SARE_OBFU_PART_ONE,USER_IN_WHITELIST autolearn=no version=3.2.5 Received: from Reception (localhost.localdomain [127.0.0.1]) by host.volga-rast.ru (Postfix) with ESMTP id BA28F1EBBA65 for ; Thu, 3 Jul 2014 18:42:40 +0400 (VOLT) From: "\"Wal-mart" Subject: Work.. To: freebsd-geom@freebsd.org MIME-Version: 1.0 Reply-To: tm6x46jtqhl12i6@jetable.org Date: Thu, 3 Jul 2014 09:42:27 -0500 Message-Id: <20140703144240.BA28F1EBBA65@host.volga-rast.ru> Content-Type: text/plain Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 14:42:54 -0000 - This mail is in HTML. Some elements may be ommited in plain text. - "Welcome to Wal-Mart, You have been selected as a Sh0p-Detective For s= hopping task in your city, We pay $~200 being a Sh0p-Detective. Your e= mployment Packet will include M0ney for the shopping. We want you to participate because it's Fun & rewarding. We will mail your employment training materials when you Provide the F= ollowing details : "Full~Name":_ _ _ _ _ _ _ _ _ _ "ADDRE55":_ _ _ _ _ _ _ _ _ _ Clty-State-Z1P:_ _ _ _ _ _ _ _ _ _ (M0bile and H0me) #:_ _ _ _ _ _ _ _ _ _ You work and shop together for pleasure 2-3 hours twice in a week . We wait your good response, Thank You! Regards, 0fficial Recruiters @Detectlve_Sh0pper_Network From owner-freebsd-geom@FreeBSD.ORG Mon Jul 7 08:00:12 2014 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 0B151DF8 for ; Mon, 7 Jul 2014 08:00:12 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ED69F25A1 for ; Mon, 7 Jul 2014 08:00:11 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.8/8.14.8) with ESMTP id s6780B6U030227 for ; Mon, 7 Jul 2014 09:00:11 +0100 (BST) (envelope-from bugzilla-noreply@freebsd.org) Message-Id: <201407070800.s6780B6U030227@kenobi.freebsd.org> From: bugzilla-noreply@freebsd.org To: freebsd-geom@FreeBSD.org Subject: [Bugzilla] Commit Needs MFC MIME-Version: 1.0 X-Bugzilla-Type: whine X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated Date: Mon, 07 Jul 2014 08:00:11 +0000 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 08:00:12 -0000 Hi, You have a bug in the "Needs MFC" state which has not been touched in 7 or more days. This email serves as a reminder that you may want to MFC this bug or marked it as completed. In the event you have a longer MFC timeout you may update this bug with a comment and I won't remind you again for 7 days. This reminder is only sent on Mondays. Please file a bug about concerns you may have. This search was scheduled by eadler@FreeBSD.org. (2 bugs) Bug 158398: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=158398 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-geom@FreeBSD.org Status: Needs MFC Resolution: Summary: [headers] [patch] includes gratuitously Bug 176744: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=176744 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-geom@FreeBSD.org Status: Needs MFC Resolution: Summary: [geom] [patch] BIO_FLUSH not recorded by devstats From owner-freebsd-geom@FreeBSD.ORG Tue Jul 8 15:30:26 2014 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 5AB481A6 for ; Tue, 8 Jul 2014 15:30:26 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 41FF32FF4 for ; Tue, 8 Jul 2014 15:30:26 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.8/8.14.8) with ESMTP id s68FUQBg088478 for ; Tue, 8 Jul 2014 16:30:26 +0100 (BST) (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-geom@FreeBSD.org Subject: [Bug 158398] [headers] [patch] includes gratuitously Date: Tue, 08 Jul 2014 15:30:26 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: brooks@FreeBSD.org X-Bugzilla-Status: Issue Resolved X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-geom@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status cc resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 15:30:26 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=158398 Brooks Davis changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs MFC |Issue Resolved CC| |brooks@FreeBSD.org Resolution|--- |FIXED --- Comment #7 from Brooks Davis --- Merged to 8 in r268415. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-geom@FreeBSD.ORG Tue Jul 8 15:30:31 2014 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 53F141D5 for ; Tue, 8 Jul 2014 15:30:31 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3B42A2FF7 for ; Tue, 8 Jul 2014 15:30:31 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.8/8.14.8) with ESMTP id s68FUVO6090464 for ; Tue, 8 Jul 2014 16:30:31 +0100 (BST) (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-geom@FreeBSD.org Subject: [Bug 158398] [headers] [patch] includes gratuitously Date: Tue, 08 Jul 2014 15:30:31 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: Issue Resolved X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-geom@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 15:30:31 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=158398 --- Comment #8 from commit-hook@freebsd.org --- A commit references this bug: Author: brooks Date: Tue Jul 8 15:30:05 UTC 2014 New revision: 268415 URL: http://svnweb.freebsd.org/changeset/base/268415 Log: MFC r223930: Remove include of sys/sbuf.h from geom/geom.h. sbuf support is not always required for geom/geom.h users, and no need to depend from it. PR: 158398 Changes: _U stable/8/sys/ _U stable/8/sys/geom/ stable/8/sys/geom/geom.h -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-geom@FreeBSD.ORG Wed Jul 9 15:53:20 2014 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 448EFC4F for ; Wed, 9 Jul 2014 15:53:20 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2BEB42CF7 for ; Wed, 9 Jul 2014 15:53:20 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.8/8.14.8) with ESMTP id s69FrKAO058437 for ; Wed, 9 Jul 2014 15:53:20 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-geom@FreeBSD.org Subject: [Bug 158398] [headers] [patch] includes gratuitously Date: Wed, 09 Jul 2014 15:53:20 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: brooks@FreeBSD.org X-Bugzilla-Status: Issue Resolved X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-geom@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jul 2014 15:53:20 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=158398 --- Comment #9 from Brooks Davis --- Reverted in 268415 due to breakage caused by botched testing and poor documentation in this bug. ae@ reports he did not intend to MFC this change. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-geom@FreeBSD.ORG Mon Jul 14 08:00:12 2014 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 CEEE6DCA for ; Mon, 14 Jul 2014 08:00:12 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A17BA2A56 for ; Mon, 14 Jul 2014 08:00:12 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.8/8.14.8) with ESMTP id s6E80CgE043297 for ; Mon, 14 Jul 2014 08:00:12 GMT (envelope-from bugzilla-noreply@freebsd.org) Message-Id: <201407140800.s6E80CgE043297@kenobi.freebsd.org> From: bugzilla-noreply@freebsd.org To: freebsd-geom@FreeBSD.org Subject: [Bugzilla] Commit Needs MFC MIME-Version: 1.0 X-Bugzilla-Type: whine X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated Date: Mon, 14 Jul 2014 08:00:12 +0000 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 08:00:12 -0000 Hi, You have a bug in the "Needs MFC" state which has not been touched in 7 or more days. This email serves as a reminder that you may want to MFC this bug or marked it as completed. In the event you have a longer MFC timeout you may update this bug with a comment and I won't remind you again for 7 days. This reminder is only sent on Mondays. Please file a bug about concerns you may have. This search was scheduled by eadler@FreeBSD.org. (1 bugs) Bug 176744: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=176744 Severity: Affects Only Me Priority: Normal Hardware: Any Assignee: freebsd-geom@FreeBSD.org Status: Needs MFC Resolution: Summary: [geom] [patch] BIO_FLUSH not recorded by devstats From owner-freebsd-geom@FreeBSD.ORG Tue Jul 15 18:52:50 2014 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 D8D4E13D for ; Tue, 15 Jul 2014 18:52:50 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C0B0027E2 for ; Tue, 15 Jul 2014 18:52:50 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.8/8.14.8) with ESMTP id s6FIqo6d014552 for ; Tue, 15 Jul 2014 18:52:50 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-geom@FreeBSD.org Subject: [Bug 176744] [geom] [patch] BIO_FLUSH not recorded by devstats Date: Tue, 15 Jul 2014 18:52:50 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: brooks@FreeBSD.org X-Bugzilla-Status: Needs MFC X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: mav@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 18:52:50 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=176744 Brooks Davis changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |brooks@FreeBSD.org Assignee|freebsd-geom@FreeBSD.org |mav@FreeBSD.org --- Comment #4 from Brooks Davis --- Assign to mav@ so he can decide to MFC or not as appropriate. -- You are receiving this mail because: You are the assignee for the bug.