On Thu, May 12, 2011 at 17:43, James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > It depends what the drive is caching and what's removable. If it's some > type of hybrid, and the cache isn't mapped to the media for instance. Except that the SCSI spec says the cache affected by SYNCHRONIZE CACHE is related to the medium. > The point really is that if the cache is in the housing, setting it to > write through when it's not is not a correct reflection of reality. Since this pretty clearly violates the intent of the spec, I have to ask whether you are aware of any such device. I've never seen one. Also, the only actual behavioral difference between my proposed patch and your proposed one is to print out a message; you still weren't calling sd_sync_cache() if the medium was not present. I'm not beholden to a specific patch—but printing out an extra message, which seems to imply that something is wrong, is decidely uncool in the original case I referenced (my Android phone, after “Turn on USB storage” and then “/usr/bin/eject”), where nothing is wrong other than the driver trying to SYNCHRONIZE CACHE to a medium that it already knows is not present. > or actually, just checking the value when it looks at the return code. That was what I did first, but then I realized two things: 1) The pre-use (before clicking “Turn on USB storage”) state has WCE==0 because the mode page code hasn't been called at that point. There is no good reason the pre-use and post-eject behavior should be different, given that the device itself is in *exactly* the same state at these points. 2) I definitely do not want a spurious message that could be interpreted as an error, since this is perfectly normal and acceptable use. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
