On Sat, 1 Aug 2009, Oliver Neukum wrote: > Am Samstag, 1. August 2009 03:54:04 schrieb Alan Stern: > > On Sat, 1 Aug 2009, Oliver Neukum wrote: > > > > This is basically a judgement call. How much damage is acceptable if > > > autosuspend is activated on a device that can't handle it? > > > We felt that filesystem corruption is beyond the pale in any case. > > > > Add to this the fact that the kernel can't tell whether a particular > > drive will lose its cached data when it is suspended. > > Exactly. The scsi layer leaves this to user space with sysfs attributes. > This however raises the point whether the storage driver need be more > saintly than scsi itself. Neither more nor less -- it's not our concern. The right approach is to have the storage driver not carry out its own suspend until the SCSI suspend routines have been called. That way we don't violate layering. And if anything goes wrong, we can blame the SCSI people. :-) > > The safest would be to restrict autosuspend to SCSI disks only, and > > only when they are not being accessed via sg, and only if we can get > > the sd driver to cooperate. > > What exactly does this mean? It means we have to figure out how to be sure that the SCSI suspend routines have been invoked. > > We certainly would want to synchronize the > > cache before suspending, but would we want to spin the disk down? > > We can do no less than sd would do if the system were suspended to > play it safe. Or to put it another way, we should do _exactly_ what sd would do -- by asking sd to do it! Or more properly, by getting the SCSI core to tell the appropriate drivers to do their own things. In any event, we will eventually want to tie this in with Rafael's new runtime PM infrastructure. If usb-storage and SCSI both use it then the integration should be fairly easy. 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
