freebsd-scsi Digest, Vol 358, Issue 5
freebsd-sc...@freebsd.org
freebs...@freebsd.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freebsd.org/mailman/listinfo/freebsd-scsi
or, via email, send a message with subject or body 'help' to
freebsd-sc...@freebsd.org
You can reach the person managing the list at
freebsd-s...@freebsd.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of freebsd-scsi digest..."
Today's Topics:
1. Re: How is supposed to be protected the units list?
(Matthew Jacob)
2. Re: performance tuning of iSCSI and Dell MD3000i / gjournal
problem (Daisuke Aoyama)
3. Re: How is supposed to be protected the units list? (Attilio Rao)
4. Re: How is supposed to be protected the units list? (Attilio Rao)
----------------------------------------------------------------------
Message: 1
Date: Thu, 04 Mar 2010 12:12:09 -0800
From: Matthew Jacob <m...@feral.com>
Subject: Re: How is supposed to be protected the units list?
To: freebs...@freebsd.org
Message-ID: <4B901419...@feral.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
The referred to patch at least got me out of panic case :-)..
http://people.freebsd.org/~mjacob/scsi_da.c.patch
------------------------------
Message: 2
Date: Fri, 5 Mar 2010 07:20:45 +0900
From: "Daisuke Aoyama" <aoy...@peach.ne.jp>
Subject: Re: performance tuning of iSCSI and Dell MD3000i / gjournal
problem
To: "Miroslav Lachman" <000....@quip.cz>, <freebs...@freebsd.org>
Cc: ivo...@freebsd.org
Message-ID: <96BBFBFE5763434E8F65D8C503BABB2C@artemis>
Content-Type: text/plain; format=flowed; charset="iso-8859-2";
reply-type=response
Hi,
> And ZFS on iSCSI is the worst case with 5MB/s write performance! (I have
> much better experiences with ZFS on RAIDZ pool of 4 SATA drives)
I'm not sure but FreeBSD initiator does not support immediate operation.
(ImmediateData=Yes)
If the target supports it, the initiator can send data with the command
up to the size in small one of FirstBurstLength and
MaxRecvDataSegmentLength.
Also the initiator can send more data up to FirstBurstLength if the target
supports unsolicited operation. (InitialR2T=No)
It will improve small writing performance and latency.
In any case, each PDU must not exceed the target's MaxRecvDataSegmentLength.
See RFC3720 page 213 and 217 for example of the sequence.
http://tools.ietf.org/html/rfc3720#page-213
http://tools.ietf.org/html/rfc3720#page-217
If possible, try to increase MaxBurstLength both of the initiator and the
target.
It will decrease the number of R2T. Therefore, large writing is faster.
Regards,
Daisuke Aoyama
------------------------------
Message: 3
Date: Fri, 5 Mar 2010 02:33:57 +0100
From: Attilio Rao <att...@freebsd.org>
Subject: Re: How is supposed to be protected the units list?
To: Alexander Motin <m...@freebsd.org>
Cc: freebs...@freebsd.org, "Justin T. Gibbs" <gi...@freebsd.org>,
Matthew Jacob <m...@feral.com>
Message-ID:
<3bbf2fe11003041733x532...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
2010/3/4 Alexander Motin <m...@freebsd.org>:
> Hi.
>
> Attilio Rao wrote:
>> 2010/3/1 Attilio Rao <att...@freebsd.org>:
>>> I have a question that I've been unable to reply reading the code.
>>> Someone could point me to documentation explaining how the unit tailq
>>> (within a struct periph_driver) is supposed to be locked?
>>> I'm not sure how it is assured consistency of accesses to the list and
>>> more important how is ensured that the periphs composing it doesn't go
>>> away as I don't see any reference bump for objects inserted there.
>
> I am not sure that existing implementation is complete, but at least in
> some places it is protected by xpt_lock_buses(), which is wrapper for
> mtx_lock(&xsoftc.xpt_topo_lock). camperiphfree() called under the lock,
> same as many (all?) traverses.
Initially I thought about using xpt_lock_buses() but then I regret in
order to avoid any unconvenient LOR.
Using a new lock would decrease the chances to see this happening.
>> I don't think the lists are protected at all so I made this simple
>> patch taking advantage by a global lock:
>> http://www.freebsd.org/~attilio/Sandvine/pdrv/pdrv_lock.diff
>>
>> The patch is simple enough but I just test-compiled it (will need some
>> time to run in a debugging kernel, hope to do tonight) and maybe you
>> can already give your opinions here.
>
> It is not obvious to me, how your new lock expected to interoperate with
> existing xpt_topo_lock. I have feeling that it duplicates one in some
> places. If you believe that second lock is needed there, then probably
> first one should be partially removed. But then we should be careful to
> not create LORs between them, as they are not natively nested.
>
> Changes in cam_xpt.c break splbreaknum meaning of temporary dropping
> xpt_topo_lock. I have doubts whether it is required now at all now, but
> leaving dead code it definitely not good.
If you think that using xpt_topo_lock in all the other places
accessing units that don't do right now is suitable and safe I'm fine
with it. Otherwise the new global lock should be fine I assume.
Thanks,
Attilio
--
Peace can only be achieved by understanding - A. Einstein
------------------------------
Message: 4
Date: Fri, 5 Mar 2010 02:37:23 +0100
From: Attilio Rao <att...@freebsd.org>
Subject: Re: How is supposed to be protected the units list?
To: m...@feral.com
Cc: freebs...@freebsd.org
Message-ID:
<3bbf2fe11003041737p306...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
2010/3/4 Matthew Jacob <m...@feral.com>:
> The referred to patch at least got me out of panic case :-)..
>
>
> http://people.freebsd.org/~mjacob/scsi_da.c.patch
Yes, honestly the main intent of this patch is to offer a stable
ground for correct handling of periph. When looking about refcounting
them correctly, the main problem is that there was no initial
condition assuring safety, and the initial patch should address this,
but I'm sure there are places where periph refcount is not handled
correctly and this may be one.
Thanks,
Attilio
PS: Sorry for late responses since now, but I'm mostly away.
--
Peace can only be achieved by understanding - A. Einstein
------------------------------
End of freebsd-scsi Digest, Vol 358, Issue 5
********************************************