Accidental Sd Ejections

[rv6502]

(I mentioned it in another thread, but it was rather OT so I'm making this thread)

I tried running Linux on an iPAQ PDA from an SD card, one big problem I found was it was too easy to accidentally eject the SD card, that would make the whole system go belly up with a nice irrevocable kernel panic.

if we use one of the SD slots as a "system/software drive" with all the user apps and a swap space (for the occasional gimping) what is going to happen if we accidentally remove the SD card ?

GEOS on C64, Amiga OS, MSDOS, and other floppy (removable media) based OSes have a dialog box asking to re-insert the media, but Linux does not expect its system drives to be pulled from under its feet at all (afaik).

memory swapping will be almost essential for doing work with the Pandora (not games, real work = VNC, Firefox, telnet/ssh/ftp, OpenOffice) where it would allow you to switch between multiple programs, each using a big chunk of ram but individually not having a large ram working set.

aside from the extreme solution of software RAID-ing both SD slots to survive accidental ejection of 1 card (and you lose the advantage of having 2 slots), is there kernel support for graceful recovery ?

 

[Kramy]

I'm not sure, but I know they were considering some sort of memory compression. Basically, rather than paging to SD, they page to gzip'd 4MB page, or something like that. Sounds like you'd be an ideal candidate.

If implemented in the kernel, the 256MB might act more like 400MB, which should be sufficient for a few of the tasks you listed, if not all.

 

[dflemstr]

If a swap dies, bad things happen. You can of course create multiple swap files, one for each SD card you've got, and configure /etc/fstab to mirror those swap files only, so you don't have to have full raids but can instead use "swapmirrors" (dunno the official name for it).

So if you want 1 GiB swap, create two 1Gib files one ach SD card, add them as swap in the fstab or alternatively use some "swapon" flags so that they both will be containing the same pages, and bam, you've got redundancy.

Oh, and most apps are capable of dealing with removed disks. In desktop environments, you might see icons disappearing or text being replaced by a string of boxes (if you know what I mean) but nothing more serious than that should happen. Just don't pull out the SD card while doing something critical with "dd" or while reflashing your NAND with a file from a SD card or something. The Linux kernel will also to some extent "pool" old file requests that have failed due to "Resource unavailable", so when you insert the SD card again, queued up file requests should get processed and everything should resume as if nothing had happened.

 

[rv6502]

If a swap dies, bad things happen. You can of course create multiple swap files, one for each SD card you've got, and configure /etc/fstab to mirror those swap files only, so you don't have to have full raids but can instead use "swapmirrors" (dunno the official name for it).

So if you want 1 GiB swap, create two 1Gib files one ach SD card, add them as swap in the fstab or alternatively use some "swapon" flags so that they both will be containing the same pages, and bam, you've got redundancy.

Oh, and most apps are capable of dealing with removed disks. In desktop environments, you might see icons disappearing or text being replaced by a string of boxes (if you know what I mean) but nothing more serious than that should happen. Just don't pull out the SD card while doing something critical with "dd" or while reflashing your NAND with a file from a SD card or something. The Linux kernel will also to some extent "pool" old file requests that have failed due to "Resource unavailable", so when you insert the SD card again, queued up file requests should get processed and everything should resume as if nothing had happened.

the kernel is unlikely to "pool" file requests for a removed media.
when it detects a media removed it'll just return an error to the app, and who knows what the app will do then.
most likely the app will crash or ignore the error (outside of well-maintained apps)

the ideal is not to have redundancy in the swap file but to have the kernel pause/hold until the media is re-inserted, verify that it really is the same media, and then resume like nothing happened.

 

[polyroy]

the ideal is not to have redundancy in the swap file but to have the kernel pause/hold until the media is re-inserted, verify that it really is the same media, and then resume like nothing happened.

Err... consider the implementation; verification of swap is virtually impossible, unless you recalculate a hash on every write into swap, which is painfully slow. Also, when a card is ejected during a write, verification is not even possible as you have no idea what state the flash is in. The only way to do this is to use some kind of swap journalling, and boy, is that ugly and complex So we remain with unverified swap to which the last swap-out operation was probably interrupted and must be re-done. Implementing something like this (without verification) is somewhat possible.

Now, the advantage will be that your system will not crash when an SD card is ejected, instead the kernel will "only" suspend every userspace app which happens to have a page swapped out, so in most cases making the pandora completely unresponsive. AFAIK, you can't tell the kernel not to swap out specific apps. You won't be able to do so properly, and you wouldn't want to restrict the kernel in swapping out apps which aren't constantly used anyway.

You are asking quite a bit of effort for protecting the few people who don't understand that they shouldn't eject the card they have set up a swap partition on, but simultaneously do understand how to make and activate that swap partition. Also, the Pandora comes with two SD card slots (and a USB Host port), so I personally wouldn't really mind if my Pandora expected me to dedicate one slot to internal functions if I use it for out-of-the-ordinary purposes which require said swap.

Edit: that reminds me. Does the Pandora have a reset switch/keyboard combo somewhere? I know the magic SysRq key can help a hung kernel for most systems with a 104-key keyboard, but it is obvious the Pandora is a bit limited here. Or are we expected to pull the battery if such a thing occurs?
Edit2: Nevermind, I just had to search.

 

[rv6502]

the ideal is not to have redundancy in the swap file but to have the kernel pause/hold until the media is re-inserted, verify that it really is the same media, and then resume like nothing happened.

You are asking quite a bit of effort for protecting the few people who don't understand that they shouldn't eject the card they have set up a swap partition on, but simultaneously do understand how to make and activate that swap partition.

sorry if I misdirected the discussion off topic with my swap file example, I am talking about ACCIDENTAL SD card ejections.

I'm not talking about "people who don't understand": its extremely easy to eject an SD card unintentionally (as well as other push-and-it-pops-out medias), not only full ejection but sometimes with vibration the contacts between the slot and SD cards disconnect slightly and the card needs to be reset with a full ejection and re-insertion.

in the case of the Pandora, one could try to grab the lid and base to open the Pandora and accidentally push the SD card in enough that the mechanism ejects it.
the Pandora might slip from your hands and as you catch it you depress the SD cards...
this kind of stuff happens regularly.

its simple enough to push it back in, but by that time the Linux kernel or the Applications might have gone belly up to various degrees and need to be restarted.

 

[Squidge]

Since you must instead use your finger nail to push the card in so that it pops out, I fail to see how you are going to eject the card accidentally by grabbing the device/etc. The card will be flush with the casing otherwise.

Similarly, if the card stops working under vibration, then you either have a faulty card or a faulty card holding. Either way, it should be replaced under warranty.

If this does indeed happen regularly for you, then you have a badly designed or built device.

 

[nikkopt]

Pandora's SD card sockets don't have an ejection mechanism. Like Squidge said, you need to use your nails to take them out..

 

[polyroy]

I'm not talking about "people who don't understand": its extremely easy to eject an SD card unintentionally (as well as other push-and-it-pops-out medias), not only full ejection but sometimes with vibration the contacts between the slot and SD cards disconnect slightly and the card needs to be reset with a full ejection and re-insertion.

Ah, accidental in that way. Sorry for the misunderstanding. How much of an issue that is depends on the connector used, of course. I do hope some vibration testing has been done to assess the stability of the connector during IO operations, I own a Treo 750 (quite the popular device) and for some reason it keeps ejecting the miniSD card irregularly (in software, forcing me to do a manual eject and re-insertion, although non-fatal), so I am fammiliar with the problem as well. This could be due to dirty contacts, some faulty design, or even just because Windows Mobile likes to mess with me. Anyway, I'm not too confident either it will be "perfect" without sufficient abuse testing by users. But what Squidge says does help boost confidence

Still, if it proves to be a problem due to a wrong design, I'm sure it will get proper attention. You should also realize that it won't be all that common to have users activate the swap on flash memory. I'd even be less than eager and would actually want my kernel to kill apps when they request too much memory, rather than wear out my flash media. In my opinion, it's too early for a verdict on accidental ejection, especially considering Squidge's opinion

nikkopt: note that Squidge didn't say it didn't have an ejection mechanism; he even said you'd have to push the card in to get it out It will just be hard to do accidentally.

 

[nikkopt]

nikkopt: note that Squidge didn't say it didn't have an ejection mechanism; he even said you'd have to push the card in to get it out It will just be hard to do accidentally.

Ur right..

http://www.molex.com/molex/products/datasheet.jsp?part=active/0679130006_MEMORY_CARD_SOCKET.xml&channel=Products&Lang=en-US


oh well, another *facepalm*

 

[rv6502]

Since you must instead use your finger nail to push the card in so that it pops out, I fail to see how you are going to eject the card accidentally by grabbing the device/etc. The card will be flush with the casing otherwise.

that's great news.

if not, it'll motivate someone to add a kernel workaround

Similarly, if the card stops working under vibration, then you either have a faulty card or a faulty card holding. Either way, it should be replaced under warranty.

If this does indeed happen regularly for you, then you have a badly designed or built device.

or I'm abusing the device my dash cam is starting to have problems after 3 years of car vibration.

but aside from that extreme case, my DS sometime has trouble reading nintendo cards (similar form/mechanical factor), my iPAQ also requires SD re-insertion regularly, and various SD adapters/readers I use can get finicky... its the NES all over again.

some cheap SD connectors in brand name devices scrapes off the gold plating layer and some cheaply built brand name SD cards have their layers scraped off just by looking at the pins in a mean manner.
But in either case you don't know until weeks of usage.

my guess is that they last a long time if they're just kept within the phone or digital camera which is the expected use, when you start using them as floppies for file transfers the insertion cycles multiply and they wear out really fast.