View Single Post
qole's Avatar
Moderator | Posts: 7,109 | Thanked: 8,820 times | Joined on Oct 2007 @ Vancouver, BC, Canada
#335
Originally Posted by fanoush View Post
Point is that it looks like both partition table and FAT layout is tuned to be aligned with physical flash blocks. By creating random partition table, speed (and maybe even reliability and durability) may go down.

See this article for details
http://www.hjreggel.net/cardspeed/cs_calign.html

So maybe, if nupgrade.sh does the partition layout, it would be nice if it left at least the beginning of first FAT partition alone.

It is hard to know how important it is, maybe not much. YMMV

When I got my 8GB SDHC card I found that first 4MB of the card is 'wasted' and partition begins on block 8192. This is confirmed in the document mentioned above. There is perhaps some reason for this. I think this may be related to erase blocks and grouping of blocks for internal wear level logic. Maybe they try to prevent wearing off the beginning of the card (as it may contain some critical low level data).
This is a bit of black magic. If you are interested, start reading from page 66 of http://www.sdcard.org/about/memory_c...Layer_Spec.pdf
Looks like the size of Allocation Unit (AU) is 4MB for big cards. so it may make sense to aling beginning of partition at 4MB and data blocks after FAT table at 8MB.
That is very interesting, and it is true on both of my 8GB cards.

Code:
sfdisk -l -uM
This produces, in part, the following output (I have 8GB cards in both slots):

Code:
   Device       Start  End    MiB    #blocks    Id  System
/dev/mmcblk0p1    4    7821   7818    8005632    b  W95 FAT32
/dev/mmcblk1p1    4    7819   7816    8003584    b  W95 FAT32
This strongly suggests to me that any script that partitions an SD card should start by checking the start and end points and use those values when repartitioning. I have to agree that we shouldn't be messing with the "black magic".

EDIT: Milhouse (or other file system guru), as you can see above, my cards were factory formatted with 0B FAT32, but you suggest using 0C FAT32 LBA. Why?

Last edited by qole; 2008-04-26 at 07:50.