Am Mittwoch, 21. Oktober 2009 17:44:25 schrieb Alan Stern: > On Wed, 21 Oct 2009, Oliver Neukum wrote: > > Am Mittwoch, 21. Oktober 2009 16:10:57 schrieb Alan Stern: > > > On Wed, 21 Oct 2009, Oliver Neukum wrote: > > > > Very well, here are just a few ideas unfortunately involving layering > > > > violations. Something about storage makes me want to violate > > > > layering. > > > > > > > > 1. Introduce a heuristics to detect endangered devices > > > > > > > > I think we can be pretty sure that all devices that drop their caches > > > > have the following features: > > > > - bus powered > > > > - draw >100 mA > > > > > > > > So I propose that we don't autosuspend them during normal operations > > > > and, later on, tell the SCSI layer that these devices need a cache > > > > flush during a normal suspension. > > > > > > As far as I know, there is no way to tell the SCSI layer. (Besides, it > > > should already know which devices need cache flushes.) > > > > OK, so why don't we take the hint from the SCSI layer? > > Layering makes it very awkward. Have you looked at sd_suspend() in > drivers/scsi/sd.c? We need to get at scsi_disk and it is the gold standard. > > > > 2. Filter errors and watch for "medium not present" indications > > > > > > > > We look at errors anyway, so I think we can do something with this > > > > We can > > > > a) suspend devices we wouldn't suspend normally if all their LUNs and > > > > SCSI devices have no medium present, as we can loose no data > > > > b) suspend immediately under this condition. We can be pretty sure > > > > no further commands will come for a device without medium. This way > > > > we can cooperate with haldemon. > > > > > > Objection 1: Ugh! > > > > Maybe I should clarify. I don't propose that the kernel probe for > > media detection. Just that it interpret error returns that come anyway. > > Yes, but it's still ugly. usb-storage would have to maintain its own > array of state information for all the LUNs present. struct scsi_device has a hook for the low level driver. > > > Objection 2: Probing for medium insertion would defeat the autosuspend. > > > Or else the autosuspend would defeat probing for medium insertion, > > > depending on how it was implemented. > > > > Unfortunately haldemon needs to do it if it wants to catch media > > insertion, doesn't it? If so we can only mitigate the effect of polling > > by suspending as soon as possible. > > Yes, all right. To tell the truth, I would prefer to avoid all these > difficulties and not worry about autosuspending card readers and such. > (Unless the user disables hal's probing.) We can emphasize that this > is only a partial, potentially unsafe, autosuspend implementation. This would have the perverted effect of working autosuspend for a mounted device and no autosuspend for an empty device. > > > > 3. Filter commands and watch for writes > > > > > > > > This is really dirty, but we can use it to increase safety. We can be > > > > pretty sure devices eventually flush their caches on their own. But > > > > they may need more time than we give. So we could enforce a minimum > > > > timeout, say 10 seconds, from within the kernel after the last write > > > > before we autosuspend. > > > > > > I suppose that's possible. There's a whole bunch of different sorts of > > > write commands. Would you restrict your attention to WRITE(6) and > > > WRITE(10)? Or maybe include WRITE(12) and WRITE(16)? What about > > > things like WRITE-VERIFY? > > > > Which commands does sd issue? > > It uses WRITE(6), WRITE(10), and WRITE(16). It also uses WRITE(32), > but the USB mass-storage protocol can't handle those commands. Easy to catch. > > > What about issues of spinning down? > > > > As far as I can tell a device that is spun down will complain, the scsi > > layer will spin it up explicitly and retry the command. > > That's a spinning-up issue. What I meant was, will there be a problem > if we cut bus power to a rotating platter without first spinning it > down? There'll be problems. And the remedy would be to get at struct scsi_device and look at manage_start_stop. Regards Oliver -- 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
