After a recent upgrade to b124, decided to switch to COMSTAR for iscsi targets for VirtualBox hosted on AMD64 Fedora C10. Both target and initiator are running zfs under b124. This combination seems unbelievably slow compared to the old iscsi subsystem. A scrub of a local 20GB disk on the target took 16 minutes. A scrub of a 20GB iscsi disk took 106 minutes! It seems to take much longer to boot from iscsi, so it seems to be reading more slowly too. There are a lot of variables - switching to Comstar, snv124, VBox 3.08, etc., but such a dramatic loss of performance probably has a single cause. Is anyone willing to speculate? Thanks -- Frank
On Tue, Oct 13, 2009 at 01:00:35PM -0400, Frank Middleton wrote:> After a recent upgrade to b124, decided to switch to COMSTAR for iscsi > targets for VirtualBox hosted on AMD64 Fedora C10. Both target and > initiator are running zfs under b124. This combination seems > unbelievably slow compared to the old iscsi subsystem. > > A scrub of a local 20GB disk on the target took 16 minutes. A scrub of > a 20GB iscsi disk took 106 minutes! It seems to take much longer to > boot from iscsi, so it seems to be reading more slowly too. > > There are a lot of variables - switching to Comstar, snv124, VBox > 3.08, etc., but such a dramatic loss of performance probably has a > single cause. Is anyone willing to speculate?Maybe this will help: http://mail.opensolaris.org/pipermail/storage-discuss/2009-September/007118.html -- albert chin (china at thewrittenword.com)
On 10/13/09 18:35, Albert Chin wrote:> > Maybe this will help: > http://mail.opensolaris.org/pipermail/storage-discuss/2009-September/007118.htmlWell, it does seem to explain the scrub problem. I think it might also explain the slow boot and startup problem - the VM only has 564M available, and it is paging a bit. Doing synchronous i/o for swap makes no sense. Is there an official way to disable this behavior? Does anyone know if the old iscsi system is going to stay around, or will COMSTAR replace it at some point? The 64K metadata block at the start of each volume is a bit awkward, too. - it seems to throw VBox into a tizzy when (failing to) boot MSWXP. The options seem to be a) stay with the old method and hope it remains supported b) figure out a way around the COMSTAR limitations c) give up and use NFS Using ZFS as an iscsi backing store for VirtualBox images seemed like a great idea, so simple to maintain and robust, but COMSTAR seems to have sand-bagged it a bit. The performance was quite acceptable before but it is pretty much unusable this way. Any ideas would be much appreciated Thanks -- Frank
Frank Middleton wrote:> On 10/13/09 18:35, Albert Chin wrote: >> >> Maybe this will help: >> http://mail.opensolaris.org/pipermail/storage-discuss/2009-September/007118.html > > Well, it does seem to explain the scrub problem. I think it might > also explain the slow boot and startup problem - the VM only has > 564M available, and it is paging a bit. Doing synchronous i/o for > swap makes no sense. Is there an official way to disable this > behavior? > > Does anyone know if the old iscsi system is going to stay around, > or will COMSTAR replace it at some point? The 64K metadata > block at the start of each volume is a bit awkward, too. - it seems > to throw VBox into a tizzy when (failing to) boot MSWXP.There are two options here, see stmfadm(1m) for details: If the backing store deviceis a ZFS ZVOL, then the metadata is stored in a special data object in the ZVOL rather than using the first 64K of the ZVOL. The command "stmfadm -o meta=/path/to/metadata-file create-lu /path/to/ backing/store" is used to specify a file-based location to store SBD metadata. This method can be used to upgrade old iSCSI Target Daemon backing storage devices to iSCSI Target COMSTAR, if the backing store device is not a ZVOL. Note: For ZVOL support, there is a corresponding ZFS storage pool change to support this functionality, so a "zpool upgrade ..." to version 16 is required: # zpool upgrade -v . . 16 stmf property support - Jim> > The options seem to be > > a) stay with the old method and hope it remains supported > > b) figure out a way around the COMSTAR limitations > > c) give up and use NFS > > Using ZFS as an iscsi backing store for VirtualBox images seemed > like a great idea, so simple to maintain and robust, but COMSTAR > seems to have sand-bagged it a bit. The performance was quite > acceptable before but it is pretty much unusable this way. > > Any ideas would be much appreciated > > Thanks -- Frank > > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20091019/f0cc71d1/attachment.html>