[zfs-discuss] Single SSD or raidz with L2arc for zfs root pool

Schlacta, Christ aarcane at aarcane.org
Thu Oct 31 10:05:30 EDT 2013


I had mirrored usb root on one system for less than a year with low write
throughput, and the uptime alone killed both drives. Be wary of this
solution.
On Oct 31, 2013 5:09 AM, "Gregor Kopka" <gregor at kopka.net> wrote:

>
> Am 31.10.2013 08:46, schrieb Ivan Krutskikh:
>
>> Hi all.
>>
>> I'm deploying a number of zfs-based storage servers focused on sequential
>> writes (video surveillance) with a single ssd and a raidz2 group of 6-7
>> HDD's
>>
>> Basically, I have 2 options for my root zfs dataset:
>>
>> 1)place one the whole zpool on second partition on the ssd.
>>  pro: faster, writes and reads are separated on different devices
>> cons: single point of failure. underused- the zfs partition with os
>> consumes about 4G, compared to 80G ssd
>>
>> 2) place everything on raidz2, boot from first partition of ssd, attach
>> the second one as l2arc to raidz2.
>> pro: safer (no single point of failure), better utilized.
>> cons: more complex setup, possible degradations on resilver events,
>> longer bootup time.
>>
>> Which way should I go?
>>
>
> With video streams you'll most likely have a relatively constant write
> load on the pool, if L2ARC makes sense depends on how (and if) the data is
> read back + how much RAM you have to hold metadata (so you won't have the
> impact of zfs seeking it), using the SSD as ZIL might make sense in case
> you have bursty writes or need to buffer the performance impact of read
> spikes - but the only way to find a good .
>
> Since the rpool should be fairly static, small and most likly idle after
> boot you could as well partition off a bit from each HDD for a mirrored
> rpool to have redundancy to boot from, but should you really need to reboot
> quickly to not let evildoers (or whatever you're taping) escape: add (a)
> fast USB3 stick(s) as mirror(s) to the SSD rpool for cheap redundancy - or
> mirror the rpool over USB sticks in the first place so you can do away with
> the SSD should you please.
>
> Gregor
>
> To unsubscribe from this group and stop receiving emails from it, send an
> email to zfs-discuss+unsubscribe@**zfsonlinux.org<zfs-discuss%2Bunsubscribe at zfsonlinux.org>
> .
>

To unsubscribe from this group and stop receiving emails from it, send an email to zfs-discuss+unsubscribe at zfsonlinux.org.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.zfsonlinux.org/pipermail/zfs-discuss/attachments/20131031/155bf14d/attachment.html>


More information about the zfs-discuss mailing list