Comment 17 for bug 477106

Right, being so close to release we did not want to change defaults to something
different than in Karmic. Even as the behaviour is looking better with the cards
being declared non-removable.
The problem is that this is a choice between two evils: either you declare them
removable, so the card is basically forcefully ejected on suspend and
re-detected and mounted on resume. Although the system tries to ensure there is
no unwritten data, there might be holes/races between that and the eject. And in
fact we had such a problem at some point in Karmic were the card got overwritten
(total data loss) on resume by things that did not make it to it on suspend.
We had a patch back then but that did not get accepted by upstream and then
replaced by something else that looked like doing the same but there either is a
subtle difference or something else got into upstream that lets suspend hang.

The other evil is to say the card is not removable. Now the card is not ejected
on suspend but upstream people think that this opens up a chance to destroy data
by swapping out the card and replacing it with a different one while the system
is suspended. I am not really sure how big this danger is, as when I remember
that correctly there is some card ID checked before actually assuming the same
media is still present. But the question is how unique these card IDs are. I
guess there is the problem of being good but expensive and less good but cheap
vendors of SD cards around. And from what I have read the cheap ones are not
really putting much effort into having uids or serial numbers right. But still
that might be a lot of the second case around...

So I think it is probably a good plan to make it a more concious decision to
twiddle with that setting.