Date: Mon, 17 Sep 2001 09:32:08 -0700 From: Steven Dake <sdake@mvista.com> To: "Timothy D. Witham" <wookie@osdlab.org> Cc: freebsd-fs@FreeBSD.ORG, opengfs-devel@lists.sourceforge.net Subject: Re: Porting a new filesystem to FreeBSD Message-ID: <3BA62588.20005@mvista.com> References: <3BA4B507.CC70ECD4@nipsi.de> <20010916140843.A21982@xor.obsecurity.org> <3BA52C79.E1E247F5@mindspring.com> <3BA5419F.BF0C3E70@nipsi.de> <3BA555D8.D2C53387@mindspring.com> <20010917084023.A13990@caldera.de> <3BA5AF53.EE87658F@mindspring.com> <2 <3BA5BDBC.107DC520@mindspring.com> <20010917113627.A28298@caldera.de> <3BA5C78B.FE14882@mindspring.com> <1000741723.15009.78.camel@wookie-laptop.pdx.osdl.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--------------020906060400000905040004
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Timothy D. Witham wrote:
>On Mon, 2001-09-17 at 02:51, Terry Lambert wrote:
>
>>Christoph Hellwig wrote:
>>
>>>>This disagrees with a discussion I had off list, as to the use
>>>>and availableility of DLOCK, and the firmness of the SCSI III
>>>>standard. The GFS people are using Matt Jacob's fiberchannel
>>>>driver, and a network based distributed lock manager.
>>>>
>>>DLOCK was GFS 3.x. GFS 4.x and OpenGFS use dmep.
>>>
>>I think you are misunderstanding me. There is a SCSI III
>>primitive in the drafts that permits multiple masters to
>>range lock disk ranges to a a particular host. By doing
>>this, it permits multiple writers, by guarantees that each
>>host will not overlap a write. It also causes a writeback
>>invalidation for other masters, in order to effect a distributed
>>cache coherency protocol, without additiona daemons or hardware.
>>
> I have a very different and practical reason for not wanting to
>see this used. And it has to do with the fact that it is a feature
>that isn't used by the volume portion of the market. As drives can
>be shipped to 99.999+% of the customers with this feature not working
>correctly and they will be happy. This means that the vendor has
>very little economic incentive to make this work correctly under all
>conditions. The cost of implementing one fix would eat up way more
>margin dollars than they would get out of the small numbers of drives
>sold in these situations.
>
>Which puts you in the position of:
>
>GFS User: "Vendor this feature doesn't work on your drives like
>it is documented.".
>Vendor: "Let us check it out .... It works under our tests."
>GFS User: "But it doesn't work for me."
>Vendor: "Well we checked it out again and they way you are using
> it causes the problem."
>GFS User: "Fix it."
>Vendor: "No, but we will allow you to return the drives for a refund."
>
>
> And of course by using a SCSI features then you can only use
>SCSI.
>
Interesting argument, however, if range locking were to become a
differentiating factor because of some requirement of clustering
storage, SCSI manufacturers would, eventually, follow the spec. There
may be easier ways to solve this problem, though, then to persuade the
SCSI vendors in to implementing the proper spec.
<CUT>
--------------020906060400000905040004
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<html>
<head>
</head>
<body>
<br>
<br>
Timothy D. Witham wrote:<br>
<blockquote type="cite" cite="mid:1000741723.15009.78.camel@wookie-laptop.pdx.osdl.net">
<pre wrap="">On Mon, 2001-09-17 at 02:51, Terry Lambert wrote:<br></pre>
<blockquote type="cite">
<pre wrap="">Christoph Hellwig wrote:<br></pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">This disagrees with a discussion I had off list, as to the use<br>and availableility of DLOCK, and the firmness of the SCSI III<br>standard. The GFS people are using Matt Jacob's fiberchannel<br>driver, and a network based distributed lock manager.<br></pre>
</blockquote>
<pre wrap="">DLOCK was GFS 3.x. GFS 4.x and OpenGFS use dmep.<br></pre>
</blockquote>
<pre wrap="">I think you are misunderstanding me. There is a SCSI III<br>primitive in the drafts that permits multiple masters to<br>range lock disk ranges to a a particular host. By doing<br>this, it permits multiple writers, by guarantees that each<br>host will not overlap a write. It also causes a writeback<br>invalidation for other masters, in order to effect a distributed<br>cache coherency protocol, without additiona daemons or hardware.<br><br></pre>
</blockquote>
<pre wrap=""><!----> I have a very different and practical reason for not wanting to<br>see this used. And it has to do with the fact that it is a feature<br>that isn't used by the volume portion of the market. As drives can<br>be shipped to 99.999+% of the customers with this feature not working<br>correctly and they will be happy. This means that the vendor has<br>very little economic incentive to make this work correctly under all<br>conditions. The cost of implementing one fix would eat up way more<br>margin dollars than they would get out of the small numbers of drives<br>sold in these situations. <br><br>Which puts you in the position of:<br><br>GFS User: "Vendor this feature doesn't work on your drives like <br>it is documented.".<br>Vendor: "Let us check it out .... It works under our tests."<br>GFS User: "But it doesn't work for me."<br>Vendor: "Well we checked it out again and they way you are using<br> it causes the problem."<br>GFS User: "Fix it.
"<br>Vendor: "No, but we will allow you to return the drives for a refund."<br><br><br> And of course by using a SCSI features then you can only use<br>SCSI. <br></pre>
</blockquote>
Interesting argument, however, if range locking were to become a differentiating
factor because of some requirement of clustering storage, SCSI manufacturers
would, eventually, follow the spec. There may be easier ways to solve this
problem, though, then to persuade the SCSI vendors in to implementing the
proper spec.<br>
<br>
<CUT><br>
<br>
</body>
</html>
--------------020906060400000905040004--
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3BA62588.20005>