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? > > However we could prevent autosuspend for devices drawing more than 100 > > mA of bus current. Even if it has an external power supply, such a > > device might not be safe to autosuspend without special measures like > > spinning down. And best of all, this wouldn't be a layering violation. > > I am fine with that. Okay, that's easy to add. > > > 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. > > 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. > > Objection 3: This would prevent us from autosuspending flash drives, > > which could really benefit. > > Why? Sorry, I misunderstood the proposal. Ignore this objection. > > > 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. > > 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? Alan Stern -- 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
