On Fri, May 23, 2008 at 01:16:39AM +0530, Syed Mohammed, Khasim wrote: > > The obscene amount of noise here seems to be caused by ext2 being > > extremely persistent. This is generally a good thing for your data > > though. :) > > > > What is missing is a decent way for a block device to tell the upper > > layers that is gone with no hope of ever coming back. Right now we just > > tell it that there was a write error, which just makes the upper layers > > retry and retry. > > > In this scenario, do you think it would be right to kill the ongoing > copy from application space, say for example an UI is running for MMC > copy and when the card is removed the app gets notified may be through > hotplug event or signaling and then app just kills the process that is > issuing this copy request. This will prevent long running errors. Just > a thought, If you pick out the errors from 'cp', you'll see that the system is telling 'cp' that it's getting IO errors. Nevertheless, 'cp' carries on trying to copy each file (and rightfully so.) However, there is another issue here - if you're going to be ejecting a medium containing an ext2fs filesystem at some random point, you absolutely must run e2fsck before remounting it - the filesystem _will_ be in an inconsistent state at the point you eject the card. Moreover, I wouldn't be surprised if you keep doing this with a card, that the card's firmware will eventually get confused and die. Basically, what I'm trying to say is that ejecting any medium randomly from the system is _always_ going to result in problems of some nature. Some of which you can reduce the impact from, others are fairly terminal. The only safe solution is the unmount, wait for data to be written, and then eject the card. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
