NI Linux Real-Time Discussions
NTFS Partial Support
Solved!
So I know documentation-wise NTFS is not supported on the Linux-RT controller. But I had an NTFS USB drive so I plugged it in and started logging to it just fine so I figured it was supported since I didn't read the documentation first. But once the log file became greater than 4GB the file generated ended up not being valid. I happened to be logging to TDMS and I'm not sure how it became bad but it did.
So is there plans to support NTFS? Is there a way to disable NTFS if it doesn't fully work? For me the only real requirement is that I have a file system that is on this drive that Linux RT can log to, and Windows can recognize. It seems the only file system that meets that need is FAT32, and that means files can't be over 4GB. Oh and the 128GB drive limitation isn't a big deal yet, but the largest USB drive I have is 128GB, any larger and we'll have more issues.
cDAQ-9136 LabVIEW 2018 32-bit.
I didn't try to recreate your error, but I do have a potential solution.
From what I have found online, NTFS is partially supported in the Linux kernel. The ntfs-3g driver is a more full featured driver for NTFS on Linux or Mac. You can install it by typing
opkg install ntfs-3g
Then, Linux should automatically mount your NTFS drive with the new driver. You can check it by running
mount -l
or
cat /proc/mounts
It should now have a type of "fuseblk" instead of "ntfs". (Note: if you are not sure which device you are looking for, running "lsblk" can be helpful.)
I am using a 128GB SD card in a cRIO-9039 (which has NIRIO18.0 installed with 6.0.0f1 firmware). I have formatted the SD card as NTFS. I created a 6.5 GB text file for testing, without any problems. I then used the SD card on a Windows 7 machine and was able to read it without any corruption issues.
A few recommendations:
- I haven't worked with TDMS files a lot, but I highly advise keeping your log files less than 100MB (I typically use 20MB). Many programs can't open large files. Smaller files have a lower risk of loosing all of your data if you do get a corrupt file. In an embedded environment, smaller files also make it easy to write code to throw away the oldest data if your disk space gets full.
- I would avoid FAT32 as it is notorious for corruption issues. I recommend either putting NTFS drivers on Linux or EXT3/4 drivers on Windows. You might also try exFAT.
Best of luck.
Wow absolutely fantastic, I don't know how I can only give you one kudo. So yes after connecting to the internet and doing and opkg update and then installing the package you mentioned, my USB drive that is NTFS appears to work properly. Just for reference here is the VI I use to generate a 4.6GB TDMS file.
Can NI chime in on how likely this will work in the future? I'm not asking NI to say "This is fully supported." I'm just looking for someone at NI with technical knowledge to say "I can't think of a reason this will break." Or "I wouldn't trust this to work".
As for the other file system options. Formatting my drive to EXT2 and EXT3 required Ext2Fsd. I used the command line call to mke2fs.exe and it appeared in Windows and could be written to. I plugged it into my controller and the file was there and could be read. But trying to write to it resulted in Error 6 Generic file I/O error, in LabVIEW on the TDMS Open. This was for both EXT2 and EXT3. exFAT didn't work for me on my controller, the drive wasn't enumerated.
Also I'd like to mention one other positive side effect of your package installation suggestion. Recently I replied to a thread where users notice that drives that are taken out of the controller, and plugged into Windows, get a dialog from Windows saying the drive might be corrupt and needs to be scanned. Most of the time there is no issue but once in a while issues are found. This corruption dialog is seen even if all references are closed and cleaned up. Well I noticed that after your package install, my NTFS drives no longer say they are corrupt when plugged into Windows. If I format my drive back to FAT32, run the same VI (the one above but with only 2000 cycles) then unplug, and plug back into Windows that familiar corrupt dialog is there. I'm guessing there is a problem with the FAT32 file system, and without the installed packages you mentioned, NTFS was treated as FAT32.
Hi,
Are you able to quickly detail the steps involved in "doing and opkg update and then installing the package you mentioned".
I cannot access the internet directly from my cRIO because of company policy but I thought I could manually copy the files down and do it that way.
My problem is that having found what looks like the correct files I don't know which of them to use.
Thanks
So for me I have a cDAQ-9136 which is an x86 based Linux RT platform. I went to the package repository on a computer with the internet which is here:
http://download.ni.com/ni-linux-rt/feeds/
I then went into the newest which at the moment is 2018.5, and then x64 (since my controller is Intel based and not ARM), and then the core2-64 folder.
http://download.ni.com/ni-linux-rt/feeds/2018.5/x64/core2-64/
From here I searched for the 3 packages I found I needed. libntfs-3g, ntfs-3g, and libfuse2.
http://download.ni.com/ni-linux-rt/feeds/2018.5/x64/core2-64/ntfs-3g_2017.3.23-r0.15_core2-64.ipk
http://download.ni.com/ni-linux-rt/feeds/2018.5/x64/core2-64/libfuse2_2.9.4-r0.287_core2-64.ipk
Download those 3 packages and save them to a FAT32 USB drive and plug it into the controller.
Then SSH into the controller using Putty. You may need to enable SSH in MAX and reboot the controller. Once logged in go to the folder on the USB drive where the packages are installed using the change directory command (cd). The USB drive will be in the media folder on the root. Once there execute the following 3 commands:
opkg install libfuse2_2.9.4-r0.287_core2-64.ipk opkg install libntfs-3g88_2017.3.23-r0.15_core2-64.ipk opkg install ntfs-3g_2017.3.23-r0.15_core2-64.ipk
Obviously the file name needs to be replace with the actual name of your files if there are newer ones named differently. Now reboot your controller (optionally turn off SSH if you don't want it first) and now plugging in NTFS formatted drives should show up in the media folder just like the FAT32 ones.
EDIT: I see the answer by tic.not.tock has more packages listed. It is possible that my controller already had some of these but so far I've been successful with just the 3 I listed. It might be a good idea to use all the ones they listed.
Perhaps a simple question, but we're looking to access a networked NTFS folder from our cRIO. Does this mean we need the locally installed NTFS driver support mentioned in this thread?
Also, the networked location requires a Windows account + password to gain access. On our laptops we can map a network drive letter to the folder URI and provide Windows with the user account details - simple. On the cRIO we want to programmatically push files up to the same NTFS location, is this possible? If so, how do we go about it?
