1 |
On Thursday, August 06, 2015 6:18:59 PM Meino.Cramer@×××.de wrote: |
2 |
> Hi, |
3 |
> |
4 |
> for my tablet PC I used a used 32GB FAT32 formatted SDcard. The |
5 |
> formatting was already done by the manufacturer. |
6 |
> Then I screwed it up and had to do the partioning and formatting |
7 |
> myself again. "No big deal", I thought -- and was wrong. |
8 |
> Yes, the "thing" I got could be read and written. But it was |
9 |
> DAMN slow in comparison to the original formatting. |
10 |
> |
11 |
> I googled and found a description, which described exactly, |
12 |
> what I wanted: An optimal formatting for one big FAT32 partion. |
13 |
> I did it again ;) and: TADA! The speed was back. |
14 |
> LINK:http://zero1-st.blogspot.de/2012/05/formatting-fat32-volumes-larger-than.html |
15 |
> |
16 |
> Now I need the something identical but explained in a way |
17 |
> that it can be successfully applied to any partion layout |
18 |
> and any SDcard size. |
19 |
> Currently the new SDcard has 64GB (yes, the tablet eats that size |
20 |
> well :) and needs at least two partions: One FAT32 and one ext4. |
21 |
> May be that I need a different layout later. |
22 |
> |
23 |
> To what aspect and "logic" do I have to keep my eyes on, when |
24 |
> it comes partioning/formatting any SDcard size with any partion |
25 |
> layout and any filesystem? |
26 |
> |
27 |
> Thank you very much in advance for any help! |
28 |
> Best regards, |
29 |
> Meino |
30 |
|
31 |
I had to research this a few years back when writing a FAT32/SD driver[1] for |
32 |
an embedded project because all the available choices where too slow at |
33 |
writing for my requirements. It's been a while so excuse me if I got some |
34 |
details wrong. Most of the information you'll find around is wrong (it may |
35 |
still give you good results as in your case) but the only reliable source I |
36 |
found is the specification[2]. |
37 |
|
38 |
128KB is not the magic number, SD cards (except for the very early ones or |
39 |
standard SD) are divided into Allocation Units (AU) that are between 1-4 MB |
40 |
for SDHC and even greater for SDHC. To get the actual value you need to read a |
41 |
register on the card (Linux may expose it on /sys, not sure), I did this work |
42 |
on Windows and I had to write a program (now lost) to guess it by writting at |
43 |
different boundaries and benchmarking. The Windows 7 and later formatting |
44 |
utility will align it properly though. |
45 |
|
46 |
The AUs are further divided into Recording Units (RU). These are determined by |
47 |
the speed class of the card (the number inside the C on the label) and the |
48 |
capacity. For class 2 and 4 it is 16kb if the card is under 1GB or 32K |
49 |
otherwise. For class 6 it is 64KB, and for class 10 it is 512KB. |
50 |
|
51 |
After an AU is erased you can write to all the RUs within it in any order but |
52 |
if you modify an RU all the used RUs on that AU need to be copied to a new AU. |
53 |
|
54 |
So to get the best performance you need to make sure that the first cluster is |
55 |
aligned to an AU boundary and erase the padding sectors before writing the FAT |
56 |
(I'm not sure if mkdosfs can do that last bit from userspace), otherwise |
57 |
everytime the FAT is updated all the padding sectors are copied needlessly. |
58 |
The next best thing is aligning it to an RU boundary which is easier to |
59 |
determine. |
60 |
|
61 |
1. https://github.com/fernando-rodriguez/fat32lib/ |
62 |
2. https://www.sdcard.org/downloads/pls/ |
63 |
|
64 |
-- |
65 |
Fernando Rodriguez |