A common complaint from owners of the first edition of the Nexus 7 is that it suffers from a noticeable slowdown over time. Whilst the tablet proved to be a speed demon straight out of the box, after months of use signs of lagging would appear.
Of course, this is hardly a new phenomenon, with the performance of hi-tech products often getting worse over time. Still, this does not mean that the slowdown is any less frustrating.
As noted by AnandTech and Nexus 7 owners on various forums, the release of Android 4.3 has noticeably improved the performance of Google’s original 7-inch tablet. This makes a welcome change, as new versions of operating systems – usually with more demanding hardware requirements – often slow down older devices even further.
Poor storage management has been a longtime criticism of the Nexus 7 and attempts to address this problem in Android 4.3 seem to be largely responsible for the performance improvements. The introduction of fstrim has enabled support for the TRIM command, which in turn has allowed for better management of storage space.
What is fstrim and how will a TRIM command speed up my Nexus 7?
Fstrim is a Linux utility that has been included in the latest Android release. It allows devices like the Nexus 7 to use TRIM, a command designed to make more efficient use of the space available on solid-state storage.
To understand how a TRIM command works and the speed benefits that it may bring, first we need to consider how data is read, stored and modified on solid-state storage, like eMMC (as used by the Nexus 7).
If you delete a file on your Nexus 7, the Android file system will recognise that it is no longer needed and that you now have some additional free space on your tablet. What the Android file system does not do, though, is communicate with the eMMC controller and tell it to delete the file that is physically stored on the device.
This can lead to the mapping between the Android file system and the actual files physically stored on the Nexus 7’s eMMC becoming increasingly complex. This in itself can cause slowdown.
Data is written to solid-state storage on pages, which are grouped together to form blocks. But when it comes to removal, it is not possible to delete information on pages – all data on an individual block must be deleted.
We know that when we delete a file, the physical data associated with that file is not erased. This means that solid-state storage eventually can become full of invalid data, which is not needed by the file system.
So we can find ourselves in a situation where as far as the Android file system is concerned we have plenty of spare capacity remaining, when in reality the solid-state storage on our Nexus 7 is brimming with invalid data. And unlike with hard disk drives, data on solid-state storage can not be overwritten – old data must be deleted before new information can be written.
Remember that it is not possible to delete data from individual pages. The minimum amount of data that can be deleted is a block, so the way that the eMMC controller has to deal with this problem isn’t particularly efficient.
The Android file system is able to let the eMMC controller know that there is invalid data that can be deleted. This data has to be processed first, so that the new file can be written to the solid-state storage.
When solid-state storage contains a lot of invalid data, a certain degree of maintenance needs to be performed before a new file can be added.
A good controller will select a block which has the largest amount of invalid data and its contents will be read to a buffer. The information that is not needed by the file system can be removed and data from a new file will be added to any spare pages.
The information in the buffer – which could include both data from a new file and data that is still needed by the Android file system – will then be written to pages of an empty block. Many blocks will likely need to be processed in this way, before all data from a new file has been written to the solid-state storage.
Both data from a new file and any old data that is still needed by the file system must therefore be written to the internal storage. This will vastly increase the amount of writing that takes place and slow down your device as a result.
How does a TRIM command work?
Although it has been possible to take advantage of the TRIM command before with rooted phones and tablets, since the Android 4.3 release Nexus devices have native support. When a file is deleted, the controller will now be notified, so that it can remove invalid data before it becomes a problem.
When modifying a file, a TRIM command can’t be sent. If, for example, you were to open an image in Uber Iris PRO, apply a filter, then re-save that image, TRIM cannot be used. Whilst it is not a flawless solution, TRIM is most definitely a step in the right direction.
From AnandTech’s investigations mentioned earlier in this piece, it would appear that a TRIM command is invoked under specific circumstances, once ever 24 hours. The maintenance should take place as long as your device hasn’t been used for an hour and has at least 80% battery capacity remaining off-charger, or at least 30% battery capacity if your device is charging.