>>>>> "Tejun" == Tejun Heo <tj@xxxxxxxxxx> writes: Tejun> The problem with that approach is that it's very likely that we Tejun> won't be able to take advantage of that feature ever. Well, maybe. Ubuntu just turned on discard by default (for better and worse). Took a while to get here with unqueued trim but it doesn't look like they've had too much fallout. The problem with queued trim is that we're in the bootstrap phase, vendors generally don't have anything to test it with. The ones I talk to claim that it's not really working in Windows yet. So we're the only ones that actually support it. Tejun> That said, I wouldn't have any problem with applying blacklist Tejun> liberally for devices which show any sign of issues. If there Tejun> isn't no definite confirmation from the vendor regarding what the Tejun> issue was and which firmware fixes it, I think blacklisting the Tejun> whole family of devices isn't a bad idea. Yeah. The fun thing in this case is that Micron specifically issued this firmware release to fix queued trim. And they did test with our code. As did I. And yet something broke for users. Tejun> So, let's keep blacklisting liberally for now. OK. And how do you feel about making a disable/unqueued/queued sysfs knob? I'd really like to make it easy for the drive vendors to test. And if we liberally blacklist their firmware releases then we have significantly raised the barrier for their testing. Because all of a sudden they need to start mucking with kernel builds instead of booting the latest $DISTRO Live CD. -- Martin K. Petersen Oracle Linux Engineering -- 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
