Going by the blog, the compaction thread is low priority so it should not interfere with the system. You are also reporting this on CE5 which is RAM backed so I do not think this a compaction issue. If you really think this is filesystem related, we may have tool to help you but it focused to internal NAND flash. Before we go that route, we would like some emscript logs and details on how to repro.

The storage card should not be affected by an OS compaction thread as described in the blog.  Storage cards have their own hardware controllers that handle all of the wear leveling and compaction and just look like a normal disk drive to the OS.  There is no way on the device side to trigger the SD card to do its wear leveling/block management. The article applies mainly to flash drivers using Microsoft's flash driver architecture.  "Application" and "Platform" folders may be subject to this.

I suspect, the CPU is simply flushing out the data to the SD card due to the numerous file operations. Do we have an idea on how many file operations are being done and the size associated with it? Also if there is app running off the SD card, this too would cause file operations to occur each time a new page of the running module is loaded. Free space and speed of the SD card can also be a factor.

Take a look at the paper that describes persistent storage in this compass site: http://compass.mot.com/go/ecrtwhitepapers Although, it's main focus is WM5, many of the concepts apply to CE as well.

Thanks George. I have read the document, but haven't found any explanation for the compaction thread issue customer is describing. Today they went back to me asking following: Can you confirm thatit's compaction that makes filesys.exe behave that way, or could it besomething else?   Is it possible to consult Microsoft, maybe theyknow a way? Thanks for your help, Petr

The purpose of providing the paper was not to address the compaction.  It was to address writing small blocks of data.  The paper describes the drawbacks of writing data in small blocks in CE5 and WM5.  The account team may wish to engage the ECSG team to help further here.

Normally, this is done when the terminal is idle.  (see the blog).  The only reason that this would happen is if a critical compaction is required.  That in and of itself is triggered by the application writing big blocks. If you're talking about normal compaction.  Then no, there is no way to trigger it. Are you sure that the slow downs being experienced are caused by this?

Thanks George. I have sent your feedback to GLS, they came back with following: "It's happening usually during processes, where there's not a lot of idle time (continuous scanning at conveyor belt eg.).  We're only writing small amounts of data to the storage card, but file is opened/appended to/closed for each scan. Here's two examples how the cpu graph looks when the stalling occurs when filesys.exe (red line) kicks in.. The device is anything but idle when it happens, to the contrary... I wonder what could be done about it?" I have attached two screenshots from the customer. Thanks for your help, Petr