5 Hidden Terminal Commands for Root Users to Speed Up Storage

Storage slowdowns feel like a slow phone. Apps take longer to open, photos take longer to save, and games stutter when a new level loads. The processor may be fine. The storage may be the bottleneck, and a slow storage chip makes even a flagship feel tired. A few terminal commands can reveal that bottleneck, and a few more can reduce it safely.

Root access opens storage tools that normal apps cannot touch. A root shell can run trim commands, clear caches that normal settings miss, check I/O statistics directly, and find the folders quietly eating your free space. Those tools help when used carefully, and they harm when used blindly. This guide gives five commands with context for each, so you know what each one does, when to run it, and when to leave it alone.

Think of storage as a warehouse. Files fill shelves over time, deleted files leave gaps, and the system must work around those gaps. Trim tells the storage which blocks are free, cache clearing removes stale stock, and a size scan shows which shelves are overflowing. Each command targets a different warehouse problem, and together they cover the most common reasons a rooted phone slows down. A tweak that frees up reserved RAM can ease the same stutter when apps compete for memory, so storage and memory work is best done together.

Safety first: backups and partition checks before any command

Back up before you run storage commands with root. A trim command is safe on modern storage, and a cache clear is safe for most apps, but a wrong partition name is not safe at all. Double-check every partition name before you press enter, because a single wrong letter can target the wrong partition. I keep a note on my computer with the exact partition names for my phone, and I read from that note rather than typing from memory.

Open your terminal app of choice, grant root with su, and confirm you are looking at the right device before you run anything. Check that your photos, messages, and important files are backed up somewhere off the phone. A backup takes ten minutes and turns a mistake into an annoyance instead of a disaster. Never run storage commands while the battery is under 20 percent, and never run them during a system update.

Work one command at a time and record a baseline first. Note your free space, note how long your heaviest app takes to launch, and note whether the phone stutters during a specific task. That baseline lets you judge each command honestly. A command that frees two gigabytes is a success, while a command that frees ten megabytes is noise. Without a baseline you cannot tell the difference, and you will keep running commands that never fix the real issue.

The 5 hidden terminal commands for faster storage

These five commands are the ones I return to on every rooted phone I own. They are ordered the way you should run them: measure first, then trim, then clear, then tune, then hunt for waste. Run them in order, check the result after each one, and stop when the phone feels fast again. You do not need all five every time.

Command 1: df -h shows free space on every partition

The first command is a status check, not a fix. Running df -h in a root shell shows total space and free space for each partition: data, cache, system, and vendor. A full data partition slows everything, a full cache partition slows app launches, and a full system partition blocks updates. The result tells you where to focus, and it stops you wasting time trimming a partition that is already healthy.

su
df -h /data /cache /system

Read the output column by column. The Use% column matters most: anything above 85 percent on /data deserves attention, and anything above 95 percent is urgent. Flash storage slows sharply when nearly full, because trim works less well and swap has no room to breathe. Note the free space on /data in your baseline note, because you will compare it again after the other commands.

Warning: df only reads information, so it cannot harm your phone, but do not trust it blindly when the numbers look strange. If df shows a partition as full while your settings app shows free space, the difference may come from reserved system space or a mounted folder. Investigate before you delete anything, and never delete files from /system based on a df reading alone.

Command 2: fstrim -v trims free blocks on flash storage

Trim informs flash storage about freed blocks. Flash storage writes in blocks, and deleted files leave blocks marked as used until trim runs. Trim marks them free, so future writes use clean blocks and write speed stays high over months of use. Modern Android runs trim automatically during idle charging, but a manual trim helps after a large deletion, such as removing many gigabytes of videos or uninstalling several large games.

su
fstrim -v /data
fstrim -v /cache

Let trim finish before you run another storage command. Trim takes time on a large partition, and interrupting it rarely causes damage, but it leaves some blocks untrimmed and a partial run simply helps less. After trim completes, test app launch speed by opening a heavy app three times and noting how the first launch feels after a reboot. A trim gain shows as smoother first launches, not as higher benchmark scores, so judge it by real app behaviour.

Warning: run trim only on /data and /cache, and never on a partition you do not recognise. Do not run trim on /system, because the system partition is mounted read-only and trimming it gains nothing. If fstrim reports an error about the filesystem not supporting trim, stop and leave it alone: your storage may already handle this automatically, or the partition may use a filesystem where trim does not apply.

What a good trim result looks like

A good trim run reports how many bytes it trimmed, and on a phone that has not been trimmed in weeks that number can reach several gigabytes. If it reports only a few megabytes, your storage was already in good shape and trim was not your problem. That is useful information too, because it tells you to move on to the next command instead of repeating trim and hoping for a different result.

Command 3: pm trim-caches clears stale caches safely

Caches speed up apps by storing repeated data, but stale caches slow apps by storing outdated data. A cache clear forces an app to rebuild fresh data: the first launch takes longer, and later launches feel faster. The pm trim-caches command asks the system to free cache space across all apps down to a target, which is far safer than deleting cache folders by hand, because the system knows which files are safe to drop.

su
pm trim-caches 1073741824

The number at the end is one gigabyte in bytes, and it tells the system to free caches until at least that much space is available. Start with one gigabyte and check the result before you ask for more. Clear caches for apps that misbehave or feel slow first, and judge the result after a day of normal use, not after the first launch, because the first launch after a clear always feels slower while caches rebuild.

Warning: do not clear every cache blindly and repeatedly. Game caches may hold downloaded maps or assets, and clearing them forces a large re-download over your data connection. Some apps store login tokens in cache-like folders, so check that you stay signed in after a clear. If an app misbehaves after clearing, reinstall it from your backup rather than clearing again.

Command 4: cat scheduler and read_ahead_kb checks I/O tuning

The I/O scheduler orders read and write requests, and different schedulers suit different storage types. Flash storage benefits from a scheduler that does not waste time on seek assumptions made for spinning disks. Reading the current scheduler and the read-ahead size tells you whether your phone already uses sensible values, and it gives you a baseline to return to if you ever change them.

su
cat /sys/block/sda/queue/scheduler
cat /sys/block/sda/queue/read_ahead_kb

Your block device may be named sda, sdb, or something else, so list /sys/block first and use the name that matches your storage. The scheduler line shows the active scheduler in brackets, such as [mq-deadline] or [bfq], and the read-ahead value is usually 128 or 512 kilobytes. Note both values before you change anything. A default that already suits flash storage needs no change, and changing a good default for novelty wastes time and adds risk.

Warning: read these values, but do not change the scheduler or disable journaling on a daily driver. A strict journal protects against corruption after a crash, and the speed gain from relaxing it is small while the corruption risk is large. Changing the I/O scheduler without recording the default value is the most common way a small experiment turns into a permanent slowdown, because you can no longer tell what changed. If you do experiment, change one value at a time, use the phone for a full day, and revert at once if it feels worse.

When to stop tuning and leave the defaults alone

Stop tuning when two changes in a row show no clear gain. The stock scheduler on modern phones is usually well chosen, and the remaining speed lives in free space and clean caches, not in scheduler tweaks. A short list of settings you understand beats a long list of guesses you cannot explain, and it is far easier to maintain after the next system update.

Command 5: du finds the folders eating your storage

A size scan finds large folders quickly, and it often reveals a surprise. A messaging app may hold gigabytes of media, a game may hold old update packs, and a download folder may hold forgotten installers. Deleting the right folder frees more space than any trim command, and it fixes the root cause instead of the symptom. Game memory tuning also interacts with storage speed, and the guide on tuning mobile game memory limits explains how a game that swaps heavily needs fast storage with free room to work in.

su
du -h -d 1 /data/media/0 2>/dev/null | sort -rh | head -20

Scan the data partition first, then app media folders, then the download folder. Those three scans cover most waste. The output lists folders from largest to smallest, so the top five lines are your suspects. Open each large folder and check what it contains before you delete anything: a large folder may hold photos you want to keep, and moving those photos to a safe place first takes a minute and saves regret.

Warning: never delete a folder based on size alone. System folders with large sizes often hold data your apps need, and deleting them can break logins, lose offline maps, or force huge re-downloads. Delete only folders you recognise and understand, move keepers first, and keep at least fifteen percent of the data partition free when possible so trim and swap keep working.

How to read the numbers after each command

After each command, repeat the df -h check from command one and compare it with your baseline. A trim that freed two gigabytes shows up at once, and a cache clear shows up as more free space plus slightly slower first launches. Write the new numbers in your note with the date, because a phone that slowly fills up over months is easier to fix when you can see the trend instead of guessing.

Watch I/O wait as well as free space. High I/O wait means the processor waits for storage often, and that wait shows up as stutter even when free space looks fine. Open a heavy app and notice whether the first launch lags or the interface freezes for a second. If the phone feels smoother after a command, that feeling is worth more than any benchmark number, and if nothing changed after a day, the command was not your fix.

Keep a simple log of what you ran and what changed. One line per command, with the date and the free-space reading before and after, is enough. That log turns future troubleshooting into a five-minute job: you will know which commands helped last time, which ones did nothing, and which values were normal for your phone.

Weekly storage routine for root users

Run a weekly storage check on the same day each week. Check free space on data and cache partitions, check the largest folders, and check I/O wait during a heavy app launch. A weekly routine catches slow growth early, and early catches need small cleanups while late catches need large deletions. Put a reminder on your calendar so the routine survives busy weeks.

Sunday check: space, folders, and downloads

Start with df -h, then run the du scan on your download folder and your messaging media folders. Clean downloads weekly, because downloads accumulate installers, documents, and media that you needed once and forgot. Review the folder each week, move keepers to organised folders, and delete the rest. A clean downloads folder speeds file searches and frees space for swap and caches at the same time.

Monthly review: messaging media and app data

Review messaging media monthly, because messaging apps store photos and videos automatically and those files grow silently. Delete duplicates and old media you no longer need, and keep favourites in a separate album. Check app data sizes quarterly: an app that grows steadily may cache excessively, and a quarterly check reveals that growth before it becomes a crisis. Clear that app cache, or reinstall the app if needed, and back up important app data before reinstalling.

Battery tuning can reduce background writes over time, because fewer background writes mean less storage churn. The guide on Magisk modules for battery standby time covers idle tuning that pairs well with storage hygiene. Combine the two thoughtfully rather than stacking every module you find, and keep at least fifteen percent free space as a soft minimum so trim, swap, and caches all keep working.

Common mistakes that slow storage down

The biggest mistake is running a trim or clear command on a partition name that was guessed rather than verified. A guessed name can point at the wrong partition, and the result ranges from nothing happening to data loss. Always list partitions first, read the exact name, and copy it rather than typing it from memory.

The second mistake is clearing every app cache at once and then losing game assets that need re-downloading. A cache clear is a targeted tool, not a weekly ritual, and clearing everything at once hides which app actually needed it. Clear one app at a time, test it, and move on only when you see a benefit.

The third mistake is disabling journaling for a tiny speed gain while risking corruption after a crash. The gain is small, the risk is large, and a corrupted filesystem costs far more time than the tweak ever saved. The fourth mistake is changing the I/O scheduler without recording the default value for reverting, which leaves you unable to undo the change. The fifth is deleting a large folder by size alone without checking for photos inside it. Back up before running storage commands with root and most of these mistakes become recoverable instead of permanent.

Frequently asked questions about root storage commands

Is manual trim safe on modern phones?

Yes, trim on data and cache partitions is safe on modern flash storage. It only marks freed blocks, it does not delete live files, and it runs automatically during idle charging anyway. Run it manually after large deletions for the best effect, and skip it on partitions you do not recognise.

Will clearing caches make my phone faster immediately?

First launches after a clear may feel slower while caches rebuild, and later launches should feel smoother. Judge a cache clear after a day of normal use, not after the first launch. If the phone still feels slow after a day, the cache was not the problem, and the du scan in command five is the better next step.

Can terminal commands fix a failing storage chip?

No, commands cannot fix hardware failure. Frequent errors, disappearing files, and apps that crash when saving point to hardware damage, not to a tuning problem. Back up immediately in that case, copy your photos and files off the phone first, and replace the device or the storage if possible. No trim or cache command will revive a dying chip.

How often should I run these five commands?

Run the df check weekly, the du scan monthly, trim after large deletions, and the cache clear only when a specific app misbehaves. The scheduler check is a one-time read unless you change something. A phone that needs these commands daily has a deeper problem, such as an app that writes constantly or storage that is nearly full, and that problem deserves investigation rather than repetition.

Storage speed improves with measurement and modest commands, not with aggressive ones. Check status first, trim after large deletions, clear stale caches one app at a time, read scheduler defaults before changing them, and find large folders before deleting anything. Your next step is simple: run the df -h check today, note the free space on the data partition, and let that baseline decide whether trim or cleanup will help you most.