From owner-freebsd-bugs@FreeBSD.ORG Wed Nov 27 23:40:02 2013 Return-Path: Delivered-To: freebsd-bugs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 50D1C3E9 for ; Wed, 27 Nov 2013 23:40:02 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3CF4F62A for ; Wed, 27 Nov 2013 23:40:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id rARNe1U6004881 for ; Wed, 27 Nov 2013 23:40:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id rARNe1dA004880; Wed, 27 Nov 2013 23:40:01 GMT (envelope-from gnats) Date: Wed, 27 Nov 2013 23:40:01 GMT Message-Id: <201311272340.rARNe1dA004880@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: info@ITSMexpert.EU Subject: Re: kern/184154: [cam] QUIRK: SYNC_CACHE not supported on IBM ServeRAID 8k X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list Reply-To: info@ITSMexpert.EU List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 23:40:02 -0000 The following reply was made to PR kern/184154; it has been noted by GNATS. From: info@ITSMexpert.EU To: mjacob@freebsd.org, bug-followup@freebsd.org Cc: Subject: Re: kern/184154: [cam] QUIRK: SYNC_CACHE not supported on IBM ServeRAID 8k Date: Thu, 28 Nov 2013 00:29:26 +0100 Just attempt to mount a ZFS pool on six RDM disks caused writing 13 error messages for each disk (78 error messages together, five line in dmesg each). The mount WAS NOT successful. ZFS uses SYNC_CACHE quite often (because of its principle), it can lead into significant performance degradation (if mounted). I can not tolerate such behaviour in production environment handling terabytes of archive data. I need to upgrade to 10.0 as soon as the STABLE version will be released. It seems I will have to patch and recompile kernel first. :-( On 27/11/2013 23:09, Matthew Jacob wrote: > Why do you think this is a serious error? All that the lack of this > command support does is cause the driver to be noisy. The device still > functions correctly, doesn't it? > > 10.X is frozen and won't be changed until after release.