We're having an issue related to writing to flash -- occasionally a write will take dramatically longer than normal. This is causing an error in an external tool that is timing out waiting for a response to the write request.
The writes are small amounts of data (typically just a few bytes) written to certain offsets in a 2KB file in /var. And /var is an EFS partition occupying 16 erase blocks in our flash. Generally any single write will complete in a few milliseconds, but sometimes it will take as long as 1.5 to 2 seconds.
When using devf with the default arguments, every 16th write to the same offset will trigger a foreground reclaim. This is part of the design of the filesystem to shorten the supersede chain.
The second argument (optional) of the -p option changes the supersede chain length trigger. Increasing this value will reduce the frequency of foreground reclaim operations. The drawback of increasing this value is that filesystem updates to this file will also take longer.
Put another way, when you modify a file, another extent/chain is created, so the "list of extents" gets longer and longer. If you specify the driver not to reclaim until the number of extents reaches a high value, any access (write/read) to the file gets longer as it has to traverse the list.
NOTE: This entry has been validated against the SDP version listed above. Use caution when considering this advice for any other SDP version. For supported releases, please reach out to QNX Technical Support if you have any questions/concerns.
Please contact us with your questions or concerns.
BlackBerry uses cookies to help make our website better. Some of the cookies are necessary for the proper functioning of the website while others, non-essential cookies, are used to better understand how you interact with our website and to make it better.
