View Single Post
Old 12 March 2017, 01:42   #12
Daedalus
Registered User

Daedalus's Avatar
 
Join Date: Jun 2009
Location: Dublin, then Glasgow
Posts: 4,352
Quote:
Originally Posted by Pat the Cat View Post
So the MaxTransfer value (the setting, not the rate as I had already posted) can indeed mangle large files like ROM dumps, and if the OP sets a lower value of Max Transfer on the drive (as I have suggested) and recopies the files to the drive, that might resolve the issue.
The driver mangles the file, the MaxTransfer setting prevents the driver from reaching a state where the mangling can happen. The rate has nothing to do with it. While your suggestion of lowering the value was sound, your explanations for that suggestion were totally wrong.

Quote:
If it was purely a software issue, you would think it would have been sorted after 25 years, and if you think it's just a software issue, feel free to rewrite scsi.device to fix it.
No need on both counts when there's a perfectly good, easy to implement and very well documented work-around (specifying a suitable MaxTransfer value). And there are already a number of replacement drivers and patches that people have already written that solve the issue, and most likely did a better job than I would too. No sense reinventing the wheel...

Quote:
Originally Posted by Toni Wilen View Post
Driver does split it correctly but it also does something unnecessarily complex and instead of just simply calculate start block of next transfer using driver's own internal state variables, it reads last access position from drive's registers and adds 1.

This method was valid in ATA-1, since ATA-2+ it is only valid if last read or write failed -> next transfer (and all following if it is really long transfer) starts from same LBA/CHS position as first transfer..
Indeed.
Daedalus is offline  
 
Page generated in 0.04329 seconds with 11 queries