HAST + ZFS + NFS + CARP

[Ben RUBSON]

> On 01 Jul 2016, at 20:23, Ben RUBSON <ben.rubson at gmail.com> wrote:
> 
> 
>> On 01 Jul 2016, at 19:54, Jordan Hubbard <jkh at ixsystems.com> wrote:
>> (...)
>> And yes, of course one can layer additional things on top of iSCSI LUNs, just as one can punch through LUNs from older SAN fabrics and put ZFS pools on top of them (been there, done both of those things), though of course the additional indirection has performance and debugging ramifications of its own (when a pool goes sideways, you have additional things in the failure chain to debug).  ZFS really likes to “own the disks” in terms of providing block-level fault tolerance and predictable performance characteristics given specific vdev topologies, and once you start abstracting the disks away from it, making statements about predicted IOPs for the pool becomes something of a “???” exercise.
> 
> Would you say that giving an iSCSI disk to ZFS hides some details of the raw disk to ZFS ?
> I though that iSCSI would have been a totally "transparent" layer, transferring all ZFS requests to the raw disk, giving back the answers, hiding anything.

From #openzfs :
A: typically iSCSI disks still appear as "physical" disks to the OS connecting to them. you can even get iSCSI servers that allow things like SMART pass-thru
Q: so ZFS will be as happy with iSCSI disks as if it used local disks ? or will it miss something ?
A: no, and ZFS isn't "unhappy" per se. but there are optimizations it applies when it knows the disks belong to ZFS only
Q: and using iSCSI disks, ZFS will not apply these optimizations (even if these iSCSI disks are only given to ZFS) ? ie, will ZFS know these iSCSI disks belong to ZFS only ?
A: if it looks like a physical disk, if it quacks like a physical disk...