Date: Fri, 03 Oct 2003 16:35:57 +0000 From: Jens Rehsack <rehsack@liwing.de> To: Don Lewis <truckman@FreeBSD.org> Cc: freebsd-current@FreeBSD.org Subject: Re: Improvements to fsck performance in -current ...? Message-ID: <3F7DA56D.8070002@liwing.de> In-Reply-To: <200310022051.h92Kp6N1039873@gw.catspoiler.org> References: <200310022051.h92Kp6N1039873@gw.catspoiler.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Don Lewis wrote:
> On 2 Oct, Terry Lambert wrote:
[...]
>>Actually, write caching is not so much the problem, as the disk
>>reporting that the write has completed before the contents of
>>the transaction saved in the write cache have actually been
>>committed to stable storage.
>>
>>Unfortunately, IDE disks do not permit disconnected writes, due
>>to a bug in the original IDE implementation, which has been
>>carried forward for [insert no good reason here].
>>
>>Therefore IDE disks almost universally lie to the driver any
>>time write caching is enabled on an IDE drive.
>>
>>In most cases, if you use SCSI, the problem will go away.
>
>
> Nope, they "lie" as well unless you turn of the WCE bit. Fortunately
> with tagged command queuing there is very little performance penalty for
> doing this in most cases. The main exception to this is when you run
> newfs which talks to the raw partition and only has one command
> outstanding at a time.
>
> Back in the days when our SCSI implementation would spam the console
> whenever it reduced the number of tagged openings because the drive
> indicated that its queue was full, I'd see the number of tagged openings
> stay at 63 if write caching was disabled, but the number would drop
> significantly under load (50%?) if write caching was enabled. I always
> suspected that the drive's cache was full of data for write commands
> that it had indicated to the host as being complete even though the data
> hadn't been written to stable storage.
>
> Unfortunately SCSI drives all seem to ship with the WCE bit set,
> probably for "benchmarking" reasons, so I always have to remember to
> turn this bit off whenever I install a new drive.
A message from this morning ('file system (UFS2) consistancy
after -current crash?') to this list describes exactly the
situation on my fileserver a few month ago, except my machine
runs with FreeBSD 4-STABLE and has an ICP-Vortex 6528RD controller.
I think, disk's or controllers (short hardware) write cache
is a problem. Maybe it shouldn't be in theory, but it is in
real world :-)
Best regards,
Jens
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3F7DA56D.8070002>