Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 29 Nov 2013 20:35:20 -0000
From:      "Steven Hartland" <killing@multiplay.co.uk>
To:        <krichy@cflinux.hu>, <freebsd-scsi@freebsd.org>
Subject:   Re: Fwd: Re: ssd for zfs
Message-ID:  <EA212CF8655D4EA6BD6AF9019470E5DE@multiplay.co.uk>
References:  <0b12c19b8832c72369ff7244d7231846@cflinux.hu> <81b87ca49aef7d88db1b4dbd5f7eb201@cflinux.hu> <923bc6b4aa9141e5e9a49ab76b3a18b5@cflinux.hu>

next in thread | previous in thread | raw e-mail | index | archive | help
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: <krichy@cflinux.hu>
To: <freebsd-scsi@freebsd.org>
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.




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?EA212CF8655D4EA6BD6AF9019470E5DE>