Swapping Sd Card Without A Power-off

[shrubberyrobbery]

Basically I'm using Win98 so to copy files to my SD card I have to use a separate card reader. No problemo.

However, I always switch off the gp2x before taking the card out, copy files onto it, put SD card back into gp2x, and THEN switch the gp2x back on. Is this really necessary?

or is it perfectly safe to remove, and replace the SD card while the gp2x is running?

 

[Targus]

it works fine for me

 

[woogal]

As long as you're not accessing any files on the gp2x at the time you remove the card then you will be safe. However, with flash media you sometimes won't know if you're accessing the card as it could be waiting to write data. Most apps will try and sync the data before they exit, but I've found that it sometimes takes a few more seconds after the call to sync before anything happens, so if you exit back to the main menu then wait for a few seconds you should be safe. In fact you should really do this before switching off if you've done anything like saving games otherwise they could get lost.

Every now and again though you'll find that things won't respond well after you re-insert the card, which seems to be down to a buggy sd driver (it's not as bad as it used to be though). If this happens then a reboot will be needed, but nothing should be corrupted on the card.

 

[vic20-ian]

I've been doing this when recompiling Vice and testing keyboard configurations and it works fine 99% of the time.

Occaisionally it loses track of the directory contents and I reboot. Otherwise it is pretty slick.

 

[luteijn]

To prevent corruption, you ought to run a little script to unmount the card properly using the umount command...

 

[shrubberyrobbery]

thanxs guys.

I think I am going to make a little umount script to run from utilities
so, i can make a text file called umount.gpu with the line:

umount /mnt/sd

is that all I need? Will this really do it?

The man pages (on the pc I'm logged into at the moment) for umount says:

Note that a file system cannot be unmounted when it is `busy' -
for example, when there are open files on it, or when some process
has its working directory there, or when a swap file on it is in
use. The offending process could even be umount itself - it opens
libc, and libc in its turn may open for example locale files. A
lazy unmount avoids this problem.

so do I need the 'lazy' -l option? :

-l Lazy unmount. Detach the filesystem from the filesystem
hierarchy now, and cleanup all references to the filesystem
as soon as it is not busy anymore. (Requires kernel 2.4.11
or later.)

 

[nickspoon]

The newest firmwares (I think from 1.1.0, possibly, but definitely >=1.2.0), automatically unmount the SD when it's removed. There's no longer any need for that script.

 

[Squidge]

don't forget the auto unmount will only work if there's nothing accessing the sd card at the time, so only remove the card when your at the main gp2x menu. If you remove it when running an app/emu/etc then the unmount will fail and so the next card you put in will not be mounted properly, and could have its contents corrupted, as the OS will still think it's the last card with the last contents.

Also, if any emu/game or app writes a file to the card and doesn't sync() then only a umount run from a script will properly unmount the card - the automatic umount will not work as the card is still in use - a partial write has started, but will not be finished until it's been told to sync. A umount causes a sync, but of course it'll fail if the card isn't there any more.

This is normally what happens when someone complains 'emu x killed my sd card' - a write took place and wasn't finished due to a missing sync() call, so it's the same as removing the card half way through a write.

I don't think the usb connection does a sync on exit either...

Sigh... Why couldn't GPH just mount the card as sync? Then it wouldn't bother with the buffering and wouldn't corrupt cards unless you ripped it out whilst it was actually writing data.

 

[BradN]

I don't think the usb transfer function would need to do a sync - caching is only done within the filesystem drivers... raw access to a device isn't cached I don't think.

 

[Squidge]

If thats the case, then can someone explain why when copying a file or making a directory through the usb link and then quiting the usb link and turning off the gp2x, that the file or directory is no longer there? or is this fixed in later firmwares?

EDIT: Hmmm, or you could be agreeing with me, as I see you are using a double negative.. "isn't cached I don't think" - so it is cached?

 

[luteijn]

You can't just umount /mnt/sd. It's not in the /etc/fstab anymore, as it's under automounter control.
You can make the script a little smarter so it will try to umount using the /dev/ part (shown when you type mount), and lets you know if it succeeded ('you can now eject your SD card' <-> 'oops, something is accessing the card'), by checking mount output again...

If I get some time (maybe next nightshift..), and no-one beats me to it, I'll eventually make such a script + a little support program to display the messages on the graphical screen.

P.

 

[BradN]

I stand corrected. I swear I tried some stuff once (reading a block device), and every read would cause disk activity, but I just tried it now, and lo-and-behold it indeed caches it. Yeah, certainly shouldn't kill GPH to throw a sync call in there should it...

 

[Squidge]

You can't just umount /mnt/sd. It's not in the /etc/fstab anymore, as it's under automounter control.

You may not be able to do it, but it seems to work for me When I take out the SD card and then remember my bash CWD is still on the SD card, a quick "cd /; umount /mnt/sd" gets things back to normal.