From owner-freebsd-questions@FreeBSD.ORG Fri Jun 19 08:41:44 2015 Return-Path: Delivered-To: freebsd-questions@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D4DEA836 for ; Fri, 19 Jun 2015 08:41:44 +0000 (UTC) (envelope-from freebsd-questions@herveybayaustralia.com.au) Received: from mail.unitedinsong.com.au (mail.unitedinsong.com.au [150.101.178.33]) (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 8966FC44 for ; Fri, 19 Jun 2015 08:41:44 +0000 (UTC) (envelope-from freebsd-questions@herveybayaustralia.com.au) Received: from laptop2.herveybayaustralia.com.au (laptop2.herveybayaustralia.com.au [192.168.0.185]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.unitedinsong.com.au (Postfix) with ESMTPSA id EC875620A0 for ; Fri, 19 Jun 2015 18:41:34 +1000 (EST) Message-ID: <5583D5BE.7050508@herveybayaustralia.com.au> Date: Fri, 19 Jun 2015 18:41:34 +1000 From: Da Rock User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: freebsd-questions@freebsd.org Subject: Re: ZFS passdevgonecb References: <557F90DB.80601@herveybayaustralia.com.au> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2015 08:41:45 -0000 Ok, top posting as a summary really - numerous threads of thought going on now. First, that ggatel and mountver workaround - how does zfs take that? Is it possible zfs will have a dummy spit if this is between it writing to the drive? I'd assume not given it can use a md device as a vnode, but doesn't hurt to ask. Second, I've tried another drive and still the same issue; also.swapped cable, and still errors. So a controller test would be ideal - or a new system is in order :) Third, that consumer/raid drive difference seems a bit dodgy doesn't it? :) Appears they're basically forcing you to pay up for the privilege... wouldn't surprise me! Regardless, though, how does that stack up in an ordinary situation? I doubt you'd have a raid certified drive in a desktop to play games or edit home movies, and in that scenario it would spak out as the only drive in the system and probably crash, wouldn't it? Or am I not thinking it through properly? Possible given the amount of sleep I've had lately... Thanks for the brainstorming help guys. On 06/18/15 05:24, Michael Powell wrote: > Da Rock wrote: > >> I hate jumping in like this out of the blue, but time is not on my side >> atm with a lot going on. >> >> I have a problem with some devices disappearing on various versions of >> FreeBSD and machines (laptops, workstations/servers). Umass are the >> norm, with the message occurring most on usb sticks and sd cards. >> >> Big problem atm is that my file server has a failed disk in the raid, >> and I've tried replacing it with a new drive (twice now), and both times >> it begins to resilver and then it is "REMOVED". If I online it again, it >> goes for about 10mins then REMOVED again. >> >> Dmesg shows that the device is removed from the devfs with a >> passdevgonecb/lost device message. This apparently occurs right at boot >> too, as it shows amongst the usual scrolling during boot. >> >> I had a chat with someone and they mentioned the cable and/or controller >> could be the issue. Could anyone add any insight or tests I could do? >> I'm not exactly claim to be an expert at zfs, so maybe something might >> need addressing there too. >> >> I'd particularly appreciate a means of testing the controller. >> >> ATM the main theory is to replace the board - not a happy thought! :/ >> > Another item to consider, even if only to exclude it, is: what kind of > drives are these? Are they server RAID certified or are they 'consumer' > desktop types. RAID certified are designed to time-limit attempts at error > recovery. There is a window in time that if a consumer drive takes too long > at internal ECC the controller will drop it. Doubt this is your case, I bet > you have server drives. I just mention it because using consumer desktop > drives on RAID controllers can sometimes be problematic. > > -Mike > > > > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org"