"D. Hugh Redelmeier" <hugh(a)mimosa.com> writes:
Could you dd an equivallent volume from /dev/zero to see if it also
causes a problem? That eliminates one more variable from the problem.
I'll try. I have only seen it happen with a dvd as source. Disk to
disk copies such as "cp -ax / /mnt/backup" didn't seem to cause
problems.
Why do you call it "streaming conditions"? Do you think
that the fact
that the DVD delivers bytes more slowly than the hard drive would accept
them is important?
I had assumed that the bug required a high sustained data rate that
would dump a large number of consecutive blocks into the disk's on-disk
cache, but was still slow enough to allow the on-disk cache to drain.
But then again, it was just a stab at explaining why it only seemed to
happen when reading from dvd.
Or is there some other aspect that you think is relevant?
Hard to say. I'd only really had 3 or 4 lockups and each time it was
the morning after I'd added a new video.
NCQ has been around long enough that I'd expect/hope that the
nits
have been picked. Of course I could be wrong.
Well, I've seen the bug described as a on-disk cache flushing bug and/or
NCQ bug.
In any case, Seagate support got me some SD3B firmware to load onto the
disk. Strangely my disk now identifies itself as ST31500341AS instead
of ST31500343AS (with a "1" instead of a "3"). That also explains why
I
couldn't find other folks with bug reports -- only a few drives went out
with the trailing "3" model number. Lets see how the drive holds up.
I'm beating on it right now.
-wolfgang
--
Wolfgang S. Rupprecht
http://www.full-steam.org/ (ipv6-only)
You may need to config 6to4 to see the above pages.