OS does not recognize a removed USB drive or SD card if writing a file

[labviewman]

I have a support ticket open with NI for this but was told to come here and ask for help. I'm not sure why I am directed to a forum for support when I'm paying NI for support, but here it goes.

If I have an open file (and I'm writing to it) on an external USB drive (or SD card), and the user removes the drive without allowing the RT code to close the file (people do stupid things), RT Linux will not recognize the drive as removed, even if I try closing the file after the drive was removed.

Here is what I have found after removing the drive or SD card while writing a file:
1) The drive (U) still shows up via 'List Folder'
2) The code writing the file doesn't return an error
3) Checking the free space via 'Get Volume Info' does not return an error and still shows free space on the drive.

So, my questions are:
1) how can I make the OS detect the drive has been removed (within LV)?
2) how can I 'eject' a USB drive if the user follows proper procedure (allow RT code to close the file), such that the drive doesn't look like a
damaged drive when plugged into Windows?

Seems like I shouldn't have to get down to the Linux level to do this...I should be able to keep the code independent to the underlying OS.

Very strange I'm even seeing these problems...I don't recall any version of Windows having a problem detecting a removed drive

[BradM]

Hi labviewman,

The interesting thing is that it seems to be something related to what LV does when opening a file reference. When attempting to recreate the high-level description of the issue (using dd to write to a file on the USB device and removing the drive mid-write), the system works as it should: IO errors are reported (sanely), but the device removal is detected, the mount point is cleaned up, and /u disappears. I was able to exactly recreate the issue you describe using a simple implementation in LV, and have filed an internal issue on the topic. So, at a minimum, the folks behind NI Linux RT will review the issue and see if and when it can be dug into deeper. If you can PM me the support ticket ID, I'll add it to the internal issue report.

From my prodding around, it seems like there's no easy way (from LV) to correct the situation (my guess is that the mechanism to handle USB device removal does not handle a failure at some point during the cleanup on device removal). There are a few ideas off the top of my head, none of which are great:

• Install sudo and configure it to allow lvuser to run umount, rmdir, and rm to manually do the cleanup
  • Not great, as this gives lvrt user power to corrupt your system if you're not careful
  • Not great, as this shouldn't need to be done by the application
• Write a monitor daemon or actually fix the udev management script (/etc/udev/scripts/mount.sh)
  • Not great, as this is work above what should need to be done to use the system

All of this being said, surprise USB storage removal when the device is using FAT32 is a recipe for filesystem corruption, no matter what OS you're using. The OS can only do so much to prevent this, but there's a reason why Windows offers the "Safely Remove Device" option for removable storage.

[labviewman]

Hi Brad,

I agree, removal with FAT32 is asking for trouble, esp. when the user removes the drive during a write or a file open. 

Another simple issue is that there is no way to 'eject' the drive in RT Linux...the simple act of plugging in the drive with the cRIO for 30 seconds, remove then plug into Windows results in Windows wanting to scan the drive (no code running on the cRIO).  So no matter what it seems the USB drive will want to be scanned in Windows.

How can a drive be safely ejected?

Thanks,

Todd

[labviewman]

I forgot to mention that if using multiple external drives (in my case, 1 USB drive partitioned to 6 32G FAT32 drives) and the user removes the USB cable while writing the drive, then, later, plugs in the cable, the drive that was in-use does not return...the drive remains a ghost drive, unable to be used again.  After 6 cycles of this, you run out of drives since U, V, W, X, Y, and Z are now unusable Ghost drives.  I saw this when I first created the support ticket.  I'd like to confirm this again but the only USB drive I have is being used to collected data 24/7 (old files are deleted when needed, using all 6 drives which fill up in 1 day).

As a side question, am I correct that U, V, W, X, Y, and Z are the only external USB drives that are supported in RT-LInux?

[BradM]

---

@labviewman wrote:
...

As a side question, am I correct that U, V, W, X, Y, and Z are the only external USB drives that are supported in RT-LInux?

---

This is the case for the legacy locations (/u, /v, etc.) The underlying OS will merrily mount the new drives under the /media/$DRIVE location (e.g. /dev/sda1, /dev/sda2, /dev/sdb1, etc. for a USB drive that has two partitions and a second that has only one partition).