Partitioning and formatting the SDHC card for best results?

[Nazo]

As far as I can really tell, the images and such aren't really aligning the partitions for the best results with SDHC. The problem, of course, is that SDHC has to be aligned differently from a harddrive and most tools are just looking at these as being basically a harddrive (it doesn't help that they seem to provide numbers for cylinders, heads, and sectors -- I don't know if that's the reader or the card itself, but either way these obviously are not harddrives with cylinders or heads... Then again, even that's just a legacy system that isn't really accurate with modern drives either I think.)

It seems that optimal setup involves first starting the first partition after the first "erase boundary" which seems to usually be at 4MB thus creating the first problem -- actually getting a partition exactly the right starting distance. I'll admit I got a bit lazy on this much and just used the Panasonic SD formatter tool since the explanations I could find on how to do it with fdisk just left me uncertain how to get it to align exactly right. The second problem is that all of these things assume you're just doing one single partition all the way across the card when, in fact, we want two. Ok, resizing is easy enough, but then there's the next problem: how do you actually align the second partition? I'd imagine that as an ideal setup you really want the first partition to end right on an erase boundary and the second start with the next one, but I have no clue how to actually align it exactly like that -- tools keep giving me arbitrary units. Someone told me parted could be made to show different units, but I have to admit that my familiarity with parted is limited solely to gparted and the command-line tool is completely new to me.

Finally, even if everything is aligned properly filesystems must actually be formatted correctly. With FAT32 I know all you have to do is set an allocation unit size of 32768 bytes for the best results, but I have to admit that I apparently have been doing it wrong with mkfs.vfat. Well, no big deal there, I can format FAT32 from Windows easily enough. But what about the EXT4 partition? It doesn't do "allocation units" but instead works quite differently. One person talked about the settings to be used in one tutorial I was reading, but they also were doing other things I don't want to do (for example, I don't want journalizing off -- I realize it would bottleneck a bit less without it, but at the same time, the RPi has occasions in which I must physically pull the power plug while it's on, which is just begging for trouble without journalizing...)

I can't help but to think that some of the bottlenecking that I've seen (especially on slower cards -- "slower" being defined as even a class 6 card for me) could be solved by not having write operations generally made more inefficient by the partitioning and filesystems themselves. This also would increase the overall lifetime of the card. Having the card act at its very best seems like a good idea for something that actually runs directly from it like this. Obviously this is too complicated for the complete newbie who has never used *nix before, but many of us at least have the basic knowledge enough to do this sort of thing and just need a little guidance I think.


Does anyone have any useful guides, scripts, or even just plain advice on the best way to get multiple partitions aligned on a SDHC card for the optimal performance to squeeze the very most out of the card?

[dukla2000]

Yup, Terje's blog

[Nazo]

How do I apply that to a device with more than one partition and with journalizing turned on?

[dukla2000]

How do I apply that to a device with more than one partition ...

As per his example just make sure each new partition starts on a multiple of 16384 sectors. Most of my cards have had 4MB erasure block so all my partitions start on 8192 sector multiples.

... and with journalizing turned on?

Change the formatting options - in his example he is using ext4 format for the 1 partition, type
man mkfs.ext4
to see all ext4 options

[55020]

It's about time someone did a proper job on this. There's a lot of advice out there that is just cut and pasted from other places without any critical thinking. A lot of the advice is contradictory, or even self-contradictory. A lot of the distribution images don't make any attempt at optimisation. So I'll have a go at some reasoned advice right here and now, and if other people want to shoot it down in flames they are welcome to come up with something better.

We want to honour 4Mb or 8Mb erase block boundaries, right? So why do elinux and many distros recommend and use 255H/63S geometry, which is (AIUI) pretty much guaranteed to be maximally wrong if you use ext4 defaults? AFAICT cards don't come from the manufacturers like that. 128H/32S gives 2Mb cylinders, so starting partitions on 4cyl boundaries does the 8Mb trick. Having said that, I see no reason for aligning the vfat boot partition onto an erase block boundary, since it's written so rarely and has zilch impact on performance. You might as well start it right after the partition table and end it on an 8Mb boundary.

Incidentally, why do so many distros use partition 2 for root and 3 for swap? That's daft, it makes it much harder to maximise the root partition to match the card's capacity. The other way round would avoid the need to move the swap out of the way. (There's also an unverified school of thought that swapping onto a filesystem file would help to level wear on the SD card, but that's a digression.)

So: 128H/32S, start your boot at sector 32 (or 1), end it on a multiple of 16384 sectors. If you want a swap partition create it next, sized to a multiple of 8Mb. Allocate the rest of the card for your ext4 root, use Terje's -O ^have_journal -E stride=2,stripe-width=1024 -b 4096. Job's a good un.

I would also take issue with Terje's "changes to mount". As a minor quibble, noatime implies nodiratime ( http://lwn.net/Articles/245002/ ). As a bigger quibble, the noop scheduler is IMO bad advice for any realistic workload on most SDHC cards. It's a dumb fifo, so it won't attempt to localise writes (thus conjecturally bad for the life of your SD card), and it'll kill interactive response under heavy load. Deadline will help with the latter, but not the former. Stick with cfq, or give bfs a whirl.

[RaTTuS]

I've used linux on USB RAM sticks before now
8Gb /16GB
both with and with micro SD cards.

deadline is a load better than cfq for responsiveness but then YMMV as it depends on what you are doing. - my systems tended to be 8Gb RAM , 8 or 16GB USB drive but random access really felt sluggish.

I agree with most of the other stuff though

[55020]

Previously, I wrote:

255H/63S geometry, which is (AIUI) pretty much guaranteed to be maximally wrong if you use ext4 defaults?

This actually turns out to be rubbish, as geometry has no effect whatsoever on ext4's block groups. However, most partitioning tools seem to like to start partitions on cylinder boundaries, so the net effect is suboptimal, unless of course I'm talking rubbish again.