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. > > 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_? No, specifically and at that time surprisingly, sd. sd_ioctl() is the problem. sg has nice semantics with open/close With sg you get a pm reference when you open and drop it when you close. sd is the problem. > > 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. sg, st and osst are plain correctness issues. You mustn't autosuspend while they have a reference. That's important but simple and easy. > For example, what happens if you suspend a SCSI CD drive while it is > playing an audio disc? That one special case we can deal with with hooks in the ioctl path. > 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? > 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. 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
