From owner-freebsd-scsi@FreeBSD.ORG Fri Nov 29 20:35:41 2013 Return-Path: Delivered-To: freebsd-scsi@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 7C384667 for ; Fri, 29 Nov 2013 20:35:41 +0000 (UTC) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1764E1E3B for ; Fri, 29 Nov 2013 20:35:28 +0000 (UTC) Received: from r2d2 ([82.69.179.241]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50006875075.msg for ; Fri, 29 Nov 2013 20:35:27 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Fri, 29 Nov 2013 20:35:27 +0000 (not processed: message from valid local sender) X-MDDKIM-Result: neutral (mail1.multiplay.co.uk) X-MDRemoteIP: 82.69.179.241 X-Return-Path: prvs=10451ca0e0=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-scsi@freebsd.org Message-ID: From: "Steven Hartland" To: , References: <0b12c19b8832c72369ff7244d7231846@cflinux.hu> <81b87ca49aef7d88db1b4dbd5f7eb201@cflinux.hu> <923bc6b4aa9141e5e9a49ab76b3a18b5@cflinux.hu> Subject: Re: Fwd: Re: ssd for zfs Date: Fri, 29 Nov 2013 20:35:20 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2013 20:35:41 -0000 You could add a DA_Q_NO_SYNC_CACHE quirk for you device which will prevent the cam layer attempting to call sync but this will only work if its attached to a SCSI controller like an LSI there's no such quirk currently implemented in ATA cam layer. Regards Steve ----- Original Message ----- From: To: Sent: Friday, November 29, 2013 8:17 PM Subject: Re: Fwd: Re: ssd for zfs > Dear scsi-devs, > > It seems that my device handles the flush commands slowly. The linux > code avoids issuing this if the device reports its write cache is turned > off. That way my SSD works fast under linux, but infortunately slow > under FreeBSD. Actually I dont understand why is it slow for the flush > command, as it has power-loss-protection, maybe for such a command it > really flushes everything out, dont know. But when I enable the write > cache in linux also, the block layer gets knowledge of the write cache, > it issues the flush commands, and it gets same slow. > > How could this be solved? ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk.