Date: Fri, 1 Jul 2016 20:23:54 +0200 From: Ben RUBSON <ben.rubson@gmail.com> To: freebsd-fs@freebsd.org Subject: Re: HAST + ZFS + NFS + CARP Message-ID: <E9A65461-CD42-4CBD-9C22-87E1B9D5A4EA@gmail.com> In-Reply-To: <FD296976-0250-4DA7-BB56-68F43B62C19B@ixsystems.com> References: <20160630144546.GB99997@mordor.lan> <71b8da1e-acb2-9d4e-5d11-20695aa5274a@internetx.com> <AD42D8FD-D07B-454E-B79D-028C1EC57381@gmail.com> <20160630153747.GB5695@mordor.lan> <63C07474-BDD5-42AA-BF4A-85A0E04D3CC2@gmail.com> <678321AB-A9F7-4890-A8C7-E20DFDC69137@gmail.com> <20160630185701.GD5695@mordor.lan> <FD296976-0250-4DA7-BB56-68F43B62C19B@ixsystems.com>
index | next in thread | previous in thread | raw e-mail
> On 01 Jul 2016, at 19:54, Jordan Hubbard <jkh@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. As you experienced iSCSI, any sad story with iSCSI disks given to ZFS ? Many thanks for your long feedback Jordan !home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E9A65461-CD42-4CBD-9C22-87E1B9D5A4EA>