[Galaxy Note GT-N7000 Android Development] abufrejoval:
Sorry if I'm slightly confused as to what you're trying to achieve exactly...

Trim (aka discard) is a basically a system call translating into a SATA command, telling the storage device that a block (or set of blocks) no longer contains any data the OS is interested in. This facility go introduced into Flash devices, because they can't simply overwrite 512 byte sectors like magnetic disks can when replacing old data. They need to free an entire erase block first, which can be dozens of logical sectors. If this is done stupidly at worst case the so called write amplification would be multiplying the I/O by two orders of magnitiude and quickly wear out the flash device.

But to do this smartly, the flash device should be told as early as possible which blocks are locially empty and that's what TRIM will do. While it should be done simpy by the file system itself, some early devices have rather unpredictable latencies when performing TRIM which is why it's still often performed as a separate pass, like in Android (on "normal" Linux it's often a mount option).

Linux support for TRIM was introduced with a 2.6.38 kernel or thereabouts, but still requires support from the file system: Ext4 typically has it *FAT doesn't.

But Android typically only adds batch like TRIM via an ioctl or whatnot system call on a mount point, which needs to be triggered.

KitKat has such a trigger built in, which takes a couple of pre-conditions to execute.

Running fstrim.zip in recovery doesn't *install* TRIM support onto an existing system but simply runs one such batch TRIM pass over all devices, simply failing on any with unsupported file systems. It's simply another way of doing a manual TRIM pass using the 'fstrim' command.

SDcards receive special treatment in Android and have a lot of historical ballast thrown upon them. The first generation typically came preformatted as FAT32 and users also expected easy data transfer to their PCs, which *real* Linux file systems can't deliver. At the same time there was the urgent need to use these SDcards as a way to expand the miniscule internal storage of early or cheap Androids, so the clever Google hackers devised ways of overlaying these FAT formatted SDcards with containers that were small ext4 (or ext3) file systems while appearing as files under FAT; typically one per application or sandbox (APP2SD is part of that).

That overlay stuff doesn't play well if the underlying file system isn't actually FAT, which is a real pity, because FAT is extremly wasteful with larger devices and doesn't support TRIM. So you wind up with lots of ext4 file systems (supports TRIM in theory) on top of a FAT file system that doesn't or no TRIM support for SDcards.

The worst part of course is that some of the devices with big eMMC local storage started to simulate external and theoretically removeable SDcards on internal storage (like the N7000), while they also supported external SDcards, but generally without the layering logic and APP2SD applicable to them.

In short: Don't try formatting internal or external SDcards with anything but FAT. You might get lucky with exFAT, if your kernel supports that (and your recovery, too). It will work perfectly in your recovery and some recoveries allow you to freely choose your partitions and file system type independently.

But if it then doesn't show up in Android, most likely that's because you didn't use FAT on your virtual or real SDcard.

That might change in Android Molasses or Nougat or if you have a gifted or determined set of hackers for your device.

Is there a maximum length to these posts? If so, I'm sorry I most likely went over :rolleyes: