On Thursday 05 July 2012, Victor wrote:

...

...

Are you referring to the "essential" microSDHC 32GB (MB-MSBGA) that you mentioned in some previous post in the mailing list?

Yes, that's the one.

...

What should be the the erase block size then? 1.5 MiB or some multiple?

I think it's 8 GB, but it's trying very hard to hide this.

I've lost its original partitioning and formatting and I'd be interested in having a raw copy of the first 17 MiB using dd or at least to know the details about the partitioning and formatting (it can be from the MB-MSBGA).

Actually I'd like to partition it with a FAT32 and an ext4. Should I care about the C/H/S for partitioning or can I just ignore it?

Sorry for the late reply. In case you haven't figured out a partitioning scheme yet, here is some information:

I have found in the meantime some information that hints that this card does have a 12 MB erase block size, but it doesn't really matter.

If you want to format a card properly, the easiest way is to overwrite the partition table and then stick the card in a digital camera, which will recreate the 4MB aligned partition and a FAT file system starting at the right offset (start of data is at the next 4MB boundary following the FAT).

For this particular card, none of this should actually matter, I would just make sure you have align the partitions to 1MB (as fdisk does by default now) and use 32 kb (64 sector) clusters in FAT32. The C/H/S values can be ignored completely.

I plan to set the FAT32 partition with a cluster size of 32 KiB. If I understand well the partition should start at the 8 MiB offset and not the 4 MiB one, shoudn't it?

The SD standard mandates 4MB, but for this card there is no reason to do this.

And of course I'd set the right amount of reserved sectors so the data would start at the 16 MiB offset to keep it align with the erase block size of 8 MiB, right?

Again, the standard wants it to be on a 4MB boundary, but the card doesn't care.

I've also tried to see if there is any FAT area but it doesn't look to be the case here:

$ sudo ./flashbench /dev/mmcblk0 --findfat --erasesize=$[2*1024*1024] --blocksize=$[16*1024] --fat-nr=10 2MiB 8.43M/s 8.92M/s 9.13M/s 8.81M/s 8.87M/s 9.01M/s 8.75M/s 8.97M/s 8.94M/s 8.62M/s 1MiB 8.68M/s 8.97M/s 8.63M/s 9.03M/s 9.01M/s 8.86M/s 8.81M/s 8.88M/s 8.91M/s 8.72M/s 512KiB 8.76M/s 8.93M/s 9.01M/s 8.71M/s 9M/s 8.59M/s 8.93M/s 8.92M/s 8.82M/s 8.58M/s 256KiB 8.8M/s 8.93M/s 9.03M/s 8.72M/s 8.84M/s 9.03M/s 8.63M/s 8.91M/s 8.92M/s 9.01M/s 128KiB 8.67M/s 8.87M/s 8.83M/s 8.77M/s 8.92M/s 8.9M/s 8.75M/s 8.93M/s 9.01M/s 9.03M/s 64KiB 8.68M/s 8.82M/s 8.88M/s 8.71M/s 8.94M/s 8.85M/s 8.74M/s 8.92M/s 8.72M/s 8.76M/s 32KiB 7.11M/s 7.13M/s 7.23M/s 7.22M/s 7.24M/s 7.46M/s 7.11M/s 7.33M/s 7.37M/s 7.42M/s 16KiB 4.58M/s 4.81M/s 4.75M/s 4.76M/s 4.77M/s 4.77M/s 4.7M/s 4.7M/s 4.8M/s 2.1M/s

Correct.

About the ext4, do you have any recommendation? I plan to make it start at an offset multiple of the erase block size.

I've found some recommendations here: http://blogofterje.wordpress.com/2012/01/14/optimizing-fs-on-sd-card/

Thus I'm planning to format it that way: mkfs.ext4 -O ^has_journal -E stride=4,stripe-width=512 -b 4096

For any other card, I would

### # TS32GUSDHC10 made in China #

Beside that I'd like to share the results from another TS32GUSDHC10 that I have for now with a SanDisk controller. It looks comparable to the results for the SDSDU-032G-A11. I've run the tests from the Lenovo laptop.

Ah, very interesting

$ cat /sys/block/mmcblk0/device/block/mmcblk0/size 62333952

This is a multiple of 1.5MB but no higher power-of-two value than 512KB. Presumably the erase block size is 1.5MB

$ sudo ./flashbench -a /dev/mmcblk0 -b 1024 align 8589934592 pre 841µs on 881µs post 690µs diff 115µs align 4294967296 pre 885µs on 958µs post 693µs diff 169µs align 2147483648 pre 888µs on 950µs post 690µs diff 161µs align 1073741824 pre 789µs on 957µs post 690µs diff 218µs align 536870912 pre 844µs on 947µs post 693µs diff 179µs align 268435456 pre 845µs on 952µs post 692µs diff 183µs align 134217728 pre 809µs on 920µs post 688µs diff 172µs align 67108864 pre 832µs on 945µs post 690µs diff 184µs align 33554432 pre 893µs on 947µs post 689µs diff 156µs align 16777216 pre 820µs on 934µs post 681µs diff 184µs align 8388608 pre 767µs on 890µs post 663µs diff 176µs align 4194304 pre 718µs on 805µs post 652µs diff 120µs ## Erase block size?

That would also be possible from this data

align 2097152 pre 659µs on 663µs post 663µs diff 2.26µs align 1048576 pre 658µs on 662µs post 664µs diff 809ns align 524288 pre 704µs on 806µs post 663µs diff 122µs align 262144 pre 660µs on 662µs post 660µs diff 2.11µs align 131072 pre 664µs on 660µs post 660µs diff -1346ns align 65536 pre 658µs on 664µs post 664µs diff 3.11µs align 32768 pre 664µs on 669µs post 661µs diff 6.67µs align 16384 pre 660µs on 662µs post 664µs diff 528ns align 8192 pre 665µs on 668µs post 664µs diff 3.6µs align 4096 pre 658µs on 660µs post 656µs diff 3.05µs align 2048 pre 662µs on 663µs post 663µs diff 35ns

## It looks like the erase block size is 4 MiB, which can be confirmed by the ## fact the FAT32 partition starts at the 4 MiB offset.

The start of the partition is irrelevant here, because it's mandated by the standard to be at 4MB

# # FAT area #

$ sudo ./flashbench /dev/mmcblk0 --findfat --erasesize=$[2*1024*1024] --blocksize=$[16*1024] --fat-nr=7 2MiB 13.6M/s 13.7M/s 5.92M/s 6.03M/s 5.45M/s 7.73M/s 13.7M/s 1MiB 5.83M/s 13.8M/s 5.41M/s 6.9M/s 6.27M/s 6.91M/s 13.7M/s 512KiB 12.3M/s 13.7M/s 6.82M/s 6.22M/s 5.99M/s 6.69M/s 13.7M/s 256KiB 11.5M/s 13.7M/s 5.21M/s 5.9M/s 5.7M/s 7.9M/s 13.7M/s 128KiB 13.1M/s 13.8M/s 5.88M/s 7.65M/s 5.88M/s 6.16M/s 13.6M/s 64KiB 13.5M/s 13.7M/s 7.35M/s 6M/s 7.2M/s 5.34M/s 13M/s 32KiB 11.9M/s 12M/s 6.3M/s 5.48M/s 5.73M/s 5.15M/s 12M/s 16KiB 9.68M/s 9.81M/s 4.71M/s 4.84M/s 4.7M/s 5.06M/s 9.75M/s

## FAT should be between 4 MiB and 12 MiB. ## That matches the details I can read from an hexdump -C against the disk ## about the FAT size and the number of reserved sectors to have the data ## starts at the 12 MiB offset.

Right.

# # Write benchmark #

## It looks like the card can handle up to 11 concurrent 4 MiB blocks...

$ sudo time ./flashbench --open-au --erasesize=$[4*1024*1024] --blocksize=$[16*1024] --open-au-nr=1 --offset=$[40*1024*1024] /dev/mmcblk0 4MiB 13.7M/s 2MiB 13.2M/s 1MiB 12M/s 512KiB 12.7M/s 256KiB 12.7M/s 128KiB 13.4M/s 64KiB 13.5M/s 32KiB 11.9M/s 16KiB 9.68M/s

real 0m3.568s user 0m0.212s sys 0m0.328s

$ sudo time ./flashbench --open-au --erasesize=$[4*1024*1024] --blocksize=$[16*1024] --open-au-nr=11 --offset=$[40*1024*1024] /dev/mmcblk0 4MiB 13.2M/s 2MiB 13.6M/s 1MiB 13.5M/s 512KiB 13.4M/s 256KiB 13.2M/s 128KiB 12.8M/s 64KiB 12.2M/s 32KiB 10M/s 16KiB 7.42M/s

real 0m35.892s user 0m0.164s sys 0m0.488s

$ sudo time ./flashbench --open-au --erasesize=$[4*1024*1024] --blocksize=$[16*1024] --open-au-nr=12 --offset=$[40*1024*1024] /dev/mmcblk0 4MiB 9M/s 2MiB 10.5M/s 1MiB 8.45M/s 512KiB 8.46M/s 256KiB 8.25M/s 128KiB 8.11M/s 64KiB 9.39M/s 32KiB 8.06M/s 16KiB 6.52M/s

real 0m54.451s user 0m0.240s sys 0m0.568s

The result is not as clear as it should be. My guess is that it actually handles 11 blocks of 512KB each, in SLC mode, but has to write them back to 1.5 MB blocks later. I've seen the same before on other Sandisk cards.

$ sudo time ./flashbench --open-au --erasesize=$[4*1024*1024] --blocksize=$[16*1024] --open-au-nr=1 --offset=$[40*1024*1024] --random /dev/mmcblk0 4MiB 13.7M/s 2MiB 13M/s 1MiB 12.1M/s 512KiB 5.64M/s 256KiB 3.01M/s 128KiB 2.32M/s 64KiB 2.23M/s 32KiB 1.22M/s 16KiB 590K/s

real 0m17.887s user 0m0.200s sys 0m0.352s

This basically confirms the same thing: The card can actually handle random writes I think, but only withing 512 KB areas (this is good). However, the 40MB offset is probably incorrect. If I'm guessing right, the throughput numbers should be significantly better for

sudo time ./flashbench --open-au --erasesize=$[512*1024] --open-au-nr=1 \ --offset=$[48*1024*1024]

with and without --random.

Anyway, this card is very different from the Samsung one, but it also appears to be really good.

Arnd