This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

USB mass_storage on mounted VFAT device: Filesystem not consistent

I see a weird phenomenon on my Beaglebone-like AM335x Linux machine:
I have a SDcard with 2 partitions, the first one (mmcblk0p1) is a 3GB VFAT (where my kernel and some data resides) and the second one (mmcblk0p2) is a 1GB ext4FS where my  rootFS resides.
The first partition (VFAT) is also used a USB mass-storage-device when I connect the AM335x to a USB Host. And this partition is also auto-mounted in fstab, so that I have access to the data on this partition from Linux. In fact I use this partition to exchange data between Linux and Windows.

In my /etc/fstab I have the following entry to automount the VFAT partititon:
/dev/mmcblk0p1    /media/X5data  vfat        defaults,umask=0000      0     0

At startup I have a script (/etc/init.d/S60USB) that installs the g_mass_storage USB driver to use the VFAT-partition:
modprobe g_mass_storage.ko file=/dev/mmcblk0p1

The AM335x properly connects to e.g. a Windows PC as a mass storage device.

Everything works fine until e.g. I overwrite files via USB (e.g. from a Windows PC) on the VFAT-partition.
Then I see this new data on the drive of my WindowsExplorer, but when I make a "ls -l" on that directory in Linux I DO NOT SEE THE NEW FILES there - I still see the old filesize. And also when I look at the data in that file I see the old data. Only when I restart the device (the AM335x) I see the new data on that partition in Linux (even when I turn off the power supply directly after doing the filetransfer via USB, without issuing "poweroff"!).

Its the same behaviour in the other direction: When I copy data in Linux to /media/X5data while USB is connected to the Windows PC I do not see the new data on that Windows-drive! Only when disconnecting and reconnecting USB I see the new data on that drive.
Issuing the "sync" command does not change this behaviour!


I am using the TI SDK 6.0 (PSP 04.06.00.11, Kernel 3.2, Linaro GCC 4.7) to build my kernel and I am using buildroot to make my FS.
All 6 patches regarding the MUSB for AMSDK 06.00.00.00 are applied.

uname -a gives:
"Linux X5 3.2.0 #296 Mon Aug 17 15:08:50 CEST 2015 armv7l GNU/Linux"

