Am Mittwoch, 21. Oktober 2009 04:38:11 schrieb Alan Stern: > You mean, allow START-STOP and SYNCHRONIZE CACHE to pass through > without aborting the autosuspend? What if the SCSI suspend routine > wants to send something else? > > For that matter, what if the SCSI drivers fail to accept I/O requests > while they think their device is suspended? I just don't think your > idea can be made to work well. Yes, that is a serious problem. OK, forget that idea. 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. 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. 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. 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
