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>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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 =E2=80=9Cown = the disks=E2=80=9D 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 =E2=80=9C???=E2=80= =9D 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 !
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E9A65461-CD42-4CBD-9C22-87E1B9D5A4EA>