My smartphone has wiped my microSD card again: Is it a conspiracy? Billy Idol has run off with Madonna. That's the third time this year and it's getting annoying. It's not just these two stars to have absconded: all of the music that was on the microSD card in Mme D's smartphone has vanished. Not just that cheesy 1980s playlist but all the modern stuff too – absolutely everything has been …
Quite. Now stuff it in your pocket, next to your crown jewels on a day when the ambient temperature is close to 40C. Now go out in the sun. How hot is it inside that thing?
I forget which Vietnam war film/book rather memorably described: "Hot crotch cooking".
Phones don't have fans inside them and the Li Ion battery is basically an explosion waiting to go off when a thermal runaway happens. Now stuff the thing into the glove compartment in your car and let the midday sun beat down on the car.
I find the engineering of mobile phones absolutely mind blowing. Thermal management alone is astonishingly clever. Let alone packing a camera with multiple lenses, a games machine with GPU, an array of sensors and Lord knows what else, oh and a phone into something about 8mm thick.
I don't think heat is the problem with my phone (Moto G10). It regularly stops recognising the two branded SD card bought from official distributors I've tried. It is very lightly used. 30-40 photo's a month and I almost never take videos. Glad to hear it is not just me.
My first Raspberry Pi (ordered the day they were released) is still working fine with the same SD card (which is even older). It has no difficulty with log files and swap on the card. I used to have problems with defective SD cards, but I became more careful about where I purchased pre-Pi and have not had an SD card fail in a Pi or elsewhere since.
To be fair, I do not require my Pi's to thrash the swap partition and I repartition leaving a healthy chunk unassigned. Flash is made by Samsung, Toshiba and Micron. Do not buy from anyone else. Buy from as close to the manufacturer as you can. Buy from a distributor that specialises in electronics, preferably one you find on the list of authorised distributors you can find on the manufacturer's web site. Amazon (spit) have a common binning policy: cards sold by Samsung on Amazon were (years ago and perhaps still are) mixed into a bin with cards with the Samsung logo from other sources.
My first pi had issues but the SD was as cheap as I could find. So as the saying goes I bought twice. C10 Kingston were fine with Pi 1 so I stuck with them in my brace of 3s and a load of zeros. Kingston C10s weren't a problem as such in my Pi 4s but I gradually realised performance was underwhelming. So I RTFM (shocking I know) and yeah, C10 is way under spec for a 4 confirmed by the now baked in SD tester in Pi OS. Changing to U1 and going 64 bit utterly transformed it - it flies!
I have a dozen or so first-gen Sony-built Pis at work, in constant (near 24/7) use playing videos since 2012. They were pretty awful at trashing cards in the early days, but the first batch of cards I bought (or rather, had bought for me) were what could be found at Tesco and Sainsbury's because of course putting the display together was a bit of a rush job.
It seemed mostly down to being powered-down mid-write, and often the cards could be recovered with fsck or whatever, and if not they could usually be reformatted even if that meant using the SD Card Association's official formatting tool. Powerdown during boot was almost guaranteed to trash the card and often in such circumstances the card was unrecoverable afterwards.
However, updates to the Pi's operating system have largely mitigated those problems, as has the use of genuine Sandisk, Samsung or Transcend cards, and I very rarely get a problem these days. I've subsequently bought quite a lot of Pi2, Pi3 and a couple of Pi4 and can honestly say that in the - let's call it nine years - since the first generation stopped mucking about I've had only two or three cards "just die" for no apparent reason.
As regards the problem in the smartphone, my suspicion would lie fair and square with Android I'm afraid. There is nothing intrinsic about a (good) SD card which makes it more fragile than any other removable storage medium as far as I can tell, I have SD cards in smartphones and non-smartphones, stills cameras, video recorders and mp3 players at home that have lasted years without issue.
M.
"As regards the problem in the smartphone, my suspicion would lie fair and square with Android I'm afraid. "
Agreed. As per both your and Dabbsie use cases, other than in phones, SD card either Just Work, or fail with r/w errors after lots of use. I don't think I've ever had one spontaneously re-format or refuse to work in it's "home" device only to work in something else or to be "fixed" by a re-format. There is the possibility that it's environmental in that it can get quite hot in a phone along with all the physical movement and jogging around it gets which would be the exception rather than the rule with most other devices, but it does seem more like and Android thing.
As title: I haven't had any SD card issues after I switched to Sandisk. I decided to use their SD cards because they are readily available at a decent price and have their own SD card foundry and so know what you're buying provided you buy from a reputable vendor. I use them in cameras, RPis and for gliding, where they are in two critical in-cockpit instruments:
- FLARM, an anti-collision device, where the SD card holds FLARM software, configuration and logs
- LK8000, a GPS-based moving map navigation system, where it stores the software, 3D maps, 3D airspace definitions and their categories, NOTAMS and, last but not least, the declared turnpoints for the task being flown.
There's also a Sandisk card in my GPS-based flight recorder, which is used used for competition and ladder flight scoring and for bragging rights, etc.
The actual Tegra processor had onboard flash, it wasn't on a card. They wrote a ton of crap to it and re-flashed it pretty often and they started to go bad en masse after the supplier stopped fabbing new parts.
There are a couple of hacks to get the car OS back running using an SD card to offload the W/R traffic, but they only work if the original Tegra has some life left in it, not ones who's flash is bricked. I think Tesla can fix this now, but I don't know how much it costs(replacement tegra was $$$$ to $$$$$ IIRC).
Can we all just load the car stuff on a NvME drive? They are cheap, everywhere, and they don't suck.
I'm waiting for a manufacturer to produce an EV which has a key, a couple of pedals, a "fuel" gauge and a speedometer and nothing else. Maybe a simple radio to entertain my commute. Save a couple of thousand on dubiously-useful "car operating systems", outright dangerous controls-on-touchscreens and certainly ditch the need to pair it up with a smartphone.
A friend pointed me in the direction of companies such as Electric Classic Cars and Falcon Electric (plenty more similar companies exist) which might be an option I suppose, but I'm not sure how sensible it would be to ask them to convert my Dacia Sandero :-)
M.
Someone did make the car you want- Norwegian manufacturer Th!nk, former pivco. I've had two of those, and apart from wear parts and finally rust induced death, they never failed during 350k km's of my driving. Basic, with diesel webasto heater and a radio. Plus, believe it or not, you can fit a standard 60x60cm appliance (washing machine etc) in the "boot". Sadly not made anymore.
As I recall, it was an eMMC, so it didn't even have the advantage of being removable. At least if it was an SD card, a repair wouldn't require ripping out the single point of failure, sorry I meant car systems console. Still, they could have put two flash chips in there: one to store the system files that only gets rewritten with an update, and one for writing lots of stuff to. That way, if the one they're repeatedly writing fails, which is basically guaranteed), at least the system will still work for the safety equipment they chose to run through it.
IIRC, France taxes storage devices to punish people who create their own content and to double charge those who purchase legitimate copies of copyright works. In theory the taxes are distributed among content creators so (in rainbow unicorn) France obtaining music from pirates does not harm the creators (who may well have harsh words for this theory). This type of copyright protection should be unnecessary in France.
Were these tracks bought via some route that involved payment to Google? No?
Maybe it's related to this: if my phone is switched off or, as is more likely, the battery has run down because I haven't used it for several days, all the apps downloaded from F-Droid disappear from the main UI pages. They can be copied - or is it linked? - back from the alphabetical list of available apps but not immediately as they're also hidden from that for several minutes. It may be a bug, it may be a gentle hint from Google that they don't like it when I fail opt not to to give them some money. Cock-up or conspiracy, take your choice, the result's the same.
I also use F-Droid for all my apps, and I don't have any such problem. One contact manager won't seem to stick to the home screen where a previous one did, and that's the limit of it. (I switch off every night too.)
The logic has a bit of truthiness to it though. If many phone brands and many card manufacturers are affected then it must be Android itself that is shit.
I guess no "sideloaded" (ugh) apk on the SD card is readable until Android finds it or Play Protect gets round to okaying it, and a side effect it's removed from the menu because it's not readable.
By the way, Symbian could do this properly about two decades ago (Nokia 6600), but that's progress for you.
My daughters Huawei tablet used to eat MicroSD cards regularly. The card would be marked as defective somehow. There's a kill bit that makes the MicroSD card read-only so you can retrieve the existing files, but nothing I found can change it back to read-write.
I put this down to the fact that I had the tablet set to shutdown each night and restart in the morning to save battery. I thought that perhaps the card was not being unmounted before the OS shutdown. Unlikely I know, I turned off the scheduled task, same behavior. Cards lasted a week or a month, it was totally random.
BTW I discovered that SanDisks "lifetime" warranty involved submitted serial numbers etc. to an open ticket, before they ask you to ship the card back to the US!
I'm assuming they know no one will go through that faff. By the time I was asked to return the card, it had got lost somewhere in the house.
"There's a kill bit that makes the MicroSD card read-only so you can retrieve the existing files, but nothing I found can change it back to read-write."
That seems to be a "feature" on SSDs too. It seems to be a failure mode where some (or too much) of the device has errors, possibly from too many write cycles, so the whole drive goes read-only to limit any further damage or data loss. It's a relatively common cause of boot time BSODs on Windows laptops because Windows, like any OS, needs to write stuff during the boot process. SSDs/Sata/m-sata.nvme.whatever terminology, seem to be improving though. I'm not seeing so many failed SSDs this last year or two. Maybe the silicon is better now. Or maybe the TRIM/wear-levelling has improved, or Windows is no longer forcing certain writes to the same places for "special" files. Who knows? Who cares? Whatever the cause, they seem more reliable and longer lasting.
My daughters Huawei tablet used to eat MicroSD cards regularly. The card would be marked as defective somehow. There's a kill bit that makes the MicroSD card read-only so you can retrieve the existing files, but nothing I found can change it back to read-write.
I put this down to the fact that I had the tablet set to shutdown each night and restart in the morning to save battery. I thought that perhaps the card was not being unmounted before the OS shutdown. Unlikely I know, I turned off the scheduled task, same behavior. Cards lasted a week or a month, it was totally random.
BTW I discovered that SanDisks "lifetime" warranty involved submitted serial numbers etc. to an open ticket, before they ask you to ship the card back to the US!
I'm assuming they know no one will go through that faff. By the time I was asked to return the card, it had got lost somewhere in the house.
I also discovered that Huawei tablets, like most other android slabs rarely get software updates to fix this stuff.
Obviously, the bits are being stolen by foreigners to supply their countries with enough bits. When bits are stolen they automatically return to zero on the SD card. It is just like NFTs; only one can own the bits, all other owners' are stripped.
The usual suspects were already mentioned in the article. They also engage in bits replacements and want more of your bits before they return your original bits. However, it has become easier just to steal the bits completely to supply their own demand.
This post has been deleted by its author
No. Stop these conspiracy theories.
The problem is with the phones without accelerometer. If you tilt your phone, the heavy 1 are going all around the place in the SD card and 0 sometimes get damaged and split to form 11 which destroys encryption.
If you have an accelerometer, the phone can generate a magnetic field to create a cushion and counter the forces caused by tilting, so the 1 and 0 bump each other more gently.
You may also have bit sex when a collision occurs between a 1 and a 0. Only when the angles are just right and have a gently cushioned collision you will get a penetration of the 1 through the 0.
The outcome will be added bits in any of the combinations 0 0, 0 1, 1 1 or 1 0. Procreation of storage bits with random organisation is the real encryption destroyer.
They really haven't - they've been created by bots inserting specific model names into generic pages of "turn it off and then on again" pseudo-advice with lots of space for adverts and dubious downloads. I've come to the conclusion there is absolutely no help available for mobile phone problems - especially from the manufacturers.
I've found that all SD cards in phones become corrupt over time and it seems to be a combination of the technology itself compounded by the use of FAT/exFAT. Now that most devices have moved over to MTP for USB access, there's really no reason any more why a more forgiving fie system couldn't be used. Android periodically does an fstrim for SD cards and unfortunately any duff report from the FAT and you could irretrievably discard most of your data.
So the tl;dr; here is that Android itself is shit, and habitually murders SD cards through bad software design that doesn't take into account the fact that the hardware may occasionally not report its status accurately? I wouldn't be surprised if there isn't also an element of the fact that the contacts on SD cards are small and presumably made against tiny spring-like contacts in the phone, which sound very much like something that would be prone to intermittent failure through dust sand, grease, vibration, and so on.
"I wouldn't be surprised if there isn't also an element of the fact that the contacts on SD cards are small and presumably made against tiny spring-like contacts in the phone, which sound very much like something that would be prone to intermittent failure through dust sand, grease, vibration, and so on."
Possibly, but I suspect unlikely. When did you last have a SIM card fail?
SIM cards use a VERY different technology, they have a few hundred kilobytes of EEPROM, NOR flash, or sometimes SLC NAND, all of which stores single bits of data on relatively large MOSFET gate capacitors.
SD cards use hundreds of layers of stacked QLC NAND, which stores 16 different values (4 bits) using the analogue value of each tiny gate capacitor, and the gates themselves are much, MUCH smaller. It doesn't take much in the way of excessive temperature or quantum tunneling to knock a gate charge off by the 6% needed to change its value.
They paint over the cracks with an utterly ridiculous amount of error-correction codes, but my guess would be they don't actively read and refresh data like DRAM does. Instead, the SD card looks at the error correction codes when it reads each block, and will relocate the block (thus refreshing it) if the block has correctable errors, so, something that has sat on the SD card for a long time as a read-only and rarely-read file such as "Worzel Gummidge's Greatest Hits" will eventually suffer from bit-rot.
It's also possible that the SD card will suddenly claim to be blank if more than a certain percentage of reads are bad.
I'm not sure how the QLC NAND on the phone itself is kept in better nick though. My guess would be that the Android OS would deliberately go round and read files/blocks periodically so that they can protect them from this bit-rot. Conveniently they probably don't bother to do this for SD cards, because as Dabbsy suspects, Google wants them to go away so that it can force people to buy more expensive phones.
(I just realised your post was about the contacts of the SIM cards, not the memory tech, but my post still stands^ :) )
This post has been deleted by its author
"Possibly, but I suspect unlikely. When did you last have a SIM card fail?"
I don't think that's as likely. Even though the contacts are similar, a SIM has very little data on it. A phone can read that when it first becomes available during boot, store the kilobyte at most it needs in memory, and never go back to it until the next boot. Nothing would happen if the card subsequently becomes unavailable, and since the phone can't write to it, there's no chance of a hardware problem during one of those. An SD card can both be read and written and does so periodically while the phone is on, so it has more chances to have a disconnect when needed. Combine that with poor handling in software and it could be part of the problem.
> since the phone can't write to it
Huh? I remember storing my contacts on the SIM card (pre-smartphone times), which was quite convenient when changing phones. So you can write on a SIM, although AFAIK only contact data, a perk which has become kind of useless in smartphone times where Google/Apple take gently care of your data. Just tell Google to call whatshisname, you know, that one -
Excuse me, the telephone is ringing.
"and since the phone can't write to it"
Both Phone director contacts and saved SMS messages are written to the SIM card. Most smartphone these days will still give the option to save contact data to the SIM card and even copy your phone book to it. The SIM only takes a number and a name though, so you lose all the extra contact information that the phone directory app might contain.
About 3 years ago. Honestly. Between looking at the phone at 10am,abd looking at it again at about 11am, the SIM turned into a price of plastic with a boring gold-coloured pattern on it. The help desk at whoever I was with at the time were a bit surprised!
he contacts on SD cards are small and presumably made against tiny spring-like contacts in the phone, which sound very much like something that would be prone to intermittent failure through dust sand, grease, vibration, and so on.
However, those contacts are either sliding, in which case a remove/insert will wipe them clean(er), or the card lives in a flip-up cradle inside the phone, underneath the battery[0]. In the latter case, with the effort removing the card it will only rarely be removed and reinserted, but ot now lives in a fair bit cleaner environment.
[0] presumes a removable battery and a non-slab model phone.
Yes, the car was rear ended after about 3 years of recording, played back the footage on the camera to see what it caught, everything and then mounted it on my computer to upload to insurance company. So either I was lucky and got a good SD, or the Chinese make damn sure that the SD can read in any condition.
SD card quality (and/or brand?) is important. The 4-year old SD card in my phone contains (among others) some 10 GB of professional documentation I might have the need to consult. Actually I only need it once in a blue moon (~2-3 years), and obviously only tiny parts of it, and while I admit I haven't checked it all, the bits and parts I did consult so far were all there. No bit rot.
(On the other hand the previous SD card on that same phone (with the same data) only lasted a year before going all read-only on me. Go figure. Both were mid-price 32 GB cards bought at my supermarket.)
"no one even knows how many the Americans have"
In the parts of the States that I have been in[0], they are not actually all that common outside government buildings, so-called "red light cameras" (which usually have a TCO much more than the revenue generated and so are not replaced when they break), traffic cameras (which are usually too low in resolution to see anything more than stopped traffic, or are b0rken and/or so filthy you can't see anything with them) and private security systems. Various communities try to get public surveillance systems installed for the usual reasons (deter criminals, "the children", etc.), but the curtain twitchers usually get overwhelmingly out-voted by the sensible people who refuse to spend perfectly good public funds on useless pervasive and privacy invading technology.
[0] All over West of the Rockies, most of the Easter Seaboard, and almost all of the major cities in between.
How many home owners have their own cameras?
The oft-quoted figure for the UK included cameras set up, owned and monitored solely by property owners and shopkeepers. An equivalent figure in the US would have to include all of those, plus police bodycams, car dashcams, every visual sensor set up anywhere by anyone to monitor anything. Are you *sure* there aren't that many?
SD cards are so simple (they are basically just a NAND chip on a PCB) that unless the card is properly dead you can assume the fault is in the host device (which is where the controller is).
What you are describing is a known bug with Android devices, occasionally the 'check the SD card is readable and warn the user if it is not' and the 'mount the sd card' processes run in the wrong order, so the mount process runs first.
The default behaviour when trying to mount a blank sd card is to format it and create a partition, but because it is running out of order it just gets stuck in a loop of continually wiping the sd card in the background.
You will have to ask Google why they think that wiping all data without asking the user is a sane default.
SD cards are so simple (they are basically just a NAND chip on a PCB)
While I know that was basically the case with xD cards, Smart Media and certain other early card formats, I'm pretty certain it's not the case with SD - all SD cards have a controller onboard which translates between the NAND and the interface, which is how larger sizes have been more easily accommodated than with the other formats:
Wikipedia: memory card formats technical details
M.
SD cards have an onboard controller. It knows how big the NAND chip is and the size the SD card is purporting to be. It maps the read and write operations to the right place on the NAND chip. As NAND storage has a limited number of cycles it can change where the data is stored to different places on the chip.
I have come across counterfeit SD cards that have a much smaller NAND chip than the controller asserts to the host. They work just fine till the size of the NAND chip is reached then start overwriting data. It's often quite hard to tell this is happening until something you try to access has been overwritten. Frequently people don't notice for a long time as it takes them quite a while to get their device to over 25% full. I have also seen SD cards that go into a super slow write mode as NAND capacity is approached so they can avoid the overwrite and preserve the lie that they are a lot smaller than they claim.
If the config of the controller (stored on the NAND) gets corrupted if can completely forget where recorded data was stored. Attempts to read the data could all just return the contents of an empty block instead of the blocks where the required data is actually stored.
I'd blame Androids mistreating of SD cards. I've only had 1 micro SD card fail on me, despite the fact i have more than 20 in various devices.
I abused a micro SD card in my old windows phone for years without an issue. Once i swapped to an Android phone i had my first SD card failure with vanishing files.
I think the filesystem may have something to do with it too. Most the time people use them as FAT32 and it craps out fairly quickly. exFAT or F2FS seem to work much better as they seem to be made for flash devices rather than something that was designed before such devices even existed.
Then there's the people who use the wrong type of SD card for the job. Don't plonk a standard micro SD card in a dashcam, you'll kill it pretty quickly. Throw a high endurance card in and you won't have any problems (currently on my 4th year with a Sandisk high endurance with no issues).
Was going to say this myself, Android doesn't have a clearly defined standard for the format of SD cards so it's down to the OEM. My Nokia 6.1 doesn't support exFAT for example so I can't put large video files on the SD card. I suspect, as with most of the problems with Android, that fragmentation is the problem. If Google didn't leave so much up to the OEMs it would be a much better OS.
MicroSD as a format isn't the problem here, the problem is largely IMO down to the insatiable desire for scammers to flog remarked cards to gullible buyers, who then sooner or later see their superduper top of the range card fail, and start complaining that such and such a brand is a pile of crap, without stopping to wonder how it was their supplier was able to make a profit by selling the card to them for X, when other suppliers seemed unable to offer the "same" thing for anything less than at least 2X and often somewhat more. There's only so much cynicism you can apply when it comes to presuming that some suppliers are just trying to rip you off with stupidly high pricing, before you really do need to start wondering if there's a less agreeable reason why some suppliers can undercut by such huge margins....
I only ever buy cards from trusted suppliers, and each one is tested on delivery to ensure it's able to store and retrieve its stated capacity. Consequently, the total number of SD cards (normal, mini or micro) I've had fail once put into service in whichever device (phone, tablet, dashcam etc) they were bought for is currently holding steady at a big fat zero. The only times I've suffered data loss from genuine cards whilst being used normally was back in the bad old days of SmartMedia (oh, what an ironic name for such a dumb format), which were rather more fragile (both physically and at the storage format level) than any consumer-focussed storage media ought to have been. Not at all sorry to see the back of those damn things.
I've used Nokia phones until very recently. In getting on for 20 years of memory card use, I had one sd card failure in a Nokia, which I ascribed to the fact that I used a no-name brand instead of a major name. In the last 3 years, I've been using a Huawei, with Samsung memory cards and both have failed. I've bought from the same reliable source I've always used. The cards lose the ability to reformat, save or delete. I've used specialised software to reformat the card, but no dice. In these cases I have ascribed the fault to the phone, but whether software or hardware I have yet to find out
I think the issue is how much the card is written too.
As much as I understand the below is true. Happy to be corrected.
All SSD media has a finite amount of times a cell can be written too. More expensive cards for things like video seem to have more space for spare cells to replace as cells wear out.
I use microSD in cycle and car cameras as well as Raspberry Pis, and have had cheaper cards (decent brand but basic spec) go "bad" where I can't write or sometimes read them in a few months. video rated cards aren't that much more expensive but last a lot longer.
As for Android, it seems to write all sorts of crud to a card, even if you only attach to pull some data off, so I suspect it is constantly chatting and writing to a card. I've given up sticking my camera cards in Android.
I have found MicroSD cards to be very unreliable.
Oddly enough the full size ones don't seem to suffer from the same problems, even though they are supposedly the same technology.
For that reason, I now make a point of always buying the full size cards for my camera rather than the "MicroSD with a full size adaptor" sort.
Most readers especially the ones with a plastic housing, will at some point fail (like immediately ?), causing the write protect bit, of the reader, to be falsely asserted. The write protect mechanism is implemented in software. So you put your card in the device, the device says ts write protected, and that's that. You take the write protected card , you put it into a brand new reader, you format it with the SD card association utility, not the rufus and windows file manager crapware/bugware sd utlities, and the card suddenly works. Minus any data it had in it.
So now you think to yourself, did I just format this card for nothing ? Lets try the new reader without the formatting. And ... it works.
I even had a card that was as flagged as read only by its embedded microprocessor according to diagnostics utilities. A card that was unsealed 3 hours earlier. A card that was used twice to copy in total 3 files. Suddenly it is "write protected" from its internal ucontroller according to the diagnostic software. Enter a new sd card reader for the PC and the permanent internal read only flag is gone. Poof.
Conclusion, moral of the story.
Don't buy expansive sd card readers. You will throw them away soon enough. Don't buy dirt cheap ones either. You will throw them away immediately, packaging included. Don't use 3rd part software/bugware/crapware, like windows, rufus etc to format them. I understand that people will disagree, so if all else fails use sd association software to format the card. If your card goes dead don't throw it away, try with a new sd card reader. If you are so inclined get an stduino or an arduino (don't forget the coal to power it up, in the case of the later), and make your own reader. You can find the software online if you need it ready made.
One successful read operation will do the trick, to get the card working again.
And keep in mind that every time you slot the card into the reader you wear the reader down, the write protect pin which has absolutely nothing to do with the write protect plastic switch on the card housing.
The internet if full of people copying each others pages offering the same useless advice. Like use partition manager, diagnostic utils etc etc. You will need to do some digging to get your problem sorted.
You bought a Huawei device.
Which particular (?US?) branch of the spook community do you represent?
The best conspiracy theory I heard as to why Trumped got Huawei and other Chinese companies blocked is because they were not cooperative enough about giving secret access to what the public was up to. Apparently, they kept asking for court orders etc.
What is happening is failed attempts by criminal organisations, such as RIA, MAFIAA and the NSA to see what is on the card, and the security system wipes it as a precaution.
I remember most android phones now defaulting to encrypted storage, so if the key somehow gets mangled, the card shows blank.
Same with swapping into a different device, key is different, files don't show up, card looks blank/unformatted.
It also prevents the easy copy of 15 minutes of 4K video by popping out the card, since a PC can't see it, and of course the end user can't get the key...
If “Duck” is also a verb, then the indicative mood conjugations would be
But don’t forget the imperative and subjunctive moods:
and
to earn a dime for the hapless, destitute, starving 'brands'.
p.s. while this fits neatly into my conspiratory mindset, I must confess, I never had my micro-sd deleted in such a spectacular fashion. That said... I do keep backups, of sorts, i.e. my music lives on my hdds (sadly unbackuped), and I only copy / delete from / to micro-sd card as I hear fit. But then, my Android is a 6 on one handset, and a 4 on another, both as deadly as a motion-detection hand-granade in your pocket.
I only had one phone that ate microSD cards. There was firmware a bug where it might be powered off to save battery and then turned back on at the wrong voltage. Oops.
Other than that, it's all Google. They've been slowly adding bugs and changing APIs to ruin non-cloud storage.
https://www.xda-developers.com/android-q-storage-access-framework-scoped-storage/
Not only does this ruin the usefulness, but also slows down random access by something like 10000 times. OsmAnd+ went from interactive map browsing to not finishing launching in a day.
There's a great workaround: Don't use Google Play Store. Apps in F-Droid and other locations can still access the fast filesystem APIs. I have 1TB with 120MB/s reads and 95MB/s writes. Not bad for a phone.
"DDGed" has been around for a while. The earliest reference I could find on ElReg is here:
https://forums.theregister.com/forum/containing/2528528
If you can't be arsed to look, it's a post from W.S.Gosset, dated Thursday 21st February 2019 14:04 GMT
I'm absolutely certain DDG was verbed in other forms by other people earlier than this.
Here's one ("ddg it"):
https://forums.theregister.com/forum/containing/2361788
Post by thomas k., dated Tuesday 18th November 2014 07:16 GMT
With regards to android and SD card there could be a many modes of how it fails. I guess it might be down to bad reading of the file system allocation tables ( could be EMC or just some marginal flash disturb errors). This could result in the mobile OS not thinking there is a formatted flash card. This could trigger oh there is a blank card in let us format it service.
With nand flash cards you need to get the read write usage right if it doesn’t have global wear leaving. Too much frequent write and you will kill it, mostly reads only and bits will start to flip. The way to keep it good is to copy the files off ( not an image ) reformat it copy the files back on. This will get rid of an read disturb issues you will get via playing the same old mp3 over and over again. You can buy cards with global wear levelling ( which can negate NAND flash read disturb errors) but they are ten times more expensive.
With regards to Pi booting from SD.
Standard SD cards will fail eventually if they do not have global or static wear levelling. If you are putting standard SD card into product you can not easily get to and replace you will be in a world of pain. There are techniques you can use like read into ram then never write which will make a standard SD card last a long time ( based on number of reboots). You could maybe use SPI flash for write storage instead with read and write disturb aware file-system or just use NOR flash with it’s slow erase time.
If you are gong to use a standard SD card then chose one that has android run support A1 or A2 as the flash endurance will make it last longer (like Sandisk).
So the way SD cards fail is that with read disturb multiple reads cause adjacent flash cells levels become harder to differentiate between a one or zero then you get bit flips on reads. These bit flips cause invalid files and file-systems, this makes your PI a bit flaky. If you reformat the SD card the it will be fine but the fact the pi can’t boot makes this difficult to solve remotely. If you are going to put PI in the field running from SD card make sure it has global wear levelling SD card as this is the only thing that can stop read disturb issues, they are expensive for a reason!
SanDisk HIGH Endurance microSDXC 64 GB per CCTV Domestic & Dashcam, read 100MB/s 40MB/s in write, Class 10, U3, V30, -15C to +85C.
about 20 euros here in Italy for product SDSQQNR-064G-GN6IA
W.D. claim “ High endurance lets you record and re-record
Writing and rewriting can take its toll on a memory card, but this card is built to stand up to the task. The 256GB capacity card is engineered to handle up to 20,000 hours of worry-free recording” and listening to Bowie?
I’ve moved to these cards for home CCTV & R-Pi DNS blocks, as AMZN sourced standard uSD have a limited life
Data: https://documents.westerndigital.com/content/dam/doc-library/en_us/assets/public/sandisk/product/memory-cards/high-endurance-uhs-i-microsd/data-sheet-high-endurance-uhs-i-microsd.pdf
TimeMachine is proprietary isn't it?
Proprietary meaning that anything up to and including witchcraft could be involved in keeping data safe.
But how does one effectively prove that TimeMachine is actually backing up data? If there were bitrot at one end of the medium (ah, that's where the witchcraft bit comes in), does it affect the rest, etc.?
Time Machine backups could be implemented in about 50 lines of code. It recurses depth-first through the filesystem. If a file/directory has no changes, a hard link is made from the previous backup to the latest backup. If a file has changes it makes a copy. If a directory has changes it creates a new one in the backup then recurses for the contents. Cleanup is as simple as deleting old hardlink and letting the filesystem garbage collect.
The complexity burden is entirely placed on the filesystem, and that IS buggy. Tens or hundreds of millions of hard links become difficult to track. It can run out of memory, fail to finish a long critical operation before sleep/power-off, or just goof up. Silent corruption creeps in and it's eventually FUBAR. Web & E-mail computers can be fine for 10 years. Software development computers might have corrupted backups in a few months.
I'm not sure I'd put that on a microSd card. The I/O is brutal once it reaches a steady state of adding and removing backups.
We were using SD cards for booting our early ports of Linux kernels onto Philips ARM9 SOCs .
The SD cards used to die with monotonous regularity.
Eventually we worked out a theory as to what was going on, partially guided by reading patents from the big name SD card manufacturers.
When an SD card is formatted in the factory it is FAT16 or FAT32 formatted.
It turned out from the patents that at least some of the flash controllers would do flash write levelling by directly using the DOS FAT File Allocation Table data to decide what was used and unused data on the card.
If we formatted the card with a Linux file system, in our theory, the FAT region (left untouched in the Linux partition and format ) still reported a basically empty card to the wear levelling - so almost any sector was fair game for a rewrite.
Our ext2 file systems would get trashed by something as we kept on writing yet another root file system or system start up logs.
What we did to solve the problem was to keep the FAT formatted partitions.
Then allocate a large data file using the FAT file system.
Then loopback mount the data file as an ext2 formatted file system. (whatever we had as state of the art in the 2000's )
Activity in the loopback mounted file system would then appear as random writes to the FAT file system, wear levelling would "realise" we meant to use the allocated blocks in question. So it never went and trashed our file systems.
We just arranged our Linux machines to boot from FAT ..
We were much happier with our SD cards after that, they lasted a lot longer.
I wonder if this is still going on - direct mounting SD cards as Linux file systems causing problems with the SD cards embedded controller assuming FAT formatting and wear levelling by stealing your data. .
As an aside, at another employment we found that the Samsung EVO 3D Multi Level Cell (MLC) technology SD cards were head and and shoulders ahead in write cycle lifetime, ahead of even some special "robust" industrial Single Level Cell (SLC) tech flash cards.
We were investigating loop writing video and audio into a storage device as a black box and we wanted years of lifetime. The Samsung cards would have delivered.
Has anyone tried f3, check if it is a 'fake' flash memory
# f3probe /dev/sdb
F3 probe 8.0
Copyright (C) 2010 Digirati Internet LTDA.
This is free software; see the source for copying conditions.
WARNING: Probing normally takes from a few seconds to 15 minutes, but
it can take longer. Please be patient.
Probe finished, recovering blocks... Done
Good news: The device `/dev/sdb' is the real thing
Device geometry:
*Usable* size: 14.84 GB (31116288 blocks)
Announced size: 14.84 GB (31116288 blocks)
Module: 16.00 GB (2^34 Bytes)
Approximate cache size: 0.00 Byte (0 blocks), need-reset=no
Physical block size: 512.00 Byte (2^9 Bytes)
Probe time: 2'12"
Had 2x Nokia 5800XM phones wipe no less than 5 cards (3x8GB, 2x16GB), so its not just an android conspiracy (its a Symbian one too perhaps). The cards would work OK for about a month or 2 then either wipe the contents or show signs of data loss.
All 5 of the cards were not actually dead/dying as they all still work fine to this day (each card has been tested thoroughly) in various phones, mp3 players and readers.
Never had any failures while in an android device in the literally dozens of card bought!
I had this happen to me just last week and every website I went to told me to take it out clean it reinsert it and it that doesn't work reformat it. Not one mentioned that reformatting it will wipe the contents FFS. I backed up all my photos before I copied them to the SD so nothing was lost, but I still have a nagging feeling there was something else of inportance on there, so it is currently sitting on the sidewaiitng for me to make an image and start trying to recover it.
I’ve got a Western Digital NAS downstairs that runs Windows Server 2008 or such, and that thing NEVER stops shuffling something on the disks. Same as my Win10 PC. I leave it on all the time, don’t bother putting it to ‘sleep’ or whatever, and it, too, never ceases chattering data back & forth.
I mention this because the modern cellular also never really shuts down, and meanwhile it could be running your SD flash device to death. For all anyone knows?
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
