Alan Stern wrote: > On Mon, 9 Apr 2012, Norman Diamond wrote: [Alan Stern:] >>> You're not thinking about it the right way. If the quirk handling were any less agressive, it would fail to work entirely on some devices (those that crash when trying to access a nonexistent block). >> >> I see your point, regarding devices which differ from mine, and which possibly differ from the other user in 2004 since we don't really know the reason for his crash (he might have had a bad block at or near the end of his drive). >> >>> Such devices would not usable at all. >> >> We are already in that situation because of the decrement. > > No. That statement is simply wrong. Such devices are quite usable. As you saw yesterday, Linux truncated my existing NTFS partition, which had been created properly by Linux with a different USB-to-IDE bridge. Such devices are not fully usable, and not quite usable when they were partitioned while connected through bridges that Linux was fully happy to use. >> If the drive was partitioned while the drive was internally installed on an ATA cable, then the decrement now interferes with the usability of the drive regardless of whether the USB bridge really does or doesn't have a bug. > > What are you talking about? If the bridge does have the capacity bug then the decrement allows the bridge to be used correctly. And when the bridge doesn't have the capacity bug, as mine doesn't, the present level of quirk handling truncates the partition, as it did yesterday and as I reported yesterday. >> Also, if the drive was partitioned when using a known non-buggy bridge, then the same situation happens when using a bridge whose status is ambiguous because the driver does a decrement. > > It is true that the current situation sometimes denies access to a block which might work perfectly well. Yes, and one paragraph earlier I described the same case where a drive had previously been connected directly to an ATA controller instead of a fully Linux-accepted USB bridge. A block which already has been in use now gets denied access. > But we don't have any better solutions. In some cases we do. > And don't forget, in any individual case it is always possible to disable the quirk by means of a module parameter. Yes, I remember you mentioned that a week or two ago, and I need to look at the modconf files. But I have to be capable of doing something reasonable with other bridges too, and the kinds of actions that are reasonable in my situation are different from yours. I cannot deny access to the last block. In my situation it is better to let a buggy bridge hang, so that the user knows they need to change bridges. >>> Besides, suppose this quirk entry were removed. What would happen with the other bridges with the same ID numbers that do not decrement the block count properly? Linux would try to access the nonexistent last block, and the access would fail. Perhaps no unplug and replug would be needed, but any data destined for that block would be lost. >> >> The present situation loses reads and writes of the last block when the last block DOES exist. > > No, it doesn't; it prevents those reads and writes from being attempted in the first place. Correction: yes it does, exactly because it prevents those reads and writes from being attempted in the first place. As I described yesterday, I used a different bridge (one that Linux fully accepts) and created an NTFS partition ending in the actual last sector of the drive. Then when using my Prolific bridge, Linux prevented reads and writes of the last block from being attempted in the first place. The present situation loses reads and writes of the last block when the last block DOES exist and contains NTFS metadata. > You probably don't care about this distinction, however. I do understand the distinction between losing reads and writes because of one reason and losing reads and writes because of a different reason. But in my situation I cannot lose reads and writes that users expect to take place, and I cannot give the excuse that they were lost because of one reason instead of a different reason. > If you're trying to make a point in this discussion, I can't tell what it is. I already know that decrementing the capacity is not always the right thing to do. But I don't know of any better alternative. I do think that we can try to read the single last block that the bridge asserts to exist, except in cases where a bridge has been observed to hang when when trying to read the single last asserted block (not multiples) where the bridge lied about the existence. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
