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? > 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. > > 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. > 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. > Objection 3: This would prevent us from autosuspending flash drives, > which could really benefit. Why? > > 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? > 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. 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
