Henrique de Moraes Holschuh wrote: > On Mon, 14 Sep 2009, Tejun Heo wrote: >> Oooh, another possibility is the above continuous IDENTIFY tries. >> Doing things like that generally isn't a good idea because vendors >> don't expect IDENTIFY to be mixed regularly with normal IOs and > > IMHO that means the kernel should be special-casing such commands, then (i.e > quiesce drive, do command, quiesce driver, start IO again), probably > rate-limiting it for good effect. > > This is the kind of stuff that userspace should NOT have to worry about > (because it will get it wrong and cause data corruption eventually). If this indeed is the case (As Mark pointed out, there hasn't been any precedence involving IDENTIFY but it's also the first time I see IDENTIFY timeouts which are issued from userland), this is the kind that userspace shouldn't do to begin with. There was another similar problem. Some acpi package in ubuntu issues APM adjustment commands whenever power related stuff changes. The firmware on the drive which shipped on Samsung NC10 for some reason locks up after being hit with enough of those commands. It's just not safe to assume these kind of stuff would reliably work. If you're ready to do some research and experiments, it's fine. If you're doing OEM customization with specific hardware and QA, sure, why not (this is basically what windows OEMs do too). But, doing things which aren't _usually_ used that way repeatedly _by default_ is asking for trouble. There's a reason why these operations are root only. :-) Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