mount gives (for /dev/mmcblk0p1):
/dev/mmcblk0p1 on /media/X5data type vfat (rw,relatime,fmask=0000,dmask=0000,allow_utime=0022,codepage=cp437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
/dev/mmcblk0p1 on /home/ftp type vfat (rw,relatime,fmask=0000,dmask=0000,allow_utime=0022,codepage=cp437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)

cat musb_hdrc.0 gives (while USB connected to host):
Status: MHDRC, Mode=Peripheral (Power=f0, DevCtl=99)
OTG state: b_peripheral; active
Options: ?dma?, otg (peripheral+host), [eps=16]
Peripheral address: 00
Root port status: 00000100
CPPI: txcr=0 txsrc=0 txena=0; rxcr=0 rxsrc=280de80 rxena=0
Gadget driver: g_mass_storage

ep0 (hw0): 1buf, csr 0000 maxp 0000
    (queue empty)

ep1in (hw1): 1buf dma, csr 2400 maxp 0200
TX DMA0: 00000000 00000000, 00000000 00000000; 00000000 00000000 00000000 .. 00000000 (queue empty)

ep1out (hw1): 1buf dma, csr 2000 maxp 0200
RX DMA0: 2 left, 00000000 00000000, 00000000 00000000; 00000000 00000000 00000000 .. 00000000 req de2cced0, -552361752/-566795744


What am I doing wrong so that data on the USB-mass-storage-drive and the Linux filesystem (both at /dev/mmcblk0p1) is different as long I do not restart?

  • Hi,

    Then I see this new data on the drive of my WindowsExplorer, but when I make a "ls -l" on that directory in Linux I DO NOT SEE THE NEW FILES there - I still see the old filesize. And also when I look at the data in that file I see the old data. Only when I restart the device (the AM335x) I see the new data on that partition in Linux (even when I turn off the power supply directly after doing the filetransfer via USB, without issuing "poweroff"!).


    1) Without rebooting.... could you please try just to umount the pendrive (VFAT) partition alone and remount on Linux then check.

    2) Do "sync" then check "ls -al"



    In my /etc/fstab I have the following entry to automount the VFAT partititon:
    /dev/mmcblk0p1 /media/X5data vfat defaults,umask=0000 0 0

    mount gives (for /dev/mmcblk0p1):
    /dev/mmcblk0p1 on /media/X5data type vfat (rw,relatime,fmask=0000,dmask=0000,allow_utime=0022,codepage=cp437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
    /dev/mmcblk0p1 on /home/ftp type vfat (rw,relatime,fmask=0000,dmask=0000,allow_utime=0022,codepage=cp437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)


    3) Use the following options in fstab for USB mount.

    Ex:
    rw,noauto,sync

    /dev/mmcblk0p1 /media/X5data vfat rw,noauto,sync,umask=0000 0 0
  • Hi Titusrathinaraj Stalin

    Thanks for your suggestions!

    1.) Unmounting and mounting again seems to make this work. However, this solution is not convenient for what I want to do ...

    2.) "sync"ing does not change the behaviour

    3.) This should be the same as doing a "sync" at an "async"-mounted device I suppose. As "sync"ing does not change the behaviour I suppose also this suggestion will not change it. Anyway I will try this.

    I think the problem is a low-level one, as a USB mass_storage device seems to write at lowest level to the partition (that is the reason why the g_mass_storage module uses /dev/mmcblk0p1 as device and not /media/X5data as filesystem). And so the higher level filesystem might not see changes done by the g_mass_storage at the much lower level.

    Can someone confirm this?

  • Hi! I have similar problems. , have you fixed your problems?

    So, I have PSP 03.21.00.04 and g_mass_storage version 2009/09/11. Then I do the following:

    On target: insmod /opt/ipnc/modules/g_mass_storage.ko file=/dev/mmcblk0p6
    On target: mount /dev/mmcblk0p6 /mnt/emmc3 (filesystem on the /dev/mmcblk0p6 is FAT32 created as "mkfs.vfat -F 32 /dev/mmcblk0p6")
    On Windows-PC (connected with target with USB cable) I open this "USB-flash" and write txt-file to it
    On target I see this txt-file, contents is OK
    On Win-PC I change the file. On Win-PC I reopen it and see that contents has been changed
    On target I see the OLD contents of the file!

    I disconnect USB-cable and connect it again
    On Win-PC I see the OLD contents, on target I see the OLD contents!

    On Win-PC I change file again
    On Win-PC I programmatically disconnect "USB-flash" as usual
    On target I see the OLD contents of the file!

  • shp,

    Do not do that - see my last post (above yours)!

    The mass-storage driver seems to alter the data on the according partition at a low level, not using the OS filesystem functions. So the OS does not know that someone changed the data, and with this inconsistency you can easily damage the partition.

    From my point of view the only proper way is to unmount the according partition during mass-storage-use. Thats what I am doing at our device and it works well.

  • Hi Matthias Walzer! Thank you for your extremely quick reply!

    Have you succeed with the opposite direction? Just like you, I write file on the target, sync, unmount, and don't see new file on Windows-PC. Unpluggin/plugging the USB cable helps but not always.

  • Mass-storage-usage is completely independent from OS filesystem. In most cases they do not know anything from each other. So using them simultaneously will not work properly. The only way is NOT using them simultaneously, therefore unmounting the partition during mass-storage use.
    For simultaneous usage other filesystems and USB-interfaces are used ...
  • "For simultaneous usage other filesystems and USB-interfaces are used"

    Could you please say what filesystems and USB-interfaces??

  • Mass-Storage was for simple storage devices, like flash drives. It was not intended to be used like you and me do!

    I think you should look for MTP, PTP,...:
    www.linux.org/.../
    www.howtogeek.com/.../
  • Thank you very much for claryfying this!