> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Jim Klimov
>
> A while back I've seen proposals on Linux kernel mailing lists to create
> RAID firmwares based on mdadm, and apparently some hardware
> vendors took to that. An added benefit for users was that RAID disks
> could be migrated between software and hardware RAID running same
> code, allowing for easier repairs, migrations and up/down-grades.
>
> Now, it is just a thought. But I wonder if it's possible... Or useful? :)
> Or if anyone has already done that?
Take for example, the new AES instruction set shipping in certain modern
CPU's. What they've done is adapted the hardware to perform the core tasks
of AES encryption/decryption more efficiently, that were formerly being done
in software, and hence gained significant performance improvements. Take
also, for example, the TCP Offload Engine, TOE. They moved some of the core
network processing (the TCP stack) onto the NIC processor in order to get it
away from the CPU, and gain performance in high-performance networks. I
would venture a guess there's probably some ZFS core operations that could
be offloaded onto an HBA processor. The question is what, and why? I
personally never see any ZFS performance bottleneck other than disk speeds
and bus speeds. (Neglecting dedup - dedup performance is still bad right
now.) Even if I have checksum=sha256, and compression enabled, I never see
anything that I would call significant processor utilization. Surely it's
possible in a really high end system, to eventually saturate the CPU cores
with checksum or compression operations or something...
There is one use I can imagine, which would be awesome. If you were able to
offload COW, and isolate it entirely standalone inside the HBA, then you
might be able to present the OS with basically just a zvol. So then you
could run linux, vmware, windows, or whatever... With snapshots and data
integrity and "zfs send" under the hood at the hardware level that the OS
doesn't need to know or care about. This is very similar to running solaris
(or whatever) as a hypervisor, and then running windows or linux or whatever
as a guest OS. It is also very similar to running iscsi targets on ZFS,
while letting some other servers use iscsi to connect to the ZFS server.
It's a cool way to inject a ZFS layer beneath the OS that doesn't support
ZFS. The purpose would not be performance gain, but functionality gain.
(Might be able to gain some performance, but I think it would be roughly
balanced with traditional hardware HBA's.)
I can't think of much other reason to do it...
Bear in mind, if doing something like this... Anyone other than oracle would
need to assess the possible legal risk of distributing ZFS. (Potential
netapp lawsuit.) You wouldn't necessarily need to do something like this
using ZFS. It is possible that btrfs or some other option might actually be
more attractive for such an embedded application. Also, finding engineers
to develop embedded linux is probably easier than finding engineers to
develop embedded ... whatever kernel you want to run ZFS on.
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
