Re: [PATCH v6] fat: Batched discard support for fat

[Arnd Bergmann <arnd@arndb.de>]

On Wednesday 30 March 2011, Kyungmin Park wrote:
> >> If you just pass the minimum length, the file system could end up
> >> erasing a 4 MB section that spans two half erase blocks, or it
> >> could span a few clusters of the following erase block, both of
> >> which is not desirable from a performance point of view.
> >
> > Does those cards export such information correctly ?
> 
> Each chip vendor knows it exactly and usually can't tell it outside officially.

I have written a tool for measuring the erase block size reliably
and guessing the page size.

> but it's not big as you think.

The largest erase block I have measured is 12 MB (on a USB stick),
while the smallest typical erase block that gets used in SDHC cards
is 2 MB. I have seen one card using a 1.5 MB erase block.

Older SD cards (up to 2 GB) commonly have erase blocks as small as 
128 KB, but for all I know these do not get produced any more. The
smallest cards on the market today are 2 GB cards with 2 MB erase
blocks.

> also if the request size is under trim size, then it's discarded internally.
> I mean do nothing at firmware level.

I don't think that's possible with SD cards, since the command is "erase",
not "trim", i.e. the data gets inaccessible after the command returns.

On eMMC, the command is actually "trim", which can probably be discarded
as you say.

SD cards can also do pre-erase when writing. This has similar meaning
as trim, but is not currently supported by Linux, because it is not
as easy to use.

	Arnd