scsi write barriers (ordered tags)?

scsi write barriers (ordered tags)?

[Jordan Breeding]

[-- Attachment #1: Type: text/plain, Size: 1777 bytes --]

Today regarding his message about ide write barriers I got the following 
message:

Jens Axboe wrote:
> On Wed, Feb 05 2003, Jordan Breeding wrote:
> 
>>Jens Axboe wrote:
>>
>>>Hi,
>>>
>>>The attached patch implements write barrier operations in the block
>>>layer and for IDE, specifically. The goal is to make the use of write
>>>back cache enabled ide drives safe with journalled file systems.
>>>
>>>Patch is against 2.4.21-pre4-bk as of today, and includes a small patch
>>>to enable it on ext3. Chris has a patch for reiserfs as well.
>>>
>>
>>Does the above mean that the patch only works for IDE and not for SCSI? 
> 
> 
> The above is just for IDE.
> 
> 
>> If so when will SCSI be able to use write back cache safely?  Also, 
> 
> 
> Hmmm well, it's simple enough to make the low level driver generate an
> ordered tag when appropriate, but it's very tricky to make sure that no
> re-ordering takes place in case of errors, timeouts, etc.
> 
> 
>>will this patch be ported to 2.5.x or is it already present there?  Thanks.
> 
> 
> Block layer infrastructure is there, has been since bio was merged in
> 2.5.1-pre. The ide bits will be send for inclusion shortly.
> 

The part I am concerned with is his statement about SCSI being harder to 
implement this on.  I guess this doesn't matter as much since my SCSI 
drive with write back cache off is faster than any IDE drive I have used 
with it on, but still it would be nice to be able to run both type of 
drives with the write back cache on.  So my question is, are the things 
Jens stated above about SCSI enough to keep this feature completely out 
of 2.5.x even once IDE has the code merged, or will SCSI be able to have 
this feature as well by 2.6?  Thanks for any info and/or speculation 
about this.

Jordan

[-- Attachment #2: Type: application/pgp-signature, Size: 250 bytes --]

Re: scsi write barriers (ordered tags)?

[James Bottomley]

On Wed, 2003-02-05 at 10:00, Jordan Breeding wrote:
> The part I am concerned with is his statement about SCSI being harder to 
> implement this on.  I guess this doesn't matter as much since my SCSI 
> drive with write back cache off is faster than any IDE drive I have used 
> with it on, but still it would be nice to be able to run both type of 
> drives with the write back cache on.  So my question is, are the things 
> Jens stated above about SCSI enough to keep this feature completely out 
> of 2.5.x even once IDE has the code merged, or will SCSI be able to have 
> this feature as well by 2.6?  Thanks for any info and/or speculation 
> about this.

There are two really significant differences between SCSI and IDE with
regard to barrier implementation (the basic one is that SCSI has a more
complex queueing model).

1) SCSI devices can have multiple simultaneously outstanding commands

2) Some SCSI devices (like high end arrays) have huge caches, so you
can't implement a barrier simply by flushing the cache, like IDE does,
because that might cause significant slow downs.

As Jens says, there are ways to do this, and we do have most of the
infrastructure in place.  However, we'd need different error recovery
behaviour for a complete solution, and no-one's done that work yet.

Finally, even if the error recovery work is done, drivers which use
internal issue queues would probably need modifying to do the right
thing on ordered tag error return (and that's quite a huge effort).

James

Re: scsi write barriers (ordered tags)?

[James Bottomley]

On Wed, 2003-02-05 at 11:58, jordan.breeding@attbi.com wrote:

> I understand that SCSI drives and controllers are much more
 complicated than their IDE counterparts and that to implement ordered
 tags in SCSI is more complicated.  However, doesn't FreeBSD's CAM
 layer have some kind of implementation of this which makes it safe to
 use soft-updates and write back cache together?

Actually, no.  The problem that caches cause is that they cache data,
not transactions.  You can force the caches to respect transaction order
by flushing them, but that gets expensive.

 I thought that I read  that sometime ago but I have been trying to
 find references to it on  google this morning and couldn't find any. 
 I guess what I am really  after is to fold:  1) Will Linux's SCSI
 layer get modified at _any_  point to support something like this to
 benefit  ext3/reiserfs/xfs/jfs?  2)  If this will be attempted at some
 point  will it be later in 2.5/2.6 or will this definitely be 2.7/2.8
 material?  Thanks for the info and the response.

Like I said, the infrastructure exists.  There's no compelling reason
to enable it (mainly because most of the benchmarks say it causes a
slowdown).

James

RE: scsi write barriers (ordered tags)?

[Cress, Andrew R]

Jordan,

Also, note that most of the benchmarks that show an improvement with disk
write cache enabled are using large sequential writes, whereas most
real-life storage I/O will use small random writes, which, as James said,
usually ends up slower with write-cache enabled.  

Andy

-----Original Message-----
From: James Bottomley [mailto:James.Bottomley@steeleye.com] 
Sent: Wednesday, February 05, 2003 3:25 PM
To: jordan.breeding@attbi.com
Cc: SCSI Mailing List
Subject: Re: scsi write barriers (ordered tags)?


On Wed, 2003-02-05 at 11:58, jordan.breeding@attbi.com wrote:
> I understand that SCSI drives and controllers are much more
 complicated than their IDE counterparts and that to implement ordered
 tags in SCSI is more complicated.  However, doesn't FreeBSD's CAM
 layer have some kind of implementation of this which makes it safe to
 use soft-updates and write back cache together?

Actually, no. [...]

Like I said, the infrastructure exists.  There's no compelling reason
to enable it (mainly because most of the benchmarks say it causes a
slowdown).

James

RE: scsi write barriers (ordered tags)?

[berthiaume_wayne]

	Andrew, I'd have to dispute your reported finding. I have been
testing lk 2.4.19, reiserfs, with IDE drives both with write cache enabled
and disabled, and  with and without write barrier patch on file sizes from
4kB to 100MB. All files are fsync()'d to the drives, and with write cache
enabled provided vast improvements in system performance. Further, by using
the write barrier patch, when compared with write cache enabled and no write
barrier patch, only a slight degradation in system performance was
encountered. 
	Now I can't speak for SCSI and how effective it would be, but there
is a definite improvement in the IDE world.
Regards,
Wayne

email:       Berthiaume_Wayne@emc.com

"One man can make a difference, and every man should try."  - JFK


-----Original Message-----
From: Cress, Andrew R [mailto:andrew.r.cress@intel.com]
Sent: Wednesday, February 05, 2003 4:31 PM
To: 'James Bottomley'; jordan.breeding@attbi.com
Cc: SCSI Mailing List
Subject: RE: scsi write barriers (ordered tags)?


Jordan,

Also, note that most of the benchmarks that show an improvement with disk
write cache enabled are using large sequential writes, whereas most
real-life storage I/O will use small random writes, which, as James said,
usually ends up slower with write-cache enabled.  

Andy

-----Original Message-----
From: James Bottomley [mailto:James.Bottomley@steeleye.com] 
Sent: Wednesday, February 05, 2003 3:25 PM
To: jordan.breeding@attbi.com
Cc: SCSI Mailing List
Subject: Re: scsi write barriers (ordered tags)?


On Wed, 2003-02-05 at 11:58, jordan.breeding@attbi.com wrote:
> I understand that SCSI drives and controllers are much more
 complicated than their IDE counterparts and that to implement ordered
 tags in SCSI is more complicated.  However, doesn't FreeBSD's CAM
 layer have some kind of implementation of this which makes it safe to
 use soft-updates and write back cache together?

Actually, no. [...]

Like I said, the infrastructure exists.  There's no compelling reason
to enable it (mainly because most of the benchmarks say it causes a
slowdown).

James

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html