"Eject" USB drive

[atomant]

The quesition: is there a way to -if needed, forcefully- "eject" the USB drive from which the system is running? (Something along the lines of udisks --eject /dev/whatever_the_drive_is_called)

Some lenghtly explanation: i'm running piCore on a Raspberry Pi Zero W. The system should be tolerant to power loss, this is one reason why i chose TCL (runs from memory). I'm fairly sure the SD card never gets written to during a normal run, i've been using iotop to monitor this and saw no disk writes happening. Yet, sdcard corruption is a constant problem. As time passes, files start to become unreadable, i start getting weird errors. I do time to time log onto it to modify things, fiddle with the "firmware" and the SD card does get written to at these times but in such cases i make sure there's no power loss during usage. I tried several SD cards, never used no-name Chinese ripoffs, but the problem prevails (and this isn't the first setup at which i have to deal with this).
So, i have decided to get rid of the SD card altogether (well, almost) and move the system to a USB drive. The particular USB drive is an m.2 SSD adapter. I'm assuming since m.2 drives are intended for usage in computers (rather than store images and mp3 files in cameras and media players) it should tolerate the environment better. As far as i know it's possible to boot from such a drive but it will still need an SD card too to do it, however, this only needs to contain a bootcode.bin file, if this should get damaged it's way easier to replace then the whole system, and i'm also considering trying to find one of those WORM (Write Once Read Many) SD cards for this which should completely eliminate the possibiliy of the SD card corruption. (Before you suggest burning the whole system onto a WORM card, that would make it impossible to make changes to it, and i'm at this point not sure they even make these cards anymore.)
However, even with an m.2 SSD just removing the power abruptly can cause problems (the drive's controller might be doing somesort of maintenance when the power is removed and it leaves the drive in who knows what state). To avoid this from happening, what i'm trying to do is add a big enough capacitor to the device and detect on the rPi when external power is removed, the capacitor should provide power long enough for TCL to detach/eject the USB drive and put it into a safe, turned-off state (this shouldn't take too long i reckon). At this point the power will be gone so i don't care if the system itself locks up or whatever might be happening to it. A short dip in power that could trigger this but does not actually result in a complete powerloss is a non-issue here. I would like to avoid having to add a bigger capacitor or battery to be able to perform a complete shutdown of the system since space is limited and if i'm correct with my assumption that there are no actual disk writes, this should be unnecessary anyways.

Thanks for any suggestions in advance.

[Juanito]

Have you tried booting with the copy2fs flag set and then unmounting the sd card?

[atomant]

Have you tried booting with the copy2fs flag set and then unmounting the sd card?

Hey, thanks for your reply.

To be honest i'm not sure how copytofs works but doesn't that only load (copy) the extensions onto the memory drive? I also have a few other things like e.g. a python script and a program written in C++ lying around i need access too. I guess i could try to move those too onto the memory drive and run from there, assuming there's enough space. This approach is worth considering indeed...however, i'm not yet convinced simply unmounting the partition(s) on the SD card is enough because the card and the reader remains powered and still might be doing something to the card when power is removed.

[Juanito]

Once it is unmounted you can take the sd card out of the slot if you really want to be sure...

[xyz-worx]

Hello atomant,

I know the poor performance of several SD cards. Some of
them don't even survive a normal 'aptget update/upgrade'
cycle.
I've made some good experiences with SanDisk Extreme or
Ultra types, because they are 'A1' graded and so much more
ruggedized.

Maybe this helps to get your systems more robust together
with Juanito's recommendations.

best regards
   xyz-worx

[atomant]

Hello atomant,

I know the poor performance of several SD cards. Some of
them don't even survive a normal 'aptget update/upgrade'
cycle.
I've made some good experiences with SanDisk Extreme or
Ultra types, because they are 'A1' graded and so much more
ruggedized.

Maybe this helps to get your systems more robust together
with Juanito's recommendations.

best regards
   xyz-worx

Thank you, i'll keep this in mind when i get a new card.

[curaga]

Re usb ejection: for some USB sticks the "eject" command works. Others may need sdparm.

[atomant]

Re usb ejection: for some USB sticks the "eject" command works. Others may need sdparm.

Thanks for this info. (My USB drive is -unless i’m mistaken- /dev/sda)

sudo eject /dev/sda
-does nothing that i can see

sudo hdparm -Y /dev/sda
-i’m not sure how i’m supposed to use hdparm, i tried with y and Y but both tell me “HDIO_DRIVE_CMD: Invalid argument”.

With both commands, weather anything from the drive is mounted or not doesn’t make a difference.

To make things clear, what i’m looking for is to put the drive into a state where removing power is safe (like, the same thing i would do when i wanted to unplug a USB connected SSD drive on any system without having to worry about doing this at the wrong time.)

[polikuo]

Just some guesses.
You might have some swapping with the card.
Sometimes linux swap memory into specific file for FAT32.
Thus, I'd do it this way, assume you have /dev/mmcblk0.

Code: [Select]

sudo swapoff -a # turn off swapping for anything
sudo umount --all-targets /dev/mmcblk0 # umount all mounting points
eject /dev/mmcblk0 # I don't think "sudo" is a must for the command "eject".