Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 29 Nov 2013 22:07:10 +0100 (CET)
From:      Richard Kojedzinszky <krichy@cflinux.hu>
To:        Steven Hartland <killing@multiplay.co.uk>
Cc:        freebsd-scsi@freebsd.org
Subject:   Re: Fwd: Re: ssd for zfs
Message-ID:  <alpine.BSF.2.00.1311292203140.28407@pi.nmdps.net>
In-Reply-To: <EA212CF8655D4EA6BD6AF9019470E5DE@multiplay.co.uk>
References:  <0b12c19b8832c72369ff7244d7231846@cflinux.hu> <81b87ca49aef7d88db1b4dbd5f7eb201@cflinux.hu> <923bc6b4aa9141e5e9a49ab76b3a18b5@cflinux.hu> <EA212CF8655D4EA6BD6AF9019470E5DE@multiplay.co.uk>

next in thread | previous in thread | raw e-mail | index | archive | help
Dear Steve,

Thanks, I've already did that, but as you've mentioned, that is not a 
possible solution for an ata controller. And what if one enables the write 
cache on a device, than probably flush commands should be issued to 
guarantee consistency.

What if FreeBSD would handle flushing as linux, ie keep track of current 
write cache setting, and if that is disabled for a drive, simply ignore 
flush commands? This could be implemented for ata and scsi drives, or in 
the geom layer.

Regards,

Kojedzinszky Richard

On Fri, 29 Nov 2013, Steven Hartland wrote:

> 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?alpine.BSF.2.00.1311292203140.28407>