Comment 43 for bug 548513

For the record, this was just discussed in #u-release:

pitti cjwatson: it looks like you just remove the -B option, while Jeroen's change disables hdparm altogether (hdparm-functions has other bits); but I believe -B is the only thing we actually ship by default
cjwatson that was my assessment from reading the code
cjwatson double-checking wouldn't hurt
pitti cjwatson: it seems to be that the bug doesn't happen on that particular operation, but on the initial IDENTIFY DEVICE
pitti (incidentally that's very similar to the recent udisks-probe-ata-smart bug)
pitti cjwatson: so from what I can see, if an user would customize /etc/hdparm.conf to set other options than -B, they would again be done for firefire drives, too, and again break them?
pitti (conversely, with Jeroen's variant you couldn't ever run custom hdparm commands on any firewire drive)
cjwatson I think so
cjwatson though hdparm.conf can be disk-specific
pitti sounds like being between a rock and a hard place :(
pitti ah, it can?
pitti ok, then I prefer your fix indeed :)
pitti ah, right, these come in /dev/foo { } blocks
cjwatson such is my understanding
cjwatson a release note mightn't hurt

I don't think that one of the two approaches is "obviously" right, but I think Colin's approach is more flexible for actually being able to control some fw drives with hdparm (with customized configuration), and it will stop the corruption on a default installation.