主要参考资料
ZFS L2ARC (Brendan Gregg) (2008-07-22) 和ZFS 和混合存储概念（Anatol Studler 的博客） (2008-11-11) 包括下图：
问题
我是否应该将垂直白线（在 SSD 层）解释为使用单独SSD 的偏好 –
- 不喜欢在单个磁盘上混合使用 L2ARC 和 ZIL？
背景（对评论的回应）
就个人而言，在家里我不太可能将 L2ARC 或 ZIL 与我可用的任何计算机一起使用。（我的日常电脑是 MacBookPro5,2，8 GB 内存和混合希捷 ST750LX003-1AC154。没有计划用 SSD 替换光驱。）
在其他地方：在工作中会有一些工具包的再利用，但我没有日期或完整的细节。（混合使用 Xserve RAID x2 ……目前我不打算将它们提供给 ZFS，但我保持开放的心态。）
我对 L2ARC 和 ZIL 的SSD 最佳实践的好奇心始于 ZEVO 区域中与性能相关的讨论——特别是下面提到的主题，用户在单个磁盘上同时拥有 L2ARC 和 ZIL。
其他参考和讨论
L2ARC 截图 (Brendan Gregg) (2009-01-30)
SLOG 截图 (Brendan Gregg) (2009-06-26)
[zfs-discuss] ZFS 根备份/“灾难”恢复和移动根池(2011-01-10) 建议不要在单个磁盘上混合使用三种东西（根池、ZIL 和 L2ARC）——
…不值得在同一磁盘上管理所有 3 个时可能发生的头痛。例如，如果您决定重新安装并不小心破坏了数据池的 ZIL 内容。不要为池组件或跨池共享磁盘以保持管理和恢复简单。……
– 我更感兴趣的是是否建议不要将其中两个东西混合在一个磁盘上。
https://superuser.com/a/238744/84988 (2011-01-28) 提到“缓存（L2ARC 缓存）并将日志（ZIL）写入 SSD”（单数）。但是，由于它与 FUSE 和 Windows 相关，因此我不认为该答案与 ZFS 的更常见和注重性能的使用特别相关。
@ChrisS在 2011 年 8 月16 日的通讯室中提到了 ZIL 和 L2ARC。
http://forums.macrumors.com/showpost.php?p=14248388 (2012-01-31) 讨论了多个SSD：
关于 ZFS 您需要了解的一些事情：它有两种不同类型的缓存，读取和写入（L2ARC 和 ZIL），通常位于 SSD 上。ZIL 是写缓存。这可能就是这种误解的来源。ZIL 会随着对 zpool 的每次写入而受到重创（假设是一个活动系统）。问题是使用基于 mlc 的 SSD 作为 ZIL 会导致它们很快磨损和失效。您需要一个（贵得多的）基于 slc 的 SSD 用作 ZIL 驱动器。
拥有一个完全由 SSD 组成的 zpool 不仅是可能的，而且效果很好。它还基本上消除了为 ZIL 和 L2ARC 使用单独驱动器的需要。是的，您没有 TRIM 支持，但基于 ZFS 的写时复制特性，这可能是一件好事。
话虽如此，ZFS 在几乎已满（比如 85% 或更高）的 zpools 下表现不佳。性能开始显着下降 - 无论您使用的是旋转磁介质还是固态介质。缺少 TRIM 支持可能会加剧该问题，但这已经是一个问题。
https://serverfault.com/a/397431/91969 (2012-06-11) 建议：
- ZIL 的 SLC 类型 SSD（特别不是 MLC）
- L2ARC 的 MLC 型 SSD。
https://superuser.com/a/451145/84988 (2012-07-19) 提到了一个单一的“SSD for ZIL and L2ARC to speed up ZFS”。
zevo.getgreenbytes.com • 查看主题 - FW800 连接顺序的性能问题？(2012-09-24) 关注带有用于 ZIL 和 L2ARC的单个SSD 的 FireWire 总线上的事物顺序
- 除了总线顺序，ZEVO 话题让我开始怀疑单独的 SSD 是否更可取。
更具体地说：我想知道上图中白线的解释......
简短的回答，因为我看不出你要解决什么问题......
如果可以，请使用单独的设备。这取决于您的环境规模……如果它只是一个简单的家庭系统或虚拟化或一体化 ZFS 解决方案，您可以使用单个设备。
在更大或高性能的 ZFS 解决方案中，我使用专门适合其 ZIL 或 L2ARC 角色的设备……例如，用于 ZIL 的STEC ZeusRAM或DDRDrive以及用于 L2ARC 的任何企业 SLC 或 MLC SAS SSD。
你在做什么？
从一开始就存在一些关于 ZIL 的基本误解，需要在继续之前加以纠正。
理解这一点：在“正常”情况下，不会触及 ZIL/SLOG。
它仅在命令同步写入或在特定池/数据集上启用 sync=always 时写入（“zfs get sync pool/dataset”）
在正常情况下从不读取 ZIL。这是一个灾难恢复功能。
IE：ZIL 仅在断电时存在。它用于重播在数据提交到池之前已确认回操作系统的数据。所有 ZFS 写入池（同步或异步）都来自内存缓冲区。
在正常情况下，一旦数据到达池中，slog 条目就可以消失——它只是一个很大的循环写入缓冲区，不需要很大（在大多数情况下，即使 1GB 也太大了）
非同步写入在 ram 中缓冲，整理并在适当的时候写入磁盘。如果电源关闭，数据丢失但 FS 完整性得以保持（这就是您可能想要设置 sync=always 的原因）
另一方面，L2ARC 在读取和写入级别都受到重创。
存在“太多 l2arc”之类的东西，因为 l2arc 中的元数据来自您的 ARC ram（即，如果您增加 l2arc 大小，则必须增加 ram 以适应。不这样做会导致严重的性能下降和最终 l2arc 的使用将稳定在远低于“所有可用空间”的某个水平
尽管一些制造商提出抗议，但您不能通过增加 l2arc 大小来弥补内存不足（一些分支到 ZFS 设备的硬件 raid 阵列制造商已经做出了这种假设）
tl;dr：如果您的 IO 负载是数据库活动，那么 ZIL 很可能会受到猛烈抨击。如果是别的，那很可能只会轻轻碰一下。很有可能在 99.9% 的活动中，ZIL 函数永远不会启动。
知道这一点后，您就可以决定是否需要 ZIL 的 SLOG 分区，它是否可以与 l2arc 分区共存，或者它是否需要独立驱动器（以及独立驱动器应该达到什么性能级别）。