On Sat, 1 Aug 2009, Oliver Neukum wrote: > Am Samstag, 1. August 2009 00:01:27 schrieb Sarah Sharp: > > Hi Oliver, > Hello, > > > I know you worked on several versions of a mass storage device > > autosuspend patch. > > Alan wrote them, Pavel and I tried to finish them. There were several different proposed kinds of autosuspend for USB mass storage. None of them proved to be sufficiently safe and acceptable to the community. > > ISTR that they got dropped because the USB core > > turned on autosuspend by default and some USB MSDs with spinning disks > > didn't park their heads when they were told to suspend. Were there > > any other problems with the patches? > > Yes, they basically come down to enclosures cutting power to the devices. > This means > - the cache in the drive is lost > - any setting local to the drive might be lost > > > I'm wondering if now that userspace has to enable autosuspend if we can > > get away with re-adding those patches. > > 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. > The data loss issue can be solved, but it can't be easily solved cleanly. > An implementation to do it the dirty way existed. Alan and I differed on > accepatibility. > But I never managed to find a solution to vendor specific commands over > sd. The possibility to run generic commands over sd is a nightmare from Don't you mean generic commands over _sg_? > a pm viewpoint. I was forced to disable autosuspend in literally more than > a dozen points and sometimes permanently. And it took heavy surgery > to the SCSI layer. It was hopeless. > > It seems to me that the design would need to be discussed and we need > to find a consensus on how far we are willing to let autosuspend degrade > functionality. It probably would be fairly safe for devices that don't have an open file reference through the sg interface. But there are still problems. For example, what happens if you suspend a SCSI CD drive while it is playing an audio disc? 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. We certainly would want to synchronize the cache before suspending, but would we want to spin the disk 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
