This is quite a serious problem, and probably related to why we see the suggestion to use class 4 cards. In repeated attempts to access the microSD over USB, writes have been ignored. Earlier I also got filesystem corruption, suggesting that some may be misplaced, which is even worse. It is not USB specific as attempts to make changes from the Files view also fail; can't rename, no space, can't move... the card isn't write protected, the filesystem is a perfectly accessible vfat, and a move doesn't require any space (unless it needs to grow a directory, and the root directory which I moved to cannot grow) - besides which, there was plenty of space. It doesn't even consistently fail, as one attempt to remove a file instead created a second, empty file. Perhaps it ran creat() before rename() to make sure it didn't overwrite another file, and only the creat() took effect.
It appears the PocketBook device has a kernel bug, causing it to fail to write to this SD. If higher class cards
tend to work, this is indicative that it simply presumes to talk to the card at higher speeds than it can handle.. and the SD class does
not guarantee it will work, because you don't know the access pattern as a USB storage device. Also, if you fail to write, bloody well report it! Silently dropping users' documents is inexcusable.
This is all with firmware 2.0.4.
A bit of reading up in the
SD spec suggests that, if it is as I suspect, the busy status any write may indicate is not respected. The interesting section is in the middle of page 31 of part 1: "Some cards may require long and unpredictable times to write a block of data."
I'd be willing to take a look at fixing this, but it would of course require root access on the device as well as kernel source code. And possibly a little documentation from Samsung about
S3C6410, as it seems it should have an SD host controller; the bug is nearly certainly theirs, anyway.