Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 29 Nov 2013 21:17:50 +0100
From:      krichy@cflinux.hu
To:        freebsd-scsi@freebsd.org
Subject:   Re: Fwd: Re: ssd for zfs
Message-ID:  <923bc6b4aa9141e5e9a49ab76b3a18b5@cflinux.hu>
In-Reply-To: <81b87ca49aef7d88db1b4dbd5f7eb201@cflinux.hu>
References:  <0b12c19b8832c72369ff7244d7231846@cflinux.hu> <81b87ca49aef7d88db1b4dbd5f7eb201@cflinux.hu>

next in thread | previous in thread | raw e-mail | index | archive | help
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?

Thanks in advance,

2013-11-29 15:52 időpontban krichy@cflinux.hu ezt írta:
> Dear Devs,
> 
> Regarding my problem, is that possible that the device honours the
> SYNCHRONIZE_CACHE  command slowly? Just because linux and bsd detects
> its cache setting as disabled
> when attaching it to the system. Is that possible that when linux
> detects it has no write-cache, it skips SYNCHRONIZE_CACHE commands? By
> the way, the SSD still does not lose any data
> with this behaviour according to tests.
> 
> Thanks in advance,
> 
> 2013-11-27 15:14 időpontban krichy@cflinux.hu ezt írta:
>> -------- Eredeti üzenet --------
>> Tárgy: Re: ssd for zfs
>> Dátum: 2013-11-27 14:07
>> Feladó: Richard Kojedzinszky <krichy@cflinux.hu>
>> Címzett: Tom Evans <tevans.uk@googlemail.com>
>> Másolat: FreeBSD FS <freebsd-fs@freebsd.org>
>> 
>> Dear FS devs,
>> 
>> After some investigation, it turned out that when I turn write-cache
>> off under linux, the performance drops to 100 on that OS also. But
>> when enabled, 1400 IOPS (synchronous) can be achieved. So I would like
>> to see the same on FreeBSD as well. Using camcontrol shows that the
>> write cache is enabled, but I may assume that something around this is
>> causing the performance degradation. But unfortunately I cannot step
>> forward right now.
>> 
>> Regards,
>> 
>> Kojedzinszky Richard
>> 
>> On Wed, 27 Nov 2013, Tom Evans wrote:
>> 
>>> On Wed, Nov 27, 2013 at 8:51 AM, Richard Kojedzinszky 
>>> <krichy@cflinux.hu> wrote:
>>>> Dear fs developers,
>>>> 
>>>> Probably this is not the best list to report my issue, but please 
>>>> forward it
>>>> to where it should get.
>>>> 
>>>> I bought an SSD for my ZFS filesystem to use it as a ZIL. I've 
>>>> tested it
>>>> under linux, and found that it can handle around 1400 random 
>>>> synchronized
>>>> write IOPS. Then I placed it into my freebsd 9.2 box, and after 
>>>> attaching it
>>>> as a ZIL, my zpool only performs 100 (!) write iops. I've attached 
>>>> it to an
>>>> AHCI controller and to an LSI 1068 controller, on both it behaves 
>>>> the same.
>>>> So I expect that something in the scsi layer is different, FreeBSD 
>>>> is
>>>> handling this device slower, but actually it can handle the 1400 
>>>> iops as
>>>> tested under linux.
>>>> 
>>>> Please give some advice where to go, how to debug, and how to 
>>>> improve
>>>> FreeBSD's performance with this drive.
>>>> 
>>> 
>>> The ZIL is only used for synchronous writes. The majority of writes
>>> are asynchronous, and the ZIL is not used at all. Plus, a ZIL can 
>>> only
>>> increase iops by bundling writes - if your underlying pool is write
>>> saturated already, then a ZIL can't help - any data written to the 
>>> ZIL
>>> has to end up on the pool.
>>> 
>>> Test the SSD by itself under FreeBSD to rule out FreeBSD not working
>>> correctly on the SSD (I doubt this though).
>>> 
>>> Cheers
>>> 
>>> Tom
>>> 



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