voidcoder said:
Hi,
I'm currently working on a project with some specific storage which
internally does a lot of write buffering. The whole thing is working
perfect except of a single problem: when shutting
down/suspending/hibernating/
rebooting or whatever the power is cut too fast and the storage
(it is USB bus powered) is not able to complete the cached pending writes
thus we are loosing/corrupting data. Is there any way to delay the
power off. I mean, can I insert an artificial delay after the system
completed the disk I/O (i.e. closed files, flushed registry hives etc)
but before the power is turned off. It is a dirty solution, I know,
and therefore our Linux colleagues had no problem to workaround the
problem this way. Can we do the same on windows? The project is multi-
platform and we need to support at least XP, 2K3 and Vista.
Perhaps some customized shutdown script, a simple kernel mode driver
blocking power IOCTL, anything else. Any ideas are most welcome.
Thank you!
There are a couple ways you can address this.
1) Understand how it is supposed to work. For example, with a
USB protocol analyser, see what command Windows is sending
to the device, as part of flushing the device cache, before
shutdown. Then, study the command itself. Is the command synchronous
or asynchronous ? Does the command to flush, require an
acknowledgement that flushing is complete, or instead, is the
status from the device ignored, and assumed to be completed ?
You should understand the mechanics, before using a
sledgehammer to fix it.
2) Based on the results of your studies of (1), then
you can look for a workaround, of which there are a few.
Holding up Windows shutdown might work, if the interval is not
too long - there might be timers used in the shutdown sequence,
that will prevent your method from working if you are looking
for extremely long intervals. (Windows might assume the driver
has stopped responding, and kill it anyway.)
USB device ports have a couple options for internal computer
power. Either +5V or +5VSB can be used. +5VSB sticks around,
until you flip off the switch on the back of the computer.
Older motherboards sometimes had a header and a jumper plug,
to set the voltage source (provided for things like waking a
computer by pressing a key on a USB keyboard). Some recent
motherboards, have +5VSB as the only source. The only limitation
of the +5VSB thing, is if you have so many USB devices connected,
that the power supply doesn't have enough current for them all.
If the USB port was +5VSB powered, then you should have time
to finish flushing.
The next level of fix, would be an act of desperation. It is
possible, if your product provided a 20 pin to 20 pin power
cable extension, for your product to fool around with the
PS_ON# signal going to the power supply. You could artificially
keep the power supply running longer than normal, by altering
the protocol to the power supply. PS_ON# is open collector, and
by having a third party device ground PS_ON# for 30 seconds,
that would keep the power supply running for 30 seconds, giving
time for your device to complete its operation. But if anyone
sees such a solution used, naturally they would scoff at it
Another act of desperation, is a power storage device inside
the USB storage thing. There are things like "supercaps", which
can store charge for a number of seconds. These are not
rechargeable batteries, but are capacitors with fairly large
farad ratings. There are rules to their usage, and I'd have
to go back and look that stuff up - there are probably some
rules about rates of current flow and the like. By storing
enough power, for any possible flushing operation, then it
would not matter how curt the OS was.
If you think about it, it would make sense that the issue had
been considered, when the OS was designed. And that spec wise,
there is a mismatch of expectations. I understand, that one
workaround applied at one time, was for Microsoft to delay
shutdown for a couple seconds, to fix a problem like this.
Whether that is an admission that the problem is an OS one,
or was done to help some hardware implementations that are
less than perfect, is something you could research.
Paul
