Re: write barrier patches for 2.4.21

[Chris Mason <mason@suse.com>]

On Thu, 2003-08-28 at 21:18, Mike Fedyk wrote:
>  
> > i'm not sure what you mean. chris is just saying tcq makes performance w/o
> > write cache better. i WOULD like to see wb's used w/ scsi. it would be nice
> > to be able to safely enable write cache on my drives.
> 
> I'm just trying to clairify that it looks like TCQ shows exactly what it
> happening in the drive's cache, and that's why with tcq the wb's aren't
> explicitly needed.
> 
> With ide without tcq and with write caching, it accepts the write request
> and says it's complete when it's actually still in the disks cache, not on
> the platters yet.
> 
> Contrast that to TCQ (IDE or SCSI), where the write request is sent to the
> drive, and once it hits the platter, the tcq command completes and notifies
> the host OS (Linux in this case) that it's done.  And SCSI with no TCQ is
> like IDE with no write cache.
> 
> Do I have that right?

Pretty much.  If your tag depth is set right, you get the benefits of
writeback caching without the risk.  But your workload has to be right.

Picture one process doing synchronous io writes.  He's only going to
generate one tag and then wait on it.  With writeback cache, the drive
will return immediately, but with just tcq you'll still have to wait.

For the one writer workload with the barrier patches, the writeback
cache disk will be just as slow as the tcq disk.  This is usually what
you want, since if you're taking the time to do synchronous IO it's
because you want to know the data is really on disk (or on battery
backed cache somewhere).

-chris