The cutoff for sdhc is 128gb, not 32gb.
You probably know more than I do, but the SD Association itself says that SDHC supports only a max of 32 GB. That's what the standard says. Is there a source for your claim? I guess you could allow non-standard implementations, but the problem with allowing non-standard behavior is that you can't rely on them to work all the time on every device.
Wait does that mean that the stuff saying the phone can't have an Micro SD card bigger than 32gig in it is a lie and I can put the biggest one in there and it work?
I'll just answer the general case of "my phone's advertised as supporting a max of $SOME_SIZE cards, but the standard says I can put in $MAX_SUPPORTED_SIZE_FOR_STANDARD ones!". I'll hold the specific assertion here as wrong until proven otherwise, but the general idea is answerable.
Educated guess ahead: It's a matter of marketing. If you look at SDUC, it supports up to 128 TB, but (as of this writing) no-one's made them yet. Do you want to be the company saying things like "our phone supports 128 TB SD cards!"? It's technically correct, but any outsider hearing that would start asking "is $PHONE_COMPANY smoking crack again?"
...that, or "ooh, where can I find these 128 TB SD cards?", proceeds to buy a fake one off Wish, then blames $PHONE_COMPANY for the fake card once it loses the precious memories of their family or something.
This is more an issue with FAT32 (or rather, Microsoft's hard cap of 32gb for FAT32), than the signalling technology. Android runs on linux, and does not give a shit about the huge-fat implementations. It will happily format that card as fat32 with a huge-fat implementation.
See for instance, the exchange here.I have used huge cards in phones from that era without any problems at all. 128gb card will likely live in there just fine, but I would be leery of putting bigger.
If the device supports adopted storage, it wont use FAT filesystem at all anyway, it will use an encrypted form of EXT4, which will work all the way out to the signalling limit of the SDHC spec, which is 128gb.
Anything larger than 128gb must be supported by an SDXC controller, because it uses a different addressing technology.
The reason the SDCard association caps SDHC at 32gb, is because larger modules tend to have large erase-block sizes, and the cards wear out extra super fast if the wrong allocation unit size is used. ExFAT allows cluster sizes that are astronomically large, which is what is really needed for large capacity SDcards. (Which is why the SDCard Assn switches gears abruptly and harshly at the 32gb boundary, and says "With ExFAT" for anything larger.) It has nothing to do with the signalling tech underneath, it has to do with the typical memory granularity of the flash array being accessed, and how long the device is likely to service under heavy read-erase-modify cycles.
Microsoft limits the allocation unit size to 16kb, which translates to a maximum volume size of 32GB. FAT32 actually allows you (within actual FAT32 specification) to specify a 32k cluster size, which can handle a volume up to 2TB. This is what I mean by "Huge-Fat". Linux FAT implementation does not bat an eye at 32k cluster for FAT.
The issue, is that super-duper large SDCards, use physical eras block sizes upwards of 1MB on really large capacity modules (sometimes larger than 4mb!!), and this leads to write amplification. The SDCard Assn wants you to use ExFAT, so that you can set an extra super huge cluster size, that FAT32 does not support.
That is the real, nitty gritty, down and dirty on the subject.
Zultan's intended use case: "load it up with as many video files as possible" should not have serious issues with write amplification, since the files wont change after being written. A 128gb card should work fine.
Author
Topic: The Generic Computer Advice Thread (Read 493739 times)