I am starting to believe this is a compatibility problem with VMWare ESXi and
OpenSolaris. Why would the initiator time out constantly in middle of large
transfers if this would be simple performance problem at the target. I will try
with Windows as initiator to rule this possibility out.
What I do not understand is the "large" (compared to the time when writes do
happen) amount of read ops at the time the transfer stalls:
@fs1:~$ zpool iostat pool 2
capacity operations bandwidth
pool alloc free read write read write
---------- ----- ----- ----- ----- ----- -----
pool 485G 6.34T 45 1.11K 161K 8.41M
pool 485G 6.34T 175 0 407K 0
pool 485G 6.34T 186 0 431K 0
pool 485G 6.34T 159 0 383K 0
pool 485G 6.34T 153 0 376K 0
Should take this issue to VMWare forums probably?
> There was a change in recent-ish builds where iSCSI
> traffic began to
> be treated as synchronous rather than async.
I believe this started in 2009.06? During a previous installation I had
upgraded to dev build 130 or so (already forget what I used back then, maybe
2-3 months ago) and had no problems, in fact I was amazed at the speed cheap
consumer quality hardware could deliver.
> If you
> don't have a slog
> device, this will impact performance. Check your zil
> usage, or disable
> the zil and see if it helps.
No slog device since it is a cheap whitebox.
Using the zilstat.ksh I see mostly only zeroes and only rarely some activity..
(?)
>
> Also make sure wcd is set to false in COMSTAR to
> enable write caching.
>
Same with wcd=false
> > At first I tried with dedup turned on, but the
> initiator constantly losed connection to the target
> due to timeouts and was completely unusable - maybe
> the CPU at target (Core 2 Duo E8400) could not
>
> Dedup is usually limited by memory at the target.
> Adding a L2ARC can help.
>
I don't see the connection between memory limitations and initiator timing
out/CPU being completely bogged down, but I am by no means an expert with
OpenSolaris.
L2ARC is impossible due to budget constraints unfortunately. What would be
considered "enough" RAM?
Thanks,
V
> -B
>
> --
> Brandon High : bh...@freaks.com
> _______________________________________________
> storage-discuss mailing list
> storage-discuss@opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/storage-d
> iscuss
>
--
This message posted from opensolaris.org
_______________________________________________
storage-discuss mailing list
storage-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
