Date: Wed, 19 Aug 2015 19:29:54 +0300 From: Daniel Kalchev <daniel@digsys.bg> To: PK1048 <paul@pk1048.com> Cc: FreeBSD Filesystems <freebsd-fs@freebsd.org>, javocado <javocado@gmail.com> Subject: Re: Optimizing performance with SLOG/L2ARC Message-ID: <6EAEF15E-03B0-4C75-B252-FE56DEA38DA2@digsys.bg> In-Reply-To: <3FE10173-656C-4744-AB2D-32148A34CB46@pk1048.com> References: <CAP1HOmTidC3%2BG4XfhvkQxieo%2BSYMq-JWiXF9Cs4FSW2VqkktWA@mail.gmail.com> <023F881D-CCC5-4FCA-B09D-EB92C3BFBC03@pk1048.com> <CALeZrrRex43B6N7GkTtaP36v5q7mQF8U9V1bU2W1%2B2uh8fhhiQ@mail.gmail.com> <3FE10173-656C-4744-AB2D-32148A34CB46@pk1048.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 19.08.2015 =D0=B3., at 19:10, PK1048 <paul@pk1048.com> wrote: >=20 > On Aug 19, 2015, at 12:02, Schweiss, Chip <chip@innovates.com> wrote: >=20 >> ZFS doesn't play well with the >> ZIL on the pool with SSDs. Even an SSD of the same type as the pool >> devices as the log device will fix the latency problem and throughput >> problems. >=20 > If your load is sync writes then you decidedly want a LOG device, even = if it is the same type as the devices in the pool. For the reasons = others have posted. >=20 This is because of the reason I mentioned earlier. When you don=E2=80=99t = have separate SLOG, ZFS will allocate the ZIL record from the pool = blocks, then when the blocks are at their intended location, delete that = ZIL record from the pool. This plays bad with SSDs. You also get much = fragmentation. When you have SLOG, ZFS will write the ZIL record to the SLOG, then = (batch) write the blocks to their intended place, then forget about the = SLOG (it=E2=80=99s not freed, just overwritten). This plays much better = with SSDs. You should get much better performance, with pure-SSD pool, if you = allocate small portion of the same SSD for SLOG. I know it sounds = counderintuitive. :) Of course, much better performance with separate SSD for the SLOG. Daniel
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6EAEF15E-03B0-4C75-B252-FE56DEA38DA2>