Periodic filesystem consistency checks are probably a good idea. Do current Android devices ever do them?

Let me start out by giving you some general background information. My actual question is at the very bottom of this post. ---------- # Background, part 1: Journal replays vs. consistency checks. Please assume that your Android device uses the ext4 filesystem for its internal storage, and the FAT32 filesystem for its removable MicroSD storage (if present). On ext4, a "journal replay" is a partial filesystem check-and-repair operation which normally takes no more than few seconds. ([Source](https://unix.stackexchange.com/questions/353671/what-does-e2fsck-do-during-bootup).) The Android kernel does a journal replay whenever necessary. (Based on [this source](http://confluence.wartungsfenster.de/display/Adminspace/Mount+ext4+without+journal+replay) and [this source](https://bugs.launchpad.net/ubuntu/+source/partman-basicfilesystems/+bug/41624/comments/6).) On ext4, a full filesystem consistency check takes longer. For an average Android device, it takes 12 seconds or so. (Based on [this source](https://github.com/android/platform_system_core/commit/07068de7894d3b8c4faf6c6c0844e1ec9684c5b1).) FAT32 is a non-journaling filesystem. So there are no journal replays. There are only consistency checks. ---------- # Background, part 2: It's probably a good idea for your OS to do periodic consistency checks. Here's why. Microsoft program manager Kiran Bangalore [writes](https://docs.microsoft.com/en-us/archive/blogs/b8/redesigning-chkdsk-and-the-new-ntfs-health-model) that there are certain cases in which a filesystem can become corrupted. On a journaling filesystem such as ext4, such cases are exceedingly rare. On removable MicroSD cards, I suspect that such cases are not so rare. The usual way to check for such corruption is to configure your OS to run a consistency-check tool every so often. Such tools include chkdsk, ScanDisk, Apple Disk Utility, fsck, and others. Even on ext4 storage built into an Android device, periodic consistency checks are probably a good idea. The tune2fs manual page explains why: > Bad disk drives, cables, memory, and kernel bugs could all corrupt a filesystem without marking the filesystem dirty or in error. If you are using journaling on your filesystem, your filesystem will never be marked dirty, so it will not normally be checked. A filesystem error detected by the kernel [may] still force a [consistency check] on the next reboot, but it may already be too late to prevent data loss at that point. (Note that, on Android, I think a filesystem error detected by the kernel will _not_ lead to a consistency check on the next reboot. Android is strange that way.) ---------- # Background, part 3: Here's what other OSes do. ### Windows Windows Vista, and all later versions of Windows, include an [NTFS self-healing](https://technet.microsoft.com/en-us/library/cc771388(v=ws.10).aspx) feature. Kiran Bangalore therefore [writes](https://docs.microsoft.com/en-us/archive/blogs/b8/redesigning-chkdsk-and-the-new-ntfs-health-model) that, nowadays, Windows users no longer need to run periodic consistency checks anymore. He explains that the OS "will inform you when ... corruption is found". ### Windows 10 Mobile Windows 10 Mobile is probably the [third-most-popular smartphone OS](http://www.idc.com/prodserv/smartphone-os-market-share.jsp) . I think it uses NTFS. So perhaps it also can do NTFS self-healing. ### OS X Mac OS X runs fsck_hfs -p during [every boot](https://apple.stackexchange.com/questions/88604/how-to-auto-run-disk-repair-on-os-x-after-each-system-crash#88676) . I don't know what this does. See the [manual page](https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man8/fsck_hfs.8.html) . ### Linux It's true that [some](http://markmail.org/message/7rgbdczwvhxbsipa#query:+page:1+mid:tbkmrhpcgetlwmy4+state:results) ext4 developers say that periodic ext4 consistency checks aren't particularly useful. But [other](http://markmail.org/message/7rgbdczwvhxbsipa#query:+page:1+mid:ew5osoby3kaacf6f+state:results) ext4 developers say that these checks improve safety and reliability. In practice, when a filesystem is marked in error, Linux runs a consistency check at the next reboot. At other times, modern Linux distributions don't do automatic periodic consistency checks, ever. Those who want them must schedule these checks themselves. ### Android Stock Android includes an [ext4 consistency-check tool](https://android.googlesource.com/platform/external/e2fsprogs/+/master) . As well, it includes a consistency-check [tool](https://android.googlesource.com/platform/external/fsck_msdos/+/master) which works on removable MicroSD cards of 32 GB or less (but may corrupt larger cards). Finally, your device may or may not also include fsck.exfat or exfatfsck, for running consistency checks on removable MicroSD cards of 64 GB or more. But does the OS ever run any of these tools automatically? ### iOS The iOS filesystem is normally either HFSX or APFS, and fsck is [included](https://www.theiphonewiki.com/wiki//sbin) with the OS. I don't know whether or not iOS ever runs automatic consistency checks. ---------- # Here's my question. Please consider the stock ROMs shipped with current Android devices. Do such stock ROMs ever periodically run consistency checks, either on the internal storage device or (if applicable) on the removable MicroSD card? (P.S. In cases where a device shuts down gracefully and has enough battery charge left, it's [possible](https://serverfault.com/questions/483093/fsck-on-shutdown-instead-of-startup) to run a consistency check at shutdown instead of at startup. But it takes some engineering effort to implement such functionality, and so operating system developers normally don't bother. I wonder what Android does.) (P.P.S. I also wonder whether or not there exist _any_ smartphones, running _any_ OS, which do _any_ routine periodic consistency checking. Again, please post comments below.)