Hi all, I'm using FatFs ChaN R011a and STM32F4 HOST library 2.2.0 relasead on 2015 to develop a mass storage class usb data logger. I noticed a strange behaviour flushing the logging data on some usb key devices. I normally save the logging data on a buffer of 4096B, then when it becomes full, I call first "f_write" and aftewards "f_sync" function, but in some cases this last one takes too much time to finish (pin toggling to measure the time). The "f_sync" delay is not regular and it takes up to 800 ms for some usb key. I didn't find any file system errors and these functions return always FR_OK.
my settings clock: STM32F4 core clock = 42MHz, USB clock = 48MHz (PLL).
According to you, could it only depend by the kind of usb key interfaced or by other? In the file "usbh_msc_fatfs.c", the case CTRL_SYNC of disk_ioctl is not implemented, is it correct? Why?
Thank you, Fabio
I would think the actual USB thumb drive could be guilty of slow syncs.
If the thumb drive needs to erase flash blocks before it can write down the new data you try to flush, then that flush will be much slower than if the USB thumb drive already have empty flash blocks so it can directly write down the data.
I would think lots of USB thumb drives will lack over-provisioning so they then don't have any spare flash blocks that can be kept erased beforehand and instantly allocated when you issue new writes.
Hi Per, thanks for your fast answer.
According to you, is it possible to do something to avoid such a behaviour? I don't know, a specific format method for example? I tried to format them in Windows OS before, but I didn't see any improvement.
Fabio
I don't think USB thumb drives supports any TRIM command - that would need support in the thumb drive, and such a command in the Mass Storage Device protocol used to interface with the thumb drive.
The TRIM command is what can be used on an SSD so the OS can tell "this file has been removed on the file system level, and so all flash blocks used to store the file are now unused - feel free to erase them so they are instantly ready for later writes".
Only TRIM or flash devices with over-provisioning will allow a drive to pre-erase flash blocks so it can have a pool of empty blocks for later writes. Which over-provisioning, the controller has a number of extra flash blocks besides the number of blocks needed to give the rated capacity. These blocks are initially erased. When writing data, the controller writes to an empty block - then it replaces the old block with this just written block. The old block can then be erased in the background and then added to the spare pool. So the memory controller manages both wear-leveling and instant access to erased blocks.
This is also why people in a number of situations makes full low-level formats of their devices after having cleared out all files - a low-level format would allow the memory controller to erase all flash blocks. But this only speeds up writes until all the erased blocks has been written once - then it's back to normal mode where new writes regularly results in flash blocks having to be erased on-the-fly and so slowing down the write speed greatly.