As I wrote in my comment on the question, I rather think it's a defect in the controller – which is nothing you can fix yourself. Still, you might wish to at least check things. So I'll try to explain:
Preparation
To do all that manually, some pre-conditions must be met. You will need:
- a terminal app. Terminal Emulator for Android would be a good choice: open-source, and available on Google Play as well as on F-Droid and on Aptoide.
- alternatively: ADB to access the command-line of your Android device directly from your computer via USB. Much more comfortable, as you have a real keyboard and a big screen. If you want to go this way, see Is there a minimal installation of ADB?
- optionally: root-access will definitely prove helpful, as this would also allow you to repair things.
Step 1: Find your "drives"
In a first "operative step", you need to evaluate what partitions there are, and which file-system each of them uses. Open your terminal (or run adb shell
) to get to the command-line, and invoke the mount
command. For what to expect, let me steal a screenshot from this post:
Example output of the mount
command (click image for larger variant)
Now, not all entries are relevant to you. Check Android Folder Hierarchy to pick those you're interested in. For your case, the one holding /data/data
will be of special interest. The example screenshot has it in the line with /dev/block/platform/dw_mmc.0/by-name/userdata
, and we see it is using Android Folder Hierarchy as file system – more specifically: EXT4.
You might also wish to check other partitions, but make sure to stick to those with "real file systems" – and skip things like rootfs, tmpfs, sysfs, cgroup, etc. Basically, all those partitions you're interested in will most likely use either some extfs, or (for the SDCard) some FAT.
Step 2: Check the "drives"
Now that we know what we have, we can pick the matching tool. Our example uses ExtFS, so we need some fsck
for that. As you assumed, from your collection e2fsck
would seem the closest match here (though, if there's something specific to ext4, I'd check that first in the given example). Most parts of the different ExtFS versions are somehow backward-compatible – at least when it comes to "basic checks": EXT3 is, in easy terms, just EXT2 with a journal added – drop that journal, and you're back to EXT2.
Now how to run the check? Again, we already have answers for that – see e.g. How to check filesystem (/sdcard) for errors?, which gives us (for a read-only check run doing no repairs)
e2fsck -n /dev/block/platform/dw_mmc.0/by-name/userdata
If that finds errors, and you have root access to your device, you can replace -n
("no, don't do anything") by -y
("yes, please repair all issues you find if you can"). This might report (and optionally fix) some "bad blocks" which may have caused your issues – though the OS should attempt that itself on startup (boot). With root-access, however, it might interactively prompt you for things it didn't dare to repair automatically, so you might have a chance to improve your situation.
chkdsk
– but it's namedfsck
, "fs" standing for "file system"). In user-mode you should be able to test integrity; in order to repair anything you probably need root powers. // I agree that sounds like file system errors or bad blocks; but with the external SD card affected as well, it might rather be a defective controler. If you still have warranty, I'd hurry up giving the device to service while you can.