Re: autosuspend for storage (was:Re: USB conversion to the runtime PM framework)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.)

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.

> 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!

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.

Objection 3: This would prevent us from autosuspending flash drives,
which could really benefit.

> 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?

What about issues of spinning 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

[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux