From owner-freebsd-geom@FreeBSD.ORG Mon Nov 8 11:06:57 2010 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F4111065672 for ; Mon, 8 Nov 2010 11:06:57 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6C04D8FC0C for ; Mon, 8 Nov 2010 11:06:57 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oA8B6vqf088092 for ; Mon, 8 Nov 2010 11:06:57 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oA8B6uOo088090 for freebsd-geom@FreeBSD.org; Mon, 8 Nov 2010 11:06:56 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 8 Nov 2010 11:06:56 GMT Message-Id: <201011081106.oA8B6uOo088090@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-geom@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-geom@FreeBSD.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2010 11:06:57 -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 bin/151252 geom [geom] libgeom(3) manual page contains broken link in 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/147852 geom [geom] [panic] graid3 panic: wrong offset 16384 for se o kern/147851 geom [geom] [panic] graid3 panic: g_read_data: invalid leng o kern/147667 geom [gmirror] Booting with one component of a gmirror, the o kern/147664 geom [geom] [patch] Add the ability to create linux and fat 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/144962 geom [geom] panic when accessing GPT disk with a large numb o kern/144905 geom [geom][geom_part] panic in gpart_ctlreq when unpluggin o kern/143455 geom gstripe(8) in RELENG_8 (31st Jan 2010) broken o kern/142563 geom [geom] [hang] ioctl freeze in zpool f kern/142365 geom [geom] FreeBSD RAID1 (gmirror) is much slower than Lin o kern/141740 geom [geom] gjournal(8): g_journal_destroy concurrent error s kern/141235 geom [geom_part] 8.0 no longer provides /dev entries for al o kern/140352 geom [geom] gjournal + glabel not working o kern/135898 geom [geom] Severe filesystem corruption - large files or l o kern/134922 geom [gmirror] [panic] kernel panic when use fdisk on disk o kern/134113 geom [geli] Problem setting secondary GELI key o kern/134044 geom [geom] gmirror(8) overwrites fs with stale data from r 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 kern/132273 geom glabel(8): [patch] failing on journaled partition f kern/132242 geom [gmirror] gmirror.ko fails to fully initialize o kern/131353 geom [geom] gjournal(8) kernel lock p docs/130548 geom [patch] gjournal(8) man page is missing sysctls o kern/129674 geom [geom] gjournal root did not mount on boot o kern/129645 geom gjournal(8): GEOM_JOURNAL causes system to fail to boo o kern/129245 geom [geom] gcache is more suitable for suffix based provid f kern/128276 geom [gmirror] machine lock up when gmirror module is used o kern/127420 geom [geom] [gjournal] [panic] Journal overflow on gmirrore o kern/124973 geom [gjournal] [patch] boot order affects geom_journal con o kern/124969 geom gvinum(8): gvinum raid5 plex does not detect missing s o kern/123962 geom [panic] [gjournal] gjournal (455Gb data, 8Gb journal), o kern/123122 geom [geom] GEOM / gjournal kernel lock o kern/122738 geom [geom] gmirror list "losts consumers" after gmirror de f kern/122415 geom [geom] UFS labels are being constantly created and rem o kern/122067 geom [geom] [panic] Geom crashed during boot o kern/121364 geom [gmirror] Removing all providers create a "zombie" mir o kern/120091 geom [geom] [geli] [gjournal] geli does not prompt for pass o kern/115856 geom [geli] ZFS thought it was degraded when it should have o kern/115547 geom [geom] [patch] [request] let GEOM Eli get password fro o kern/114532 geom [geom] GEOM_MIRROR shows up in kldstat even if compile f kern/113957 geom [gmirror] gmirror is intermittently reporting a degrad o kern/113837 geom [geom] unable to access 1024 sector size storage o kern/113419 geom [geom] geom fox multipathing not failing back p bin/110705 geom gmirror(8) control utility does not exit with correct 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/88601 geom [geli] geli cause kernel panic under heavy disk usage o kern/87544 geom [gbde] mmaping large files on a gbde filesystem deadlo 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. s kern/73177 geom kldload geom_* causes panic due to memory exhaustion 63 problems total. From owner-freebsd-geom@FreeBSD.ORG Mon Nov 8 21:59:03 2010 Return-Path: Delivered-To: freebsd-geom@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DECE310656B0; Mon, 8 Nov 2010 21:59:03 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B4AD38FC1B; Mon, 8 Nov 2010 21:59:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oA8Lx3oj064784; Mon, 8 Nov 2010 21:59:03 GMT (envelope-from gavin@freefall.freebsd.org) Received: (from gavin@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oA8Lx3MF064780; Mon, 8 Nov 2010 21:59:03 GMT (envelope-from gavin) Date: Mon, 8 Nov 2010 21:59:03 GMT Message-Id: <201011082159.oA8Lx3MF064780@freefall.freebsd.org> To: tom@tomjudge.com, gavin@FreeBSD.org, freebsd-geom@FreeBSD.org From: gavin@FreeBSD.org Cc: Subject: Re: bin/110705: gmirror(8) control utility does not exit with correct exit status X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2010 21:59:04 -0000 Synopsis: gmirror(8) control utility does not exit with correct exit status State-Changed-From-To: patched->closed State-Changed-By: gavin State-Changed-When: Mon Nov 8 21:56:49 UTC 2010 State-Changed-Why: This has been fixed in 7+, and with 6-STABLE going EOL next month, the submitter is happy for this to be closed. http://www.freebsd.org/cgi/query-pr.cgi?pr=110705 From owner-freebsd-geom@FreeBSD.ORG Wed Nov 10 16:44:26 2010 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1436C10656AB for ; Wed, 10 Nov 2010 16:44:26 +0000 (UTC) (envelope-from bsemene@cyanide-studio.com) Received: from relay.cyanide-studio.com (relay.cyanide-studio.com [91.121.7.6]) by mx1.freebsd.org (Postfix) with ESMTP id C92A98FC2B for ; Wed, 10 Nov 2010 16:44:25 +0000 (UTC) Received: from mail.cyanide-studio.com (unknown [62.73.7.64]) by relay.cyanide-studio.com (Postfix) with ESMTP id 9BE15965AFE for ; Wed, 10 Nov 2010 16:27:18 +0000 (UTC) Received: from localhost (unknown [10.1.8.14]) by mail.cyanide-studio.com (Postfix) with ESMTP id C85DE17BF487 for ; Wed, 10 Nov 2010 17:26:56 +0100 (CET) Received: from mail.cyanide-studio.com ([10.1.8.3]) by localhost (mailguard.cyanide-studio.com [10.1.8.14]) (amavisd-maia, port 10024) with ESMTP id 89841-04 for ; Wed, 10 Nov 2010 17:26:56 +0100 (CET) Received: from [10.1.8.96] (unknown [10.1.8.96]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: bsemene@cyanide-studio.com) by mail.cyanide-studio.com (Postfix) with ESMTP id A02F817BF433 for ; Wed, 10 Nov 2010 17:26:56 +0100 (CET) Message-ID: <4CDAC7E2.5050309@cyanide-studio.com> Date: Wed, 10 Nov 2010 17:27:14 +0100 From: Bastien Semene User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: freebsd-geom@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Newbie RAID 0 question X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 16:44:26 -0000 Hi, Is there a way to add a component to an existing RAID 0 array ? I found nothing explicit on the man page nor FBSD online doc or Google. Thanks, From owner-freebsd-geom@FreeBSD.ORG Wed Nov 10 18:29:24 2010 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E001106564A for ; Wed, 10 Nov 2010 18:29:24 +0000 (UTC) (envelope-from modulok@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 986A38FC2B for ; Wed, 10 Nov 2010 18:29:23 +0000 (UTC) Received: by wwi18 with SMTP id 18so94527wwi.31 for ; Wed, 10 Nov 2010 10:29:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=WM+pAQdkV1RI2wlisjmiWbPCUiTH3Wf9t/F3E/SmI00=; b=Yxfmyv8PF4tz8zztHUVTPPlR958XAXamIRdsRnJfX9PYJTWjOBJbnOqNmeGrCr2zwb DkwijCrzjTDrxVsB5ktEWqVEnMRAslfKBmFn+Qx2o8yQn7ENVZlrYQJowE0EypahIBKl GbfjOClt+AccgAXjTAcZbYiV1OllquHBh3Agw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=neWpG9PQS5H4wGcczy9GmbZgjqnnCiW2oCH2U7VsdLsb1IBqSMnD9HMUNvZbAXhvJe VK8glX52paz7hP6yBoWQzp6jGg9M3mnwkvoY63sWaIWR/nQ4eFaIHP0w9uf7rabqfD8x DRtJ/WqamK2GziwPHrIo03qeTCXrmPBAj/VdE= MIME-Version: 1.0 Received: by 10.227.72.196 with SMTP id n4mr8651636wbj.153.1289411871585; Wed, 10 Nov 2010 09:57:51 -0800 (PST) Received: by 10.227.138.12 with HTTP; Wed, 10 Nov 2010 09:57:51 -0800 (PST) In-Reply-To: <4CDAC7E2.5050309@cyanide-studio.com> References: <4CDAC7E2.5050309@cyanide-studio.com> Date: Wed, 10 Nov 2010 10:57:51 -0700 Message-ID: From: Modulok To: Bastien Semene Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-geom@freebsd.org Subject: Re: Newbie RAID 0 question X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 18:29:24 -0000 > Is there a way to add a component to an existing RAID 0 array ? Probably not. I say "probably" as a personal disclaimer, but I'm pretty confident the answer is a resounding 'no'. RAID 0 is a pure striped arrangement with the goal of increasing throughput at the cost of reliability. If any single disk fails, all data is gone. The reason for this, is that data is literally 'striped' across the two, (or more) disks in alternating blocks (or whatever stripe size you configure). You can't simply append a third disk to the array and still have alternating blocks between the three disks. All data would need to be shuffled around to be re-distributed across all disks in the array. I know of no software which can do this on a functioning array. (Not saying it's impossible, just saying 'as far as I know'.) You must dump all data to a backup server, create a new array, and copy the data back over. Essentially, you have to reconstruct the array from scratch. -Modulok- From owner-freebsd-geom@FreeBSD.ORG Wed Nov 10 18:40:04 2010 Return-Path: Delivered-To: freebsd-geom@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0C2F1065670 for ; Wed, 10 Nov 2010 18:40:03 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 651F18FC12 for ; Wed, 10 Nov 2010 18:40:03 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id oAAIdTLn062693; Wed, 10 Nov 2010 19:39:45 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id oAAIdTpo062692; Wed, 10 Nov 2010 19:39:29 +0100 (CET) (envelope-from olli) Date: Wed, 10 Nov 2010 19:39:29 +0100 (CET) Message-Id: <201011101839.oAAIdTpo062692@lurza.secnetix.de> From: Oliver Fromme To: freebsd-geom@FreeBSD.ORG, bsemene@cyanide-studio.com In-Reply-To: <4CDAC7E2.5050309@cyanide-studio.com> X-Newsgroups: list.freebsd-geom User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.5 (lurza.secnetix.de [127.0.0.1]); Wed, 10 Nov 2010 19:39:45 +0100 (CET) Cc: Subject: Re: Newbie RAID 0 question X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-geom@FreeBSD.ORG, bsemene@cyanide-studio.com List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 18:40:04 -0000 Bastien Semene wrote: > Is there a way to add a component to an existing RAID 0 array ? There are several ways in FreeBSD to create a RAID-0 array. Since you're posting to freebsd-geom, I assume that you are talking about gstripe(8). If you mean something else, then please be more specific. As far as I know, you cannot directly add a new provider to an existing gstripe volume. This would be technically difficult, because the stripes are spread evenly across the existing providers. Adding a new provider would require changing the stripe distribution, which means rewriting large parts of the existing providers. However, you can add a new provider to a gconcat(8) volume (there's even an example for that in the manual page). gconcat simply concatenates its providers without striping (thus it's not RAID-0). So, basically you can add space to an existing gstripe by creating another gstripe containing the new disks, and then combine the two gstripes with gconcat. For example: gstripe1 <-- /dev/ad0 + /dev/ad1 (old) gstripe2 <-- /dev/ad2 + /dev/ad3 (new) gconcat <-- gstripe1 + gstripe2 Depending on your partition layout, you will have to modify the partition table (BSD label, GPT) to increase the size of the partition, and then use growfs(8) to resize the file system contained in the partition. Of course, you could also dump(8) your data (or copy it elsewhere), then recreate everything from scratch, and finally restore(8) your data (or copy it back). And of course you should have a good backup in either case, no matter which approach you choose. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd C++: "an octopus made by nailing extra legs onto a dog" -- Steve Taylor, 1998 From owner-freebsd-geom@FreeBSD.ORG Wed Nov 10 21:12:17 2010 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34C8510656A7 for ; Wed, 10 Nov 2010 21:12:17 +0000 (UTC) (envelope-from osharoiko@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id E3BDB8FC13 for ; Wed, 10 Nov 2010 21:12:16 +0000 (UTC) Received: by gxk9 with SMTP id 9so783283gxk.13 for ; Wed, 10 Nov 2010 13:12:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=/Zy2zqN2XP/B8o8MTMphaH6WZDFIyCHGYIJNEc9TrMY=; b=IIKUkaS0T4qgNC0Dq/nfyqAkAu817U34hVxnfjV2g+YUNXdwEySxXrvqagby3Xb41X HQE6JU1QSUkOnXI8YJ14+GAKDZSx4oRw9KHALbxnWxmA+iuZ7jO8S+YetwU94Yo6z1fW sV5PiitUzCFIlsbQUOx6AYoK7aPKC4fsMdaoA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=fXTNZ4gwxtSz9zpl/u4kSZ2PTic6Dl37L/mw+VvNaGvbiHtpO31+oImwZpk3eaqTxA 7h4KrHqMQEsxv/lKagVJcM/2qTb7TKXjHfxxL3Jn+Ak0ESy82fZyWPq0viop9+9CjHCw ZUYkrU9s005PT8CSxqhaLRURJ+20lM11e3dGY= MIME-Version: 1.0 Received: by 10.42.226.132 with SMTP id iw4mr2011icb.351.1289421690023; Wed, 10 Nov 2010 12:41:30 -0800 (PST) Received: by 10.229.29.12 with HTTP; Wed, 10 Nov 2010 12:41:29 -0800 (PST) Date: Wed, 10 Nov 2010 23:41:29 +0300 Message-ID: From: Oleg Sharoyko To: mjacob@freebsd.org, freebsd-geom@freebsd.org Content-Type: multipart/mixed; boundary=20cf30549dc5ccaf1a0494b8e13d Cc: Subject: [patch] [geom_multipath] detached device used as an active path X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 21:12:17 -0000 --20cf30549dc5ccaf1a0494b8e13d Content-Type: text/plain; charset=UTF-8 Hi Matthew, Please take a look at the patch I'm attaching to this mail. It fixes couple of issues with cp->active being left pointing to detached device. I have as well tried to remove code duplication a bit by using g_multipath_rotate() in g_mpd() and g_multipath_done_error() instead of identical loops. One thing which I'm not 100% sure about is this part (this is within g_multipath_access()): @@ -258,7 +268,7 @@ LIST_FOREACH(cp, &gp->consumer, consumer) { error = g_access(cp, dr, dw, de); - if (error) { + if (error && error != ENXIO) { badcp = cp; goto fail; } This change fixes undesired behavior in the following case: While running while true; do echo date dd if=/dev/multipath/test of=/dev/null bs=512 count=1 sleep 1 done disconnect currently active path of /dev/multipath/test. Without "&& error != ENXIO" I have exactly one failed dd. Whith it - none of dd fails. Shouldn't the overall logic of g_multipath_access() be as follows: try to do what we're asked to do while there are at least one available path, and remove from g_multipath any path for which g_access() call has failed? I would suppose that multipath device should try to work as long as there is at least one workable path, and any path which has failed (no matter if it was a physical failure or, f.e. ENOMEM in device driver) should be detached from multipath device. -- Oleg Sharoyko --20cf30549dc5ccaf1a0494b8e13d Content-Type: text/x-patch; charset=US-ASCII; name="g_multipath.diff" Content-Disposition: attachment; filename="g_multipath.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ggcnew4q0 SW5kZXg6IHN5cy9nZW9tL211bHRpcGF0aC9nX211bHRpcGF0aC5jCj09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5 cy9nZW9tL211bHRpcGF0aC9nX211bHRpcGF0aC5jCShyZXZpc2lvbiAyMTUwOTgpCisrKyBzeXMv Z2VvbS9tdWx0aXBhdGgvZ19tdWx0aXBhdGguYwkod29ya2luZyBjb3B5KQpAQCAtNzEsNyArNzEs NyBAQAogZ19tdWx0aXBhdGhfZGVzdHJveV9nZW9tKHN0cnVjdCBnY3RsX3JlcSAqLCBzdHJ1Y3Qg Z19jbGFzcyAqLCBzdHJ1Y3QgZ19nZW9tICopOwogCiBzdGF0aWMgc3RydWN0IGdfZ2VvbSAqZ19t dWx0aXBhdGhfZmluZF9nZW9tKHN0cnVjdCBnX2NsYXNzICosIGNvbnN0IGNoYXIgKik7Ci1zdGF0 aWMgaW50IGdfbXVsdGlwYXRoX3JvdGF0ZShzdHJ1Y3QgZ19nZW9tICopOworc3RhdGljIHZvaWQg Z19tdWx0aXBhdGhfcm90YXRlKHN0cnVjdCBnX2dlb20gKik7CiAKIHN0YXRpYyBnX3Rhc3RlX3Qg Z19tdWx0aXBhdGhfdGFzdGU7CiBzdGF0aWMgZ19jdGxfcmVxX3QgZ19tdWx0aXBhdGhfY29uZmln OwpAQCAtOTUsMTEgKzk1LDMwIEBACiBnX21wZCh2b2lkICphcmcsIGludCBmbGFncyBfX3VudXNl ZCkKIHsKIAlzdHJ1Y3QgZ19jb25zdW1lciAqY3A7CisJc3RydWN0IGdfZ2VvbSAqZ3A7CisJc3Ry dWN0IGdfbXVsdGlwYXRoX3NvZnRjICpzYzsKKwlzdHJ1Y3QgZ19wcm92aWRlciAqcHA7CiAKIAln X3RvcG9sb2d5X2Fzc2VydCgpOwogCWNwID0gYXJnOwogCWlmIChjcC0+YWNyID4gMCB8fCBjcC0+ YWN3ID4gMCB8fCBjcC0+YWNlID4gMCkKIAkJZ19hY2Nlc3MoY3AsIC1jcC0+YWNyLCAtY3AtPmFj dywgLWNwLT5hY2UpOworCisJZ3AgPSBjcC0+Z2VvbTsKKwlzYyA9IGdwLT5zb2Z0YzsKKwlwcCA9 IGNwLT5wcm92aWRlcjsKKworCWlmIChjcCA9PSBzYy0+Y3BfYWN0aXZlKSB7CisJCXByaW50Zigi R0VPTV9NVUxUSVBBVEg6ICVzIGZhaWxlZCBpbiAlc1xuIiwKKwkJICAgIHBwLT5uYW1lLCBzYy0+ c2NfbmFtZSk7CisJCXNjLT5jcF9hY3RpdmUgPSBOVUxMOworCQlnX211bHRpcGF0aF9yb3RhdGUo Z3ApOworCQlpZiAoc2MtPmNwX2FjdGl2ZSA9PSBOVUxMIHx8IHNjLT5jcF9hY3RpdmUtPnByb3Zp ZGVyID09IE5VTEwpIHsKKwkJCXByaW50ZigiR0VPTV9NVUxUSVBBVEg6IG91dCBvZiBwcm92aWRl cnMgZm9yICVzXG4iLAorCQkJICAgIHNjLT5zY19uYW1lKTsKKwkJfQorCX0KKwogCWlmIChjcC0+ cHJvdmlkZXIpIHsKIAkJcHJpbnRmKCJHRU9NX01VTFRJUEFUSDogJXMgcmVtb3ZlZCBmcm9tICVz XG4iLAogCQkgICAgY3AtPnByb3ZpZGVyLT5uYW1lLCBjcC0+Z2VvbS0+bmFtZSk7CkBAIC0xODcs MjQgKzIwNiwxNSBAQAogCQlnX3Bvc3RfZXZlbnQoZ19tcGQsIGNwLCBNX05PV0FJVCwgTlVMTCk7 CiAJfQogCWlmIChjcCA9PSBzYy0+Y3BfYWN0aXZlKSB7Ci0JCXN0cnVjdCBnX2NvbnN1bWVyICps Y3A7CiAJCXByaW50ZigiR0VPTV9NVUxUSVBBVEg6ICVzIGZhaWxlZCBpbiAlc1xuIiwKIAkJICAg IHBwLT5uYW1lLCBzYy0+c2NfbmFtZSk7CiAJCXNjLT5jcF9hY3RpdmUgPSBOVUxMOwotCQlMSVNU X0ZPUkVBQ0gobGNwLCAmZ3AtPmNvbnN1bWVyLCBjb25zdW1lcikgewotCQkJaWYgKChsY3AtPmlu ZGV4ICYgTVBfQkFEKSA9PSAwKSB7Ci0JCQkJc2MtPmNwX2FjdGl2ZSA9IGxjcDsKLQkJCQlicmVh azsKLQkJCX0KLQkJfQorCQlnX211bHRpcGF0aF9yb3RhdGUoZ3ApOwogCQlpZiAoc2MtPmNwX2Fj dGl2ZSA9PSBOVUxMIHx8IHNjLT5jcF9hY3RpdmUtPnByb3ZpZGVyID09IE5VTEwpIHsKIAkJCXBy aW50ZigiR0VPTV9NVUxUSVBBVEg6IG91dCBvZiBwcm92aWRlcnMgZm9yICVzXG4iLAogCQkJICAg IHNjLT5zY19uYW1lKTsKIAkJCWdfdG9wb2xvZ3lfdW5sb2NrKCk7CiAJCQlyZXR1cm47Ci0JCX0g ZWxzZSB7Ci0JCQlwcmludGYoIkdFT01fTVVMVElQQVRIOiAlcyBub3cgYWN0aXZlIHBhdGggaW4g JXNcbiIsCi0JCQkgICAgc2MtPmNwX2FjdGl2ZS0+cHJvdmlkZXItPm5hbWUsIHNjLT5zY19uYW1l KTsKIAkJfQogCX0KIAlnX3RvcG9sb2d5X3VubG9jaygpOwpAQCAtMjU4LDcgKzI2OCw3IEBACiAK IAlMSVNUX0ZPUkVBQ0goY3AsICZncC0+Y29uc3VtZXIsIGNvbnN1bWVyKSB7CiAJCWVycm9yID0g Z19hY2Nlc3MoY3AsIGRyLCBkdywgZGUpOwotCQlpZiAoZXJyb3IpIHsKKwkJaWYgKGVycm9yICYm IGVycm9yICE9IEVOWElPKSB7CiAJCQliYWRjcCA9IGNwOwogCQkJZ290byBmYWlsOwogCQl9CkBA IC00MDksMTcgKzQxOSwxNiBAQAogCXJldHVybiAoZ19tdWx0aXBhdGhfZGVzdHJveShncCkpOwog fQogCi1zdGF0aWMgaW50CitzdGF0aWMgdm9pZAogZ19tdWx0aXBhdGhfcm90YXRlKHN0cnVjdCBn X2dlb20gKmdwKQogewogCXN0cnVjdCBnX2NvbnN1bWVyICpsY3A7CiAJc3RydWN0IGdfbXVsdGlw YXRoX3NvZnRjICpzYyA9IGdwLT5zb2Z0YzsKIAogCWdfdG9wb2xvZ3lfYXNzZXJ0KCk7Ci0JaWYg KHNjID09IE5VTEwpCi0JCXJldHVybiAoRU5YSU8pOworCUtBU1NFUlQoc2MgIT0gTlVMTCwgKCJO VUxMIHNjIikpOwogCUxJU1RfRk9SRUFDSChsY3AsICZncC0+Y29uc3VtZXIsIGNvbnN1bWVyKSB7 Ci0JCWlmICgobGNwLT5pbmRleCAmIE1QX0JBRCkgPT0gMCkgeworCQlpZiAoKGxjcC0+aW5kZXgg JiAoTVBfQkFEfE1QX1BPU1RFRCkpID09IDApIHsKIAkJCWlmIChzYy0+Y3BfYWN0aXZlICE9IGxj cCkgewogCQkJCWJyZWFrOwogCQkJfQpAQCAtNDMwLDcgKzQzOSw2IEBACiAJCXByaW50ZigiR0VP TV9NVUxUSVBBVEg6ICVzIG5vdyBhY3RpdmUgcGF0aCBpbiAlc1xuIiwKIAkJICAgIGxjcC0+cHJv dmlkZXItPm5hbWUsIHNjLT5zY19uYW1lKTsKIAl9Ci0JcmV0dXJuICgwKTsKIH0KIAogc3RhdGlj IHZvaWQKQEAgLTcxNSw3ICs3MjMsNiBAQAogewogCXN0cnVjdCBnX2dlb20gKmdwOwogCWNvbnN0 IGNoYXIgKm5hbWU7Ci0JaW50IGVycm9yOwogCiAJZ190b3BvbG9neV9hc3NlcnQoKTsKIApAQCAt NzI5LDEwICs3MzYsMTEgQEAKIAkJZ2N0bF9lcnJvcihyZXEsICJEZXZpY2UgJXMgaXMgaW52YWxp ZCIsIG5hbWUpOwogCQlyZXR1cm47CiAJfQotCWVycm9yID0gZ19tdWx0aXBhdGhfcm90YXRlKGdw KTsKLQlpZiAoZXJyb3IgIT0gMCkgewotCQlnY3RsX2Vycm9yKHJlcSwgImZhaWxlZCB0byByb3Rh dGUgJXMgKGVycj0lZCkiLCBuYW1lLCBlcnJvcik7CisJaWYgKGdwLT5zb2Z0YyA9PSBOVUxMKSB7 CisJCWdjdGxfZXJyb3IocmVxLCAiRGV2aWNlICVzIG5vdCBmdWxseSBpbml0aWFsaXplZCIsIG5h bWUpOworCQlyZXR1cm47CiAJfQorCWdfbXVsdGlwYXRoX3JvdGF0ZShncCk7CiB9CiAKIHN0YXRp YyB2b2lkCg== --20cf30549dc5ccaf1a0494b8e13d-- From owner-freebsd-geom@FreeBSD.ORG Wed Nov 10 22:02:37 2010 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C11E106566C; Wed, 10 Nov 2010 22:02:37 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id 265BD8FC15; Wed, 10 Nov 2010 22:02:37 +0000 (UTC) Received: from [192.168.221.2] (remotevpn [192.168.221.2]) by ns1.feral.com (8.14.4/8.14.3) with ESMTP id oAAM2YI4081666 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 10 Nov 2010 14:02:36 -0800 (PST) (envelope-from mj@feral.com) Message-ID: <4CDB1674.1000606@feral.com> Date: Wed, 10 Nov 2010 14:02:28 -0800 From: Matthew Jacob Organization: Feral Software User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Oleg Sharoyko References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-4.2.6 (ns1.feral.com [192.168.221.1]); Wed, 10 Nov 2010 14:02:36 -0800 (PST) Cc: mjacob@freebsd.org, freebsd-geom@freebsd.org Subject: Re: [patch] [geom_multipath] detached device used as an active path X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 22:02:37 -0000 It's going to take me a bit to digest this. I have a huge set of diffs I haven't brought in yet. On 11/10/2010 12:41 PM, Oleg Sharoyko wrote: > Hi Matthew, > > Please take a look at the patch I'm attaching to this mail. It fixes > couple of issues with cp->active being left pointing to detached > device. I have as well tried to remove code duplication a bit by using > g_multipath_rotate() in g_mpd() and g_multipath_done_error() instead > of identical loops. > > One thing which I'm not 100% sure about is this part (this is within > g_multipath_access()): > > @@ -258,7 +268,7 @@ > > LIST_FOREACH(cp,&gp->consumer, consumer) { > error = g_access(cp, dr, dw, de); > - if (error) { > + if (error&& error != ENXIO) { > badcp = cp; > goto fail; > } > > This change fixes undesired behavior in the following case: > > While running > > while true; do > echo > date > dd if=/dev/multipath/test of=/dev/null bs=512 count=1 > sleep 1 > done > > disconnect currently active path of /dev/multipath/test. > > Without "&& error != ENXIO" I have exactly one failed dd. Whith it - > none of dd fails. > > Shouldn't the overall logic of g_multipath_access() be as follows: try > to do what we're asked to do while there are at least one available > path, and remove from g_multipath any path for which g_access() call > has failed? I would suppose that multipath device should try to work > as long as there is at least one workable path, and any path which has > failed (no matter if it was a physical failure or, f.e. ENOMEM in > device driver) should be detached from multipath device. > From owner-freebsd-geom@FreeBSD.ORG Fri Nov 12 09:28:52 2010 Return-Path: Delivered-To: freebsd-geom@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0C751065670; Fri, 12 Nov 2010 09:28:52 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7766A8FC1A; Fri, 12 Nov 2010 09:28:52 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oAC9Sqck000748; Fri, 12 Nov 2010 09:28:52 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oAC9SqtL000744; Fri, 12 Nov 2010 09:28:52 GMT (envelope-from linimon) Date: Fri, 12 Nov 2010 09:28:52 GMT Message-Id: <201011120928.oAC9SqtL000744@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-geom@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/151989: [geli] [patch] fix geli version check X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 09:28:52 -0000 Old Synopsis: geli version check New Synopsis: [geli] [patch] fix geli version check Responsible-Changed-From-To: freebsd-bugs->freebsd-geom Responsible-Changed-By: linimon Responsible-Changed-When: Fri Nov 12 09:27:59 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=151989 From owner-freebsd-geom@FreeBSD.ORG Fri Nov 12 15:00:27 2010 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D14610656C4 for ; Fri, 12 Nov 2010 15:00:27 +0000 (UTC) (envelope-from gcubfg-freebsd-geom@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id D4ACD8FC24 for ; Fri, 12 Nov 2010 15:00:22 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PGv6z-00012i-Ij for freebsd-geom@freebsd.org; Fri, 12 Nov 2010 16:00:21 +0100 Received: from cpe-188-129-96-31.dynamic.amis.hr ([188.129.96.31]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 12 Nov 2010 16:00:21 +0100 Received: from ivoras by cpe-188-129-96-31.dynamic.amis.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 12 Nov 2010 16:00:21 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-geom@freebsd.org From: Ivan Voras Date: Fri, 12 Nov 2010 16:00:09 +0100 Lines: 25 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: cpe-188-129-96-31.dynamic.amis.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101102 Thunderbird/3.1.6 Cc: freebsd-fs@freebsd.org Subject: ZFS stripesize patch (in the context of 4k sector drives) X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 15:00:27 -0000 Hello, Any objections to me committing the following patch? The intention is to use stripesize info from GEOM in creating vdevs, in the hope that the 4 KiB sector magic will work. Index: cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c =================================================================== --- cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c (revision 215173) +++ cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_geom.c (working copy) @@ -496,7 +496,8 @@ /* * Determine the device's minimum transfer size. */ - *ashift = highbit(MAX(pp->sectorsize, SPA_MINBLOCKSIZE)) - 1; + *ashift = highbit(MAX(pp->stripesize ? pp->stripesize : pp->sectorsize, + SPA_MINBLOCKSIZE)) - 1; /* * Clear the nowritecache bit, so that on a vdev_reopen() we will From owner-freebsd-geom@FreeBSD.ORG Fri Nov 12 16:02:31 2010 Return-Path: Delivered-To: freebsd-geom@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A4961065674; Fri, 12 Nov 2010 16:02:31 +0000 (UTC) (envelope-from pjd@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id F3AC58FC27; Fri, 12 Nov 2010 16:02:30 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oACG2Uqf091498; Fri, 12 Nov 2010 16:02:30 GMT (envelope-from pjd@freefall.freebsd.org) Received: (from pjd@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oACG2U21091494; Fri, 12 Nov 2010 16:02:30 GMT (envelope-from pjd) Date: Fri, 12 Nov 2010 16:02:30 GMT Message-Id: <201011121602.oACG2U21091494@freefall.freebsd.org> To: yamayan@wind.sannet.ne.jp, pjd@FreeBSD.org, freebsd-geom@FreeBSD.org, pjd@FreeBSD.org From: pjd@FreeBSD.org Cc: Subject: Re: kern/151989: [geli] [patch] fix geli version check X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 16:02:31 -0000 Synopsis: [geli] [patch] fix geli version check State-Changed-From-To: open->closed State-Changed-By: pjd State-Changed-When: ptk 12 lis 2010 15:55:42 UTC State-Changed-Why: As the error message states, the check you modified verifies if geli(8) userland tool is in sync with geom_eli.ko kernel module. GELI handles older metadata just fine. For the future always update both userland and kernel. Responsible-Changed-From-To: freebsd-geom->pjd Responsible-Changed-By: pjd Responsible-Changed-When: ptk 12 lis 2010 15:55:42 UTC Responsible-Changed-Why: I'll take this one. http://www.freebsd.org/cgi/query-pr.cgi?pr=151989 From owner-freebsd-geom@FreeBSD.ORG Fri Nov 12 18:09:49 2010 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BDCA61065679 for ; Fri, 12 Nov 2010 18:09:49 +0000 (UTC) (envelope-from gcubfg-freebsd-geom@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 741C98FC27 for ; Fri, 12 Nov 2010 18:09:49 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PGy4I-0007fp-RM for freebsd-geom@freebsd.org; Fri, 12 Nov 2010 19:09:46 +0100 Received: from cpe-188-129-82-31.dynamic.amis.hr ([188.129.82.31]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 12 Nov 2010 19:09:46 +0100 Received: from ivoras by cpe-188-129-82-31.dynamic.amis.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 12 Nov 2010 19:09:46 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-geom@freebsd.org From: Ivan Voras Date: Fri, 12 Nov 2010 19:09:29 +0100 Lines: 14 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: cpe-188-129-82-31.dynamic.amis.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101102 Thunderbird/3.1.6 In-Reply-To: Cc: freebsd-fs@freebsd.org Subject: Re: ZFS stripesize patch (in the context of 4k sector drives) X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 18:09:49 -0000 On 11/12/10 16:00, Ivan Voras wrote: > Hello, > > Any objections to me committing the following patch? > > The intention is to use stripesize info from GEOM in creating vdevs, in > the hope that the 4 KiB sector magic will work. Or maybe not. I've grepped and other tools use stripesize in the way its name suggests - as RAID stripe size, not as logical sector size. New idea on the menu: make the logical sector size a separate concept and a separate variable from stripe size. Would that be a better approach? From owner-freebsd-geom@FreeBSD.ORG Sat Nov 13 09:54:33 2010 Return-Path: Delivered-To: freebsd-geom@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C581B106566B; Sat, 13 Nov 2010 09:54:33 +0000 (UTC) (envelope-from arundel@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9A88F8FC0A; Sat, 13 Nov 2010 09:54:33 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oAD9sXUC031544; Sat, 13 Nov 2010 09:54:33 GMT (envelope-from arundel@freefall.freebsd.org) Received: (from arundel@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oAD9sXIL031540; Sat, 13 Nov 2010 09:54:33 GMT (envelope-from arundel) Date: Sat, 13 Nov 2010 09:54:33 GMT Message-Id: <201011130954.oAD9sXIL031540@freefall.freebsd.org> To: arundel@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-geom@FreeBSD.org From: arundel@FreeBSD.org Cc: Subject: Re: bin/120990: [patch] support "BIOS Boot" partition type in gpt(8) X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Nov 2010 09:54:33 -0000 Synopsis: [patch] support "BIOS Boot" partition type in gpt(8) Responsible-Changed-From-To: freebsd-bugs->freebsd-geom Responsible-Changed-By: arundel Responsible-Changed-When: Sat Nov 13 09:53:15 UTC 2010 Responsible-Changed-Why: Assign to freebsd-geom@, since they will have an opinion regarding this issue. http://www.freebsd.org/cgi/query-pr.cgi?pr=120990