From owner-freebsd-geom@FreeBSD.ORG Mon May 7 11:07:12 2012 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8C046106564A for ; Mon, 7 May 2012 11:07:12 +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 6C2E28FC22 for ; Mon, 7 May 2012 11:07:12 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q47B7Cn7072367 for ; Mon, 7 May 2012 11:07:12 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q47B7B1Z072365 for freebsd-geom@FreeBSD.org; Mon, 7 May 2012 11:07:11 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 7 May 2012 11:07:11 GMT Message-Id: <201205071107.q47B7B1Z072365@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, 07 May 2012 11:07:12 -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/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/162010 geom [geli] panic: Provider's error should be set (error=0) o kern/161979 geom [geom] glabel doesn't update after newfs, and glabel s o kern/161752 geom [geom] glabel(8) doesn't get gpt label change o bin/161677 geom gpart(8) Probably bug in gptboot o kern/160562 geom [geom][patch] Allow to insert new component to geom_ra o kern/160409 geom [geli] failed to attach provider f kern/159595 geom [geom] [panic] panic on gmirror unload in vbox [regres p kern/158398 geom [headers] [patch] includes o kern/158197 geom [geom] geom_cache with size>1000 leads to panics o kern/157879 geom [libgeom] [regression] ABI change without version bump o kern/157863 geom [geli] kbdmux prevents geli passwords from being enter o kern/157739 geom [geom] GPT labels with geom_multipath o kern/157724 geom [geom] gpart(8) 'add' command must preserve gap for sc o kern/157723 geom [geom] GEOM should not process 'c' (raw) partitions fo o kern/157108 geom [gjournal] dumpon(8) fails on gjournal providers o kern/155994 geom [geom] Long "Suspend time" when reading large files fr o kern/154226 geom [geom] GEOM label does not change when you modify them o kern/150858 geom [geom] [geom_label] [patch] glabel(8) is not compatibl o kern/150626 geom [geom] [gjournal] gjournal(8) destroys label o kern/150555 geom [geom] gjournal unusable on GPT partitions o kern/150334 geom [geom] [udf] [patch] geom label does not support UDF o kern/149762 geom volume labels with rogue characters o bin/149215 geom [panic] [geom_part] gpart(8): Delete linux's slice via o kern/147667 geom [gmirror] Booting with one component of a gmirror, the o kern/145818 geom [geom] geom_stat_open showing cached information for n o kern/145042 geom [geom] System stops booting after printing message "GE o kern/143455 geom gstripe(8) in RELENG_8 (31st Jan 2010) broken o kern/142563 geom [geom] [hang] ioctl freeze in zpool o kern/141740 geom [geom] gjournal(8): g_journal_destroy concurrent error o kern/140352 geom [geom] gjournal + glabel not working o kern/135898 geom [geom] Severe filesystem corruption - large files or l o kern/134922 geom [gmirror] [panic] kernel panic when use fdisk on disk o kern/134113 geom [geli] Problem setting secondary GELI key o kern/133931 geom [geli] [request] intentionally wrong password to destr o bin/132845 geom [geom] [patch] ggated(8) does not close files opened a o bin/131415 geom [geli] keystrokes are unregulary sent to Geli when typ o kern/131353 geom [geom] gjournal(8) kernel lock o kern/129674 geom [geom] gjournal root did not mount on boot o kern/129645 geom gjournal(8): GEOM_JOURNAL causes system to fail to boo o kern/129245 geom [geom] gcache is more suitable for suffix based provid f kern/128276 geom [gmirror] machine lock up when gmirror module is used o kern/127420 geom [geom] [gjournal] [panic] Journal overflow on gmirrore o kern/124973 geom [gjournal] [patch] boot order affects geom_journal con o kern/124969 geom gvinum(8): gvinum raid5 plex does not detect missing s o kern/123962 geom [panic] [gjournal] gjournal (455Gb data, 8Gb journal), o kern/123122 geom [geom] GEOM / gjournal kernel lock o kern/122738 geom [geom] gmirror list "losts consumers" after gmirror de o kern/122067 geom [geom] [panic] Geom crashed during boot o kern/121364 geom [gmirror] Removing all providers create a "zombie" mir o kern/120091 geom [geom] [geli] [gjournal] geli does not prompt for pass o kern/115856 geom [geli] ZFS thought it was degraded when it should have o kern/115547 geom [geom] [patch] [request] let GEOM Eli get password fro o kern/114532 geom [geom] GEOM_MIRROR shows up in kldstat even if compile f kern/113957 geom [gmirror] gmirror is intermittently reporting a degrad o kern/113837 geom [geom] unable to access 1024 sector size storage o kern/113419 geom [geom] geom fox multipathing not failing back o kern/107707 geom [geom] [patch] [request] add new class geom_xbox360 to o kern/94632 geom [geom] Kernel output resets input while GELI asks for o kern/90582 geom [geom] [panic] Restore cause panic string (ffs_blkfree o bin/90093 geom fdisk(8) incapable of altering in-core geometry o kern/87544 geom [gbde] mmaping large files on a gbde filesystem deadlo o bin/86388 geom [geom] [geom_part] periodic(8) daily should backup gpa o kern/84556 geom [geom] [panic] GBDE-encrypted swap causes panic at shu o kern/79251 geom [2TB] newfs fails on 2.6TB gbde device o kern/79035 geom [vinum] gvinum unable to create a striped set of mirro o bin/78131 geom gbde(8) "destroy" not working. 72 problems total. From owner-freebsd-geom@FreeBSD.ORG Wed May 9 14:16:35 2012 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7E7DF106564A for ; Wed, 9 May 2012 14:16:35 +0000 (UTC) (envelope-from kpielorz_lst@tdx.co.uk) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id 18F608FC18 for ; Wed, 9 May 2012 14:16:34 +0000 (UTC) Received: from OctaHexa64-MkII (HPQuadro64.dmpriest.net.uk [62.13.130.30]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3) with ESMTP id q49EGWou095428 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO) for ; Wed, 9 May 2012 15:16:33 +0100 (BST) Date: Wed, 09 May 2012 15:16:36 +0100 From: Karl Pielorz To: freebsd-geom@FreeBSD.org Message-ID: <1A0908A20F2EDF2BC491695C@OctaHexa64-MkII> 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 Cc: Subject: FreeBSD 9-R amd64 - graid, should it survive 'pulling' a disk? 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, 09 May 2012 14:16:35 -0000 Hi, I've got a Supermicro X8DTL-IF running amd64 FreeBSD 9.0-R, using the onboard RAID (ICH10 based) and graid, with a RAID 1 mirror comprising of two Intel 320 series SSD's. This works fine - but doesn't survive 'pulling' a disk. I realise this may not be a 'typical' disk failure scenario (i.e. the device just "disappearing") - but should it survive? At the moment I get a panic with: " (ada0:ahcich0:0:0:0): lost device g_vfs_done(): raid/r0p4[WRITE(offset=23737925632, length=131072)]error = 6 /usr3: got error 6 while accessing filesystem panic: softdep_deallocate_dependancies: unrecovered I/O error cpuid = 2 ... " In the middle of the output is: " GEOM_RAID: Intel-441dffb: Disk ada0 state changed from ACTIVE to OFFLINE. " (Which is what you'd expect to see). I can get more details - just thought I'd ask to see if this is something it should just cope with (i.e. having a disk yanked)? Thanks, -Karl From owner-freebsd-geom@FreeBSD.ORG Wed May 9 16:20:11 2012 Return-Path: Delivered-To: freebsd-geom@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E468F106564A for ; Wed, 9 May 2012 16:20:11 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B64E08FC12 for ; Wed, 9 May 2012 16:20:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q49GKBRr036237 for ; Wed, 9 May 2012 16:20:11 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q49GKBqW036236; Wed, 9 May 2012 16:20:11 GMT (envelope-from gnats) Date: Wed, 9 May 2012 16:20:11 GMT Message-Id: <201205091620.q49GKBqW036236@freefall.freebsd.org> To: freebsd-geom@FreeBSD.org From: Andreas Longwitz Cc: Subject: Re: kern/164252: [geom] gjournal overflow X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Andreas Longwitz List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 16:20:12 -0000 The following reply was made to PR kern/164252; it has been noted by GNATS. From: Andreas Longwitz To: bug-followup@freebsd.org Cc: Subject: Re: kern/164252: [geom] gjournal overflow Date: Wed, 09 May 2012 18:12:51 +0200 The panic "gjournal overflow" is caused by design problems of snapshot and/or gjournal on big disks (1 TB or more). Each journaled partition is served by a kernel thread g_journal and there is one kernel thread g_journal switcher responsible for all journaled partitions. Aside from mount/umount the g_journal switcher and snapshot for ffs are the only kernel threads using vfs_write_suspend() holding the lock "suspwt". After starting a snapshot on a big disk with mksnap_ffs /backup/.snap/snapshot the lock "suspwt" will be catched and hold for a long time. Some seconds later the g_journal switcher tries to switch the journal of the backup partition and blocks on the "suspwt" lock. Therefore he can not handle the other journaled partition anymore, he must wait until the snapshot releases the "suspwt" lock. On my test server (FreeBSD 8.3) /backup is mounted on /dev/mirror/gm2p2 (1,8 TB) and kern.geom.journal.debug=1 gives May 9 09:59:47 : Data has been copied. May 9 09:59:47 : Msync time of /backup: 0.031111s May 9 09:59:47 : Sync time of /backup: 0.086015s May 9 09:59:47 : Cache flush time: 0.000705s May 9 09:59:47 : BIO_FLUSH time of mirror/gm2p2: 0.015049s May 9 10:04:12 : Journal mirror/gm2p2 71% full, forcing journal switch. May 9 10:17:48 : Suspend time of /backup: 1080.955120s May 9 10:17:48 : Starting copy of journal. May 9 10:17:48 : Cache flush time: 0.013182s May 9 10:17:48 : Cache flush time: 0.027241s May 9 10:17:48 : Switch time of mirror/gm2p2: 0.206213s May 9 10:17:48 : Entire switch time: 1081.589788s The critical "Suspend time" was 18 minutes with no I/O on any other partitions. The same test with some I/O's on any other partition triggers the panic immediately, because my journal is not big enough to hold the I/O's of 18 minutes. The same problem occurs on removing the snapshot, the g_journal switcher waits for 10 minutes on the "ufs" lock. The same test on a 1 TB disk drops the "Suspend time" to 190 seconds for the snapshot and 12 seconds for the remove. My conclusion is, that snapshot (used for dump -L) on a journaled partition is not safe, when the "Suspend time" for the biggest journaled partition is more than about 20 seconds. -- Dr. Andreas Longwitz Data Service GmbH Beethovenstr. 2A 23617 Stockelsdorf Amtsgericht Lübeck, HRB 318 BS Geschäftsführer: Wilfried Paepcke, Dr. Andreas Longwitz, Josef Flatau From owner-freebsd-geom@FreeBSD.ORG Thu May 10 03:38:13 2012 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 14A0B106564A for ; Thu, 10 May 2012 03:38:13 +0000 (UTC) (envelope-from modulok@gmail.com) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id C46708FC0A for ; Thu, 10 May 2012 03:38:12 +0000 (UTC) Received: by qcsg15 with SMTP id g15so1053715qcs.13 for ; Wed, 09 May 2012 20:38:12 -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=+XPK9ikeq2CdE5PeTp2TfaRmjTDfBphwGdaBCzB102U=; b=rijrO0Sf/5JVKwm6nsq0qqr30ik12H6nT1kC505kBkRN/XrJiUY/8O+KlJ00A3qN39 j0DP2kGQ0xl/QxwW2+atwqSIENNda+7EPkaKofeRnLJbVn3G3rgWxFRjGyAzl3weXtT8 LMXYKtN20i4aLS+gsw3xqPBvRnVb8ahOzX2aBZbb6+pa960NfWEfTriwre4HES+h7bRZ T0vIEXF9KKxRKLHcwga1IwvwRXeh49ij2NhUsPMUUGAPCgF8pageh/A08iZdgycOHXd4 nOVDWdVk+JpRo9tucql8RQspbOA1MnXBNfgsEDErLGG7l0xNGQVXB6pPPP5CL6h6teF/ uK0g== MIME-Version: 1.0 Received: by 10.229.135.84 with SMTP id m20mr1291001qct.96.1336621092062; Wed, 09 May 2012 20:38:12 -0700 (PDT) Received: by 10.229.250.7 with HTTP; Wed, 9 May 2012 20:38:11 -0700 (PDT) In-Reply-To: <1A0908A20F2EDF2BC491695C@OctaHexa64-MkII> References: <1A0908A20F2EDF2BC491695C@OctaHexa64-MkII> Date: Wed, 9 May 2012 21:38:11 -0600 Message-ID: From: Modulok To: Karl Pielorz Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-geom@freebsd.org Subject: Re: FreeBSD 9-R amd64 - graid, should it survive 'pulling' a disk? X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 03:38:13 -0000 On 5/9/12, Karl Pielorz wrote: > > Hi, > > I've got a Supermicro X8DTL-IF running amd64 FreeBSD 9.0-R, using the > onboard RAID (ICH10 based) and graid, with a RAID 1 mirror comprising of > two Intel 320 series SSD's. > > This works fine - but doesn't survive 'pulling' a disk. I realise this may > not be a 'typical' disk failure scenario (i.e. the device just > "disappearing") - but should it survive? > > At the moment I get a panic with: > > " > (ada0:ahcich0:0:0:0): lost device > g_vfs_done(): raid/r0p4[WRITE(offset=23737925632, length=131072)]error = 6 > /usr3: got error 6 while accessing filesystem > panic: softdep_deallocate_dependancies: unrecovered I/O error > cpuid = 2 > ... > " > > In the middle of the output is: > > " > GEOM_RAID: Intel-441dffb: Disk ada0 state changed from ACTIVE to OFFLINE. > " > > (Which is what you'd expect to see). > > I can get more details - just thought I'd ask to see if this is something > it should just cope with (i.e. having a disk yanked)? Karl, As far as I know, it depends on the disk. I've never used the model mentioned. In my experience, if the disk supports hot swapping then yes, the system should remain up and running when you yank the cable. I've yanked disk cables in a running FreeBSD system which was using Western Digital's RE hot swappable drives without any problems. They were part of a gmirror and on another system a graid3. However, I've also done this on a machine that was using consumer desktop drives and had panics. Perhaps someone else knows more. -Modulok- From owner-freebsd-geom@FreeBSD.ORG Thu May 10 15:13:32 2012 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3E6FC106566B for ; Thu, 10 May 2012 15:13:32 +0000 (UTC) (envelope-from trent@snakebite.org) Received: from exchange.liveoffice.com (exchla3.liveoffice.com [64.70.67.188]) by mx1.freebsd.org (Postfix) with ESMTP id 1EF868FC08 for ; Thu, 10 May 2012 15:13:31 +0000 (UTC) Received: from EXHUB02.exchhosting.com (192.168.11.214) by exhub11.exchhosting.com (192.168.11.109) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 10 May 2012 08:13:31 -0700 Received: from EXMBX10.exchhosting.com ([fe80::9c37:32f6:a508:a44f]) by exhub02.exchhosting.com ([fe80::311c:a4c3:90a7:3e53%12]) with mapi; Thu, 10 May 2012 08:13:31 -0700 From: Trent Nelson To: "mj@feral.com" Date: Thu, 10 May 2012 08:13:29 -0700 Thread-Topic: Teaching gmultipath about path cost/priority Thread-Index: Ac0uv3Vbm6rmwL8aTjSkezjxn9IgHg== Message-ID: <4A6AB54F-A0B3-40A6-A8E4-EE9992B5C52D@snakebite.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-geom@freebsd.org" Subject: Teaching gmultipath about path cost/priority X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 15:13:32 -0000 Hi again Matt, I'm sure I'll eventually find a subsystem relevant to me that you *didn= 't* author, but for now, I have some gmultipath questions. Basically, the entire approach is perfect for me. As all my SAN target= s are JBODs (i.e. I don't have any targets that could saturate a single H= BA and thus would benefit from active/active multipathing), active/passive is exactly what I want. But... in my case, all paths are not equal. My fabric has four switche= s=20 and is fully meshed; a host may have up to four HBAs, each one connecte= d=20 to a separate switch. From a redundancy and failover perspective, I've made sure there are an abundance of paths available to a single disk. However, unless something has failed, there's only one path I want to u= se, as I've pre-planned that path to be the most optimal. It sounds like the order gmultipath uses to select paths is derived fro= m=20 the order it tastes disks -- something I have very little control over. It'd be ideal if there was a way of teaching gmultipath about a path cost/priority, so that it can make an informed decision about which path to choose a) when first initializing, and b) during failover. Thoughts? Regards, =20 Trent.= From owner-freebsd-geom@FreeBSD.ORG Thu May 10 15:26:20 2012 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 CC87A1065675 for ; Thu, 10 May 2012 15:26:20 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 84BD18FC0C for ; Thu, 10 May 2012 15:26:20 +0000 (UTC) Received: by qcsg15 with SMTP id g15so1567018qcs.13 for ; Thu, 10 May 2012 08:26:20 -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 :content-type:content-transfer-encoding; bh=Q4Z+ByF9kxMh+S02/0AjoI8yWXFtB4DIUjDuKqxHJU0=; b=lduIKD4wUZigzebuYNmXi+JoLtXhXBOSmLs5fQUV7I+3kOQBdFUV3wYZ8eo7XAM7fk hF6PYqkD0jZiS/OqtuWkPpOOS3S3PwtYoPfUUg0JvOOXop+7XAHByYYeZRj5d6HgI4WS hLEoX/YtuFBbsHgnZUjo6QYJLTjUb1nZwans2kQ046N6FT3Ssh/UYZGsQE5/O4MQWTDa 7/SSZu/OVMs2owAiX1XejUiZrSXYtI7sWhKR1BxJk/em6AB8mwuezfzx+fAJayL6R/1g 7fBINT1e5cKPVYLh8/Z4011VrhAoajmrAIzSGn6i9eRcDjJ9sFSCvgv7+T1fuutN76qz Ul/w== Received: by 10.224.174.79 with SMTP id s15mr7878631qaz.37.1336663579757; Thu, 10 May 2012 08:26:19 -0700 (PDT) Received: from mavbook.mavhome.dp.ua ([192.75.139.251]) by mx.google.com with ESMTPS id df8sm16941579qab.6.2012.05.10.08.26.18 (version=SSLv3 cipher=OTHER); Thu, 10 May 2012 08:26:18 -0700 (PDT) Sender: Alexander Motin Message-ID: <4FABDE10.8090304@FreeBSD.org> Date: Thu, 10 May 2012 18:26:08 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120116 Thunderbird/9.0 MIME-Version: 1.0 To: Karl Pielorz , freebsd-geom@FreeBSD.org Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: FreeBSD 9-R amd64 - graid, should it survive 'pulling' a disk? X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 15:26:20 -0000 Hi. This panic is not in graid code, but it can be called a problem of the graid's RAID1 implementation. If some disk returns _write_ failure, that failure may now be reported to higher levels. Problem is that UFS SU code panics on these errors in some cases. I'll try to look on it nearest time. -- Alexander Motin From owner-freebsd-geom@FreeBSD.ORG Thu May 10 15:41:47 2012 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A7EEC1065672 for ; Thu, 10 May 2012 15:41:47 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) by mx1.freebsd.org (Postfix) with ESMTP id 5EB4A8FC0A for ; Thu, 10 May 2012 15:41:47 +0000 (UTC) Received: by qabg1 with SMTP id g1so532153qab.13 for ; Thu, 10 May 2012 08:41:46 -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 :content-type:content-transfer-encoding; bh=tlbXcPvTxBDCZTwcTOh5wVEgQGKawZicATX3aE1gAU4=; b=0GQgT9b9RaYkAfMggpQlcK5g+baJjTOpIpvQc/qHMMJrCkVrti1vAl6gYbWEpb4p30 gFUzqvwhbdYc9b2Ie46sa4eGsS1cC30Jp0odMysSQtm+HF3ZLJZyasdElYwP8wAw5D+b IHvbJ2wGHqFdlRPFGulbLVNswn8oabyQYMjyUS1YH3v+x0kV8LqBad2nZE12/f0O55Q5 Xek7Y0azvelXixu0e3fwR+mU5Lbec5YPJqqnyUzQqZClCqk6IfgSOhtQDaGsXLMtJFuP jjstBeerWky8hl5hkML79dnhB7NkGd8fHgdGkl/Mm1cqq69guRWyzQ/6Nqwe+B2OBsQs tIgQ== Received: by 10.229.87.7 with SMTP id u7mr2353507qcl.15.1336664502899; Thu, 10 May 2012 08:41:42 -0700 (PDT) Received: from mavbook.mavhome.dp.ua ([192.75.139.251]) by mx.google.com with ESMTPS id dl3sm17006561qab.9.2012.05.10.08.41.38 (version=SSLv3 cipher=OTHER); Thu, 10 May 2012 08:41:38 -0700 (PDT) Sender: Alexander Motin Message-ID: <4FABE1A8.4000609@FreeBSD.org> Date: Thu, 10 May 2012 18:41:28 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120116 Thunderbird/9.0 MIME-Version: 1.0 To: Trent Nelson , mj@feral.com, freebsd-geom@FreeBSD.org Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Teaching gmultipath about path cost/priority X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 15:41:47 -0000 Hi. > It'd be ideal if there was a way of teaching gmultipath about a path > cost/priority, so that it can make an informed decision about which > path to choose a) when first initializing, and b) during failover. The problem with this is how to store that in metadata. As soon as all paths have exactly the same metadata and provider names are not mentioned there, separate paths properties are not possible at this moment. As dirty workaround, you may periodically run some script to enforce active path on your specific preference. -- Alexander Motin From owner-freebsd-geom@FreeBSD.ORG Thu May 10 16:36:35 2012 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3D78F106566C; Thu, 10 May 2012 16:36:35 +0000 (UTC) (envelope-from trent@snakebite.org) Received: from EXHUB04.exchhosting.com (exchla3.liveoffice.com [64.70.67.188]) by mx1.freebsd.org (Postfix) with ESMTP id BBBA68FC0C; Thu, 10 May 2012 16:36:34 +0000 (UTC) Received: from EXMBX10.exchhosting.com ([fe80::9c37:32f6:a508:a44f]) by EXHUB04.exchhosting.com ([fe80::e08b:16b6:14a0:73b0%12]) with mapi; Thu, 10 May 2012 09:36:33 -0700 From: Trent Nelson To: Alexander Motin Date: Thu, 10 May 2012 09:36:30 -0700 Thread-Topic: Teaching gmultipath about path cost/priority Thread-Index: Ac0uyw9HEIV7gRrZTyOZqA5FrxjpPQ== Message-ID: <7CED0E39-8C64-4AC1-80BA-D6DE9703E022@snakebite.org> References: <4FABE1A8.4000609@FreeBSD.org> In-Reply-To: <4FABE1A8.4000609@FreeBSD.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mj@feral.com" , "freebsd-geom@FreeBSD.org" Subject: Re: Teaching gmultipath about path cost/priority X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 16:36:35 -0000 On Thu, May 10, 2012 at 08:41:28AM -0700, Alexander Motin wrote: > Hi. > > > It'd be ideal if there was a way of teaching gmultipath about a path > > cost/priority, so that it can make an informed decision about which > > path to choose a) when first initializing, and b) during failover. > > The problem with this is how to store that in metadata. As soon as all > paths have exactly the same metadata and provider names are not > mentioned there, separate paths properties are not possible at this momen= t. Good point. In my environment, I use all sorts of convoluted ways to figure out which /dev/da[n] disk represents the optimal path I want to use. At the very least, I need to probe things from isp like port id, wwnn and wwpn. It's all very driver/HBA/environment specific. > As dirty workaround, you may periodically run some script to enforce > active path on your specific preference. Ah! Yeah, that was another approach I was thinking of suggesting; an ability to (gracefully) tell gmultipath to start using another path. Ignore my path cost/priority suggestion and pretend I asked that instead ;-) Extending the example in gmultipath(8): # gmultipath label -v FRED /dev/da0 /dev/da2 # disklabel -Brw /dev/multipath/FRED auto # newfs /dev/multipath/FREDa # mount /dev/multipath/FREDa /mnt.... GEOM_MULTIPATH: adding da0 to Fred/b631385f-c61c-11db-b884-0011116ae7= 89 GEOM_MULTIPATH: da0 now active path in Fred GEOM_MULTIPATH: adding da2 to Fred/b631385f-c61c-11db-b884-0011116ae7= 89 Something along the lines of: + # gmultipath active FRED /dev/da2 + GEOM_MULTIPATH: da2 now active path in Fred ....would be perfect! Don't care what it's called; active, failover, switch, select, activate. (I presume gmultipath could affect the path switch in a cleaner fashion than forcing the disk to fail? i.e. make sure all outstanding I/O is finished first, etc.) > Alexander Motin Trent. From owner-freebsd-geom@FreeBSD.ORG Thu May 10 16:38:28 2012 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 4153B106564A for ; Thu, 10 May 2012 16:38:28 +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 18B078FC21 for ; Thu, 10 May 2012 16:38:28 +0000 (UTC) Received: from [172.16.1.34] (float34.in1.lcl [172.16.1.34]) (authenticated bits=0) by ns1.feral.com (8.14.4/8.14.4) with ESMTP id q4AGcQ8h063177 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 10 May 2012 09:38:26 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4FABEEFD.90009@feral.com> Date: Thu, 10 May 2012 09:38:21 -0700 From: Matthew Jacob Organization: Feral Software User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: freebsd-geom@freebsd.org References: <4FABE1A8.4000609@FreeBSD.org> In-Reply-To: <4FABE1A8.4000609@FreeBSD.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (ns1.feral.com [192.67.166.1]); Thu, 10 May 2012 09:38:26 -0700 (PDT) Subject: Re: Teaching gmultipath about path cost/priority X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mj@feral.com List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 16:38:28 -0000 On 5/10/2012 8:41 AM, Alexander Motin wrote: > Hi. > > > It'd be ideal if there was a way of teaching gmultipath about a path > > cost/priority, so that it can make an informed decision about which > > path to choose a) when first initializing, and b) during failover. > > The problem with this is how to store that in metadata. As soon as all > paths have exactly the same metadata and provider names are not > mentioned there, separate paths properties are not possible at this > moment. > > As dirty workaround, you may periodically run some script to enforce > active path on your specific preference. > That is in fact exactly how we did this at Panasas From owner-freebsd-geom@FreeBSD.ORG Thu May 10 16:39:23 2012 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B78831065674 for ; Thu, 10 May 2012 16:39:23 +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 91AD48FC20 for ; Thu, 10 May 2012 16:39:23 +0000 (UTC) Received: from [172.16.1.34] (float34.in1.lcl [172.16.1.34]) (authenticated bits=0) by ns1.feral.com (8.14.4/8.14.4) with ESMTP id q4AGdNRC063185 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 10 May 2012 09:39:23 -0700 (PDT) (envelope-from mj@feral.com) Message-ID: <4FABEF36.50900@feral.com> Date: Thu, 10 May 2012 09:39:18 -0700 From: Matthew Jacob Organization: Feral Software User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Trent Nelson References: <4A6AB54F-A0B3-40A6-A8E4-EE9992B5C52D@snakebite.org> In-Reply-To: <4A6AB54F-A0B3-40A6-A8E4-EE9992B5C52D@snakebite.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (ns1.feral.com [192.67.166.1]); Thu, 10 May 2012 09:39:23 -0700 (PDT) Cc: "freebsd-geom@freebsd.org" Subject: Re: Teaching gmultipath about path cost/priority X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mj@feral.com List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 16:39:23 -0000 On 5/10/2012 8:13 AM, Trent Nelson wrote: > > Hi again Matt, > > I'm sure I'll eventually find a subsystem relevant to me that you *didn't* > author, but for now, I have some gmultipath questions. > > I may have authored it, but that doesn't mean I know anything or did it correctly. From owner-freebsd-geom@FreeBSD.ORG Thu May 10 17:09:52 2012 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8849D1065673 for ; Thu, 10 May 2012 17:09:52 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 37F448FC14 for ; Thu, 10 May 2012 17:09:52 +0000 (UTC) Received: by qcsg15 with SMTP id g15so1703612qcs.13 for ; Thu, 10 May 2012 10:09:51 -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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=VhwdVTShE+qxIHIMky4Zpk0l5ZJl2jG6edDD6jIsB4o=; b=uJ9cDekyH/xFmD75dmKo4qY1hKXE5WhzZYPqqbIWlndmh63i8JU2QPIiyfzQevDfWj Jfh5nmGTeMgAbKCs0uFK49Up5SsUsVDi1wPWhLENRElq8jHTPmIn7zzXCdfEUb0qR8BW br0D9b9EazMyPo6oyZCh5vct3tOp+r1qHaHiokW1ktEnDdWGqIH8quj4ZDOwYpdmwVzP mKKu0BX5Yejq/Zw4Xvb+WJpyorcfO+qtDrSQ+/qOej2L6G9EQo92LECm3rNnlXbsJ8sn hLubeAVQa4QiYjmRAjxN/48EUHCOeinDUONLDohRWiZ4LJ7WBbz1XGOcMVQ47ftO7W07 Omyg== Received: by 10.224.111.8 with SMTP id q8mr12833573qap.55.1336669791516; Thu, 10 May 2012 10:09:51 -0700 (PDT) Received: from mavbook.mavhome.dp.ua ([192.75.139.249]) by mx.google.com with ESMTPS id r19sm17394346qae.14.2012.05.10.10.09.50 (version=SSLv3 cipher=OTHER); Thu, 10 May 2012 10:09:50 -0700 (PDT) Sender: Alexander Motin Message-ID: <4FABF653.9030609@FreeBSD.org> Date: Thu, 10 May 2012 20:09:39 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120116 Thunderbird/9.0 MIME-Version: 1.0 To: Trent Nelson References: <4FABE1A8.4000609@FreeBSD.org> <7CED0E39-8C64-4AC1-80BA-D6DE9703E022@snakebite.org> In-Reply-To: <7CED0E39-8C64-4AC1-80BA-D6DE9703E022@snakebite.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: "mj@feral.com" , "freebsd-geom@FreeBSD.org" Subject: Re: Teaching gmultipath about path cost/priority X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 17:09:52 -0000 On 10.05.2012 19:36, Trent Nelson wrote: > On Thu, May 10, 2012 at 08:41:28AM -0700, Alexander Motin wrote: >> Hi. >> >> > It'd be ideal if there was a way of teaching gmultipath about a path >> > cost/priority, so that it can make an informed decision about which >> > path to choose a) when first initializing, and b) during failover. >> >> The problem with this is how to store that in metadata. As soon as all >> paths have exactly the same metadata and provider names are not >> mentioned there, separate paths properties are not possible at this moment. > > Good point. In my environment, I use all sorts of convoluted ways > to figure out which /dev/da[n] disk represents the optimal path I > want to use. At the very least, I need to probe things from isp > like port id, wwnn and wwpn. > > It's all very driver/HBA/environment specific. > >> As dirty workaround, you may periodically run some script to enforce >> active path on your specific preference. > > Ah! Yeah, that was another approach I was thinking of suggesting; > an ability to (gracefully) tell gmultipath to start using another > path. Ignore my path cost/priority suggestion and pretend I asked > that instead ;-) > > Extending the example in gmultipath(8): > > # gmultipath label -v FRED /dev/da0 /dev/da2 > # disklabel -Brw /dev/multipath/FRED auto > # newfs /dev/multipath/FREDa > # mount /dev/multipath/FREDa /mnt.... > GEOM_MULTIPATH: adding da0 to Fred/b631385f-c61c-11db-b884-0011116ae789 > GEOM_MULTIPATH: da0 now active path in Fred > GEOM_MULTIPATH: adding da2 to Fred/b631385f-c61c-11db-b884-0011116ae789 > > Something along the lines of: > > + # gmultipath active FRED /dev/da2 > + GEOM_MULTIPATH: da2 now active path in Fred > > ....would be perfect! Don't care what it's called; active, failover, > switch, select, activate. It may be not very convenient, but there is a `gmultipath rotate` command to change active path. I'll look on adding possibility to set specific path. > (I presume gmultipath could affect the path switch in a cleaner fashion > than forcing the disk to fail? i.e. make sure all outstanding I/O is > finished first, etc.) Now path switching doesn't waits for running requests completion. Is it a problem for you? -- Alexander Motin From owner-freebsd-geom@FreeBSD.ORG Fri May 11 00:37:35 2012 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 33AB0106566C; Fri, 11 May 2012 00:37:35 +0000 (UTC) (envelope-from trent@snakebite.org) Received: from exchange.liveoffice.com (exchla3.liveoffice.com [64.70.67.188]) by mx1.freebsd.org (Postfix) with ESMTP id 1360C8FC16; Fri, 11 May 2012 00:37:34 +0000 (UTC) Received: from exhub13.exchhosting.com (192.168.11.122) by exhub07.exchhosting.com (192.168.11.103) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 10 May 2012 17:37:33 -0700 Received: from EXMBX10.exchhosting.com ([fe80::9c37:32f6:a508:a44f]) by exhub13.exchhosting.com ([::1]) with mapi; Thu, 10 May 2012 17:37:32 -0700 From: Trent Nelson To: Alexander Motin Date: Thu, 10 May 2012 17:37:30 -0700 Thread-Topic: Teaching gmultipath about path cost/priority Thread-Index: Ac0vDkB47jvygSAySVuAeOYpPRJz4g== Message-ID: References: <4FABE1A8.4000609@FreeBSD.org> <7CED0E39-8C64-4AC1-80BA-D6DE9703E022@snakebite.org> <4FABF653.9030609@FreeBSD.org> In-Reply-To: <4FABF653.9030609@FreeBSD.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mj@feral.com" , "freebsd-geom@FreeBSD.org" Subject: Re: Teaching gmultipath about path cost/priority 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, 11 May 2012 00:37:35 -0000 On May 10, 2012, at 1:09 PM, Alexander Motin wrote: > On 10.05.2012 19:36, Trent Nelson wrote: >>=20 >> Something along the lines of: >>=20 >> + # gmultipath active FRED /dev/da2 >> + GEOM_MULTIPATH: da2 now active path in Fred >>=20 >> ....would be perfect! Don't care what it's called; active, failover= , >> switch, select, activate. >=20 > It may be not very convenient, but there is a `gmultipath rotate`=20 > command to change active path. Ah, didn't even know that existed (it's not mentioned in gmultipath(8)). I'll look into it, thanks.=20 >> (I presume gmultipath could affect the path switch in a cleaner fash= ion >> than forcing the disk to fail? i.e. make sure all outstanding I/O = is >> finished first, etc.) >=20 > Now path switching doesn't waits for running requests completion. Is it=20 > a problem for you? >=20 Still building the fabric, so that's completely and utterly a phantom requi= rement at the moment ;-) Trent.= From owner-freebsd-geom@FreeBSD.ORG Fri May 11 11:08:56 2012 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 54732106566C; Fri, 11 May 2012 11:08:56 +0000 (UTC) (envelope-from kpielorz_lst@tdx.co.uk) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id E12928FC08; Fri, 11 May 2012 11:08:55 +0000 (UTC) Received: from OctaHexa64-MkII (HPQuadro64.dmpriest.net.uk [62.13.130.30]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3) with ESMTP id q4BB8mPG034147 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Fri, 11 May 2012 12:08:49 +0100 (BST) Date: Fri, 11 May 2012 12:08:53 +0100 From: Karl Pielorz To: Alexander Motin , freebsd-geom@FreeBSD.org Message-ID: <61CDA17B687F1C733EE1B017@OctaHexa64-MkII> In-Reply-To: <4FABDE10.8090304@FreeBSD.org> References: <4FABDE10.8090304@FreeBSD.org> 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 Cc: Subject: Re: FreeBSD 9-R amd64 - graid, should it survive 'pulling' a disk? 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, 11 May 2012 11:08:56 -0000 --On 10 May 2012 18:26 +0300 Alexander Motin wrote: > Hi. > > This panic is not in graid code, but it can be called a problem of the > graid's RAID1 implementation. If some disk returns _write_ failure, that > failure may now be reported to higher levels. Problem is that UFS SU code > panics on these errors in some cases. I'll try to look on it nearest time. Hi, So for clarity - what you're saying is if one of the servers drops a disk from it's graid RAID1 array (for whatever reason) while writing, the error could 'bubble up' and have the UFS code panic, because of it? (even though the write would have completed on the other drive)? Is the same true for reads? -Karl From owner-freebsd-geom@FreeBSD.ORG Fri May 11 11:32:23 2012 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A1C28106566B for ; Fri, 11 May 2012 11:32:23 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 56E018FC14 for ; Fri, 11 May 2012 11:32:23 +0000 (UTC) Received: by yenl8 with SMTP id l8so3240512yen.13 for ; Fri, 11 May 2012 04:32:22 -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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=yuzjt/VIsDfFhXCFv/kX+qAFUpJagl5iBvZ3ixqUq3U=; b=B4EEaD/vwluy/r6pu1rqRjyzj0VrjXHzkhnC+Ut3t/Aso1mP6hC5uB7YE95sFXMZ5S T+gZlBymkajU0rTdz8P/LlQxU4IwSHLCqs/ARCQZDFoLH4NtYN0c28Nf949xU/UiGoFN fKF7KKSgBfKe1lSd3XKGkQBLKms3vGHKPNiDtmcmYCmCUDRKCLDTdvnnQIL8RHYHGZ9k hmSH0g6V2axlcj5wqlIyMTitPZWja8AdSmvafPJOVZP7phvcyWXj6Ex3oPQUVepjJlLL LNLtiPTE2JqjWjwiyxC/Vyc2HKvCwjqAMpCIcqnwAQmejR7Ac/X3AzbXh8hE51rStNYo u77g== Received: by 10.50.169.3 with SMTP id aa3mr1452673igc.28.1336735942502; Fri, 11 May 2012 04:32:22 -0700 (PDT) Received: from mavbook.mavhome.dp.ua ([24.114.252.240]) by mx.google.com with ESMTPS id wh8sm5501325igb.11.2012.05.11.04.32.21 (version=SSLv3 cipher=OTHER); Fri, 11 May 2012 04:32:21 -0700 (PDT) Sender: Alexander Motin Message-ID: <4FACF8BA.4020500@FreeBSD.org> Date: Fri, 11 May 2012 14:32:10 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120116 Thunderbird/9.0 MIME-Version: 1.0 To: Karl Pielorz References: <4FABDE10.8090304@FreeBSD.org> <61CDA17B687F1C733EE1B017@OctaHexa64-MkII> In-Reply-To: <61CDA17B687F1C733EE1B017@OctaHexa64-MkII> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-geom@FreeBSD.org Subject: Re: FreeBSD 9-R amd64 - graid, should it survive 'pulling' a disk? 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, 11 May 2012 11:32:23 -0000 On 11.05.2012 14:08, Karl Pielorz wrote: > --On 10 May 2012 18:26 +0300 Alexander Motin wrote: >> This panic is not in graid code, but it can be called a problem of the >> graid's RAID1 implementation. If some disk returns _write_ failure, that >> failure may now be reported to higher levels. Problem is that UFS SU code >> panics on these errors in some cases. I'll try to look on it nearest >> time. > > So for clarity - what you're saying is if one of the servers drops a > disk from it's graid RAID1 array (for whatever reason) while writing, > the error could 'bubble up' and have the UFS code panic, because of it? > (even though the write would have completed on the other drive)? Yes, sometimes bubble and in rare cases panic. I am working on the first part right now. > Is the same true for reads? No, On read error graid repeats reading from another disk and does remapping write to the original one. Error returned only if all reads have failed. -- Alexander Motin From owner-freebsd-geom@FreeBSD.ORG Fri May 11 12:59:32 2012 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F115B106566B; Fri, 11 May 2012 12:59:32 +0000 (UTC) (envelope-from kpielorz_lst@tdx.co.uk) Received: from mail.tdx.com (mail.tdx.com [62.13.128.18]) by mx1.freebsd.org (Postfix) with ESMTP id 6C8AF8FC19; Fri, 11 May 2012 12:59:32 +0000 (UTC) Received: from OctaHexa64-MkII (HPQuadro64.dmpriest.net.uk [62.13.130.30]) (authenticated bits=0) by mail.tdx.com (8.14.3/8.14.3) with ESMTP id q4BCxUI4043077 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Fri, 11 May 2012 13:59:31 +0100 (BST) Date: Fri, 11 May 2012 13:59:35 +0100 From: Karl Pielorz To: Alexander Motin Message-ID: In-Reply-To: <4FACF8BA.4020500@FreeBSD.org> References: <4FABDE10.8090304@FreeBSD.org> <61CDA17B687F1C733EE1B017@OctaHexa64-MkII> <4FACF8BA.4020500@FreeBSD.org> 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 Cc: freebsd-geom@FreeBSD.org Subject: Re: FreeBSD 9-R amd64 - graid, should it survive 'pulling' a disk? 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, 11 May 2012 12:59:33 -0000 --On 11 May 2012 14:32 +0300 Alexander Motin wrote: > Yes, sometimes bubble and in rare cases panic. I am working on the first > part right now. > >> Is the same true for reads? > > No, On read error graid repeats reading from another disk and does > remapping write to the original one. Error returned only if all reads > have failed. Ok, thanks for the explanation - if you need anything testing, do let me know, as it's obviously a pretty big issue for us [and probably others] :) -Karl From owner-freebsd-geom@FreeBSD.ORG Fri May 11 13:24:00 2012 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 399291065672 for ; Fri, 11 May 2012 13:24:00 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id E04628FC1E for ; Fri, 11 May 2012 13:23:59 +0000 (UTC) Received: by yenl8 with SMTP id l8so3388474yen.13 for ; Fri, 11 May 2012 06:23:59 -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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Uvydw004yCty/MpHXBdgi1sM9yCvV/fTudHlweP8q5s=; b=w1OzD1iOnPDYQGHtBybKOJq1mR8cKRBMWItSsXDlwRW9P38VQUTRKGT2CzuasrHrmS Ya50Ksy088nVwZW0CZgJ6yr1PsT3Q3mXSrLq2Lwyli3bubfXbrIm7z/0pooZHaOZwztn nZdEWmJhfOMfi9DoF/khWh+N+RDkXt3gRqnMSRSX/LK0tsYfu71DPJfmMTVrkD6TY24U UOLoP4QK8Nqz49NLkbn/bKWyAAEK8rKAjX5EEFRfS73mbeeOwyhEvBjDbzlORlQFfzab 4hOwQmynPiEU49plm0lf7zfiGjbkW05R5pGBKEbNDBmEo8YIT86Ez4Y9zOhm/tKvK3+y 3y2A== Received: by 10.50.216.167 with SMTP id or7mr1674506igc.32.1336742639071; Fri, 11 May 2012 06:23:59 -0700 (PDT) Received: from mavbook.mavhome.dp.ua ([24.114.252.240]) by mx.google.com with ESMTPS id re5sm3438737igb.0.2012.05.11.06.23.57 (version=SSLv3 cipher=OTHER); Fri, 11 May 2012 06:23:58 -0700 (PDT) Sender: Alexander Motin Message-ID: <4FAD12E3.3000608@FreeBSD.org> Date: Fri, 11 May 2012 16:23:47 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120116 Thunderbird/9.0 MIME-Version: 1.0 To: Karl Pielorz References: <4FABDE10.8090304@FreeBSD.org> <61CDA17B687F1C733EE1B017@OctaHexa64-MkII> <4FACF8BA.4020500@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-geom@FreeBSD.org Subject: Re: FreeBSD 9-R amd64 - graid, should it survive 'pulling' a disk? 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, 11 May 2012 13:24:00 -0000 On 11.05.2012 15:59, Karl Pielorz wrote: > > --On 11 May 2012 14:32 +0300 Alexander Motin wrote: > >> Yes, sometimes bubble and in rare cases panic. I am working on the first >> part right now. >> >>> Is the same true for reads? >> >> No, On read error graid repeats reading from another disk and does >> remapping write to the original one. Error returned only if all reads >> have failed. > > Ok, thanks for the explanation - if you need anything testing, do let me > know, as it's obviously a pretty big issue for us [and probably others] :) I've committed patch to the HEAD branch: http://svn.freebsd.org/changeset/base/235270 It should cleanly apply to 8/9-STABLE. -- Alexander Motin