Error 6 writing to USB-stick on cRIO-9068

[BradM]

No, sorry, forgot that I already installed some tools to the machine that I was playing with. Also, if there is a failure in any of the steps, you should stop and report back here since the other steps depend on the previous ones successfully completing

With the filesystem still disabled/removed:

//Okay, this one is a bit complex, it enables the on-9068 package manager

sed -i 's/^#[ \t]*\(.*http.*\)us\.\(.*\)$/\1\2/' /etc/opkg/angstrom*feed.conf

//Update the listing of packages

opkg update

//Install tools, working around a known issue

opkg install --nodeps dosfstools

//Retry the fixup

fsck.vfat /dev/sda1

//Remount the filesystem, my previous command had a mistake

mkdir -p /media/sda1

mount /dev/sda1 /media/sda1

//Check the contents of the filesystem

ls /media/sda1

Basically, a package manager system controls and manages installation of software, taking care to address dependencies between software packages (e.g. if you want to install software A but it depends on software B, which is currently not installed, it will install B first then install A). Initally, the package manager on these controllers are disabled. The steps added above reenable the package manager on the target and install some tools to enable you to work with FAT partition types on your controller.

[BjarkeDM]

---

@BradM wrote:

No, sorry, forgot that I already installed some tools to the machine that I was playing with. Also, if there is a failure in any of the steps, you should stop and report back here since the other steps depend on the previous ones successfully completing

With the filesystem still disabled/removed:

//Okay, this one is a bit complex, it enables the on-9068 package manager

sed -i 's/^#[ \t]*\(.*http.*\)us\.\(.*\)$/\1\2/' /etc/opkg/angstrom*feed.conf

Dy-am do you want fries with that?  Done...

//Update the listing of packages

opkg update

Done...

//Install tools, working around a known issue

opkg install --nodeps dosfstools

Done...

//Retry the fixup

fsck.vfat /dev/sda1

11 clusters have issues...

I correct these by pressing 1.

Leaving file system unchanged? hmm?

//Remount the filesystem, my previous command had a mistake

mkdir -p /media/sda1

mount /dev/sda1 /media/sda1

Done...

//Check the contents of the filesystem

ls /media/sda1

 I can now see the USB-stick and I have write-privileges.

Great! That worked and it seems the USB-stick has some issues. Do I buy a new stick? Are you wiser to the issue based on what you have seen?

---

[BradM]

I would recommend trying to rerun your test and see if this aided in the situation. If not, I would recommend trying a new USB storage device, yes.

Another thought that I have, is that there may be some issue with opening the file, moving to the end of the file, adding on a bit, and closing out the file. If you continue to see issues along these same lines with a new USB device, I would recommend trying to simply keep the file reference opened (pass that around instead of a file path). If this resolves the issue, please let us know since it is just a work around.

[BjarkeDM]

Thanks a bundle Brad!

I am certain that the issue will return. It will just take up to 48 hours. 

I will try to use the reference to pass around instead of the path - that is a relatively easy fix in my code.

Finally I will try with a different USB-stick

During R&Ds abuse of the 9068 have they used a specific hardware-label, in regards to USB-sticks, that you can recommend?

I WILL do all of the above!

And finally even though you made your misgivings about this VERY clear  and it IS a rather nasty workaround indeed!

I would feel sooo much better if I upon seeing the error I could do something like this:

This based on me not having lost any data already stored on disk. I am just not able to write the data I want when the USB stick has issues with its clusters.

[BradM]

If you need such behavior, I would recommend creating a service that starts up at boot and can talk with LVRT. When LabVIEW tells it that there's a problem with the storage, go ahead an fix things up (unmount, fsck, remount). Basically, the simple way to do that would be to have a script that launches on boot that checks for a file to exist (in a location that LabVIEW can write to, the normal place is /tmp). If it sees the file exists, it will do the operations and, when complete, remove the file. If the file doesn't exist, it will sleep for some time (a few seconds, let's say) then check again.

Meanwhile, from LabVIEW, it writes to this /tmp/helpmerecoverusb file then waits for the file to disappear, indicating that the script has done its job and we can continue onward.

This is a simple approach and one that can be improved by one of a few methods, not all of which have native LV APIs (e.g. using a named fifo).

If you want to learn more, I recommend looking into initscripts (http://www.cyberciti.biz/tips/linux-write-sys-v-init-script-to-start-stop-service.html), configure the script to start on boot, look for the file to indicate there's work to do or sleep if it's not there, do the work if it is and remove the file to let LabVIEW know everything's fine. Additionally, logging when this happens to keep some idea of how frequently this fixup is needed would be a good thing to know.

[BjarkeDM]

Update...

Upon further testing with using write by reference:

This seems to have reduced the occurrence of the Error 6. But it is still there.

I have also experienced that the USB-stick has thrown its formatting (i.e. all data is lost)

The USB-stick I am using is a special industrial grade version. (Will get a url-link asap)

I will now try with at regular off-the-self version.

But it really seems like I need to mitigate this error when it occurs using something like a service to take care of the fdsk?

One theory is that i end up corrupting the disk as I cycle the power at the same time as I am writing to the disk? Does that make sense?

[BjarkeDM]

The USB-Stick

WMUFD008G-ADISI-3

[BradM]

---

@BjarkeDM wrote:

...

One theory is that i end up corrupting the disk as I cycle the power at the same time as I am writing to the disk? Does that make sense?

---

FAT32 does not handle surprise interrupts to writing. It will corrupt the filesystem. If you want to do such things, you need to use a filesystem that supports journaling, for example EXT3 for the Linux RT targets. The downside is that Windows machines will not be able to read the USB drive without some additional software installed. Is power cycling while writing to and external disk a requirement of your application?

[BjarkeDM]

Thanks Brad good to know.

There might be a way to provide a "soft" shutdown.

This will entail some rework of the system which I am not confident we can do at the moment.

I think it is better to assume that we need journaling.

I will look into that.

I also have a system running on a cRIO-9014 - we have not seen the Error 6. Even though it is also FAT32 - have we been lucky or is the method for writing different on the non-linux RT? 

[BradM]

I can't speak for the USB subsystem on VxWorks, but I do know that Linux does buffer writes pretty extensively. This means that it is higher performing at the expense of being more prone to issues like this.

In reality, it is probably a combination of luck and difference in writes to USB devices that have been why you have not seen the same issue (yet) on VxWorks. FAT and unexpected power loss do not mix.