Linux Partitions – How to Achieve Optimal Alignment for eMMC Partition

gptlinuxparteduefi

We have bbb based custom board containing eMMC.
And we have created partitions as follows,

parted --script -a minimal /dev/mmcblk0 \
  mklabel gpt \
  mkpart primary 131072B 262143B \
  mkpart primary 262144B 393215B \
  mkpart primary 393216B 524287B \
  mkpart primary 524288B 1572863B \
  mkpart primary 1572864B 2621439B \ 
  mkpart primary 2621440B 3145727B \
  mkpart primary 3145728B 3276799B \ 
  mkpart primary 3276800B 8519679B \
  mkpart primary 8519680B 13762559B \
  mkpart primary 13762560B 19005439B \
  mkpart primary 19005440B 19267583B \
  mkpart primary 19267584B 19529727B \
  mkpart primary 19529728B 19791871B \
  mkpart primary 20MiB 31MiB \
  mkpart primary ext4 32MiB 232MiB \
  mkpart primary ext4 232MiB 432MiB \
  mkpart primary ext4 432MiB 532MiB \
  mkpart primary ext4 532MiB 592MiB \
  mkpart primary ext4 592MiB 792MiB \
  mkpart primary ext4 792MiB 827MiB \
  mkpart primary ext4 827MiB 3650MiB \

With above command we are able to partition eMMC but alignment is set to minimal. We wanted to check how can we achieve optimal alignment ?
Is there any advantage in achieving optimal alignment ?
I referred this link but solutions like parted -a opt /dev/sdb mkpart primary 0% 100% can not be used as we need following structure.

# parted --list
Model: MMC MMC04G (sd/mmc)
Disk /dev/mmcblk0: 3842MB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system  Name        Flags
 1      131kB   262kB   131kB                
 2      262kB   393kB   131kB                
 3      393kB   524kB   131kB                
 4      524kB   1573kB  1049kB               
 5      1573kB  2621kB  1049kB               
 6      2621kB  3146kB  524kB                
 7      3146kB  3277kB  131kB                
 8      3277kB  8520kB  5243kB               
 9      8520kB  13.8MB  5243kB               
10      13.8MB  19.0MB  5243kB               
11      19.0MB  19.3MB  262kB                
12      19.3MB  19.5MB  262kB                
13      19.5MB  19.8MB  262kB                
14      21.0MB  32.5MB  11.5MB               
15      33.6MB  243MB   210MB   ext4         
16      243MB   453MB   210MB   ext4         
17      453MB   558MB   105MB   ext4         
18      558MB   621MB   62.9MB  ext4         
19      621MB   830MB   210MB   ext4         
20      830MB   867MB   36.7MB  ext4         
21      867MB   3827MB  2960MB  ext4

With current command if we replace minimal with optimal we are seeing following messages from parted,

Warning: The resulting partition is not properly aligned for best performance.
Warning: The resulting partition is not properly aligned for best performance.
Warning: The resulting partition is not properly aligned for best performance.
Warning: The resulting partition is not properly aligned for best performance.
Warning: The resulting partition is not properly aligned for best performance.
Warning: The resulting partition is not properly aligned for best performance.
Warning: The resulting partition is not properly aligned for best performance.
Warning: The resulting partition is not properly aligned for best performance.
Warning: The resulting partition is not properly aligned for best performance.
Warning: The resulting partition is not properly aligned for best performance.
Warning: The resulting partition is not properly aligned for best performance.
Warning: The resulting partition is not properly aligned for best performance.

Any pointers/suggestions/correction for achieving optimal alignment ?

as suggested in the this link I extracted following values,

# cat /sys/class/mmc_host/mmc1/mmc1\:0001/block/mmcblk0/queue/optimal_io_size
0
# cat /sys/class/mmc_host/mmc1/mmc1\:0001/block/mmcblk0/queue/minimum_io_size
512
# cat /sys/class/mmc_host/mmc1/mmc1\:0001/block/mmcblk0/alignment_offset
0
# cat /sys/class/mmc_host/mmc1/mmc1\:0001/block/mmcblk0/queue/physical_block_siz
e
512

mmc utils give following output,

# ./mmc extcsd read /dev/mmcblk0
=============================================
  Extended CSD rev 1.5 (MMC 4.41)
=============================================

Card Supported Command sets [S_CMD_SET: 0x01]
HPI Features [HPI_FEATURE: 0x03]: implementation based on CMD12
Background operations support [BKOPS_SUPPORT: 0x01]
Background operations status [BKOPS_STATUS: 0x02]
1st Initialisation Time after programmed sector [INI_TIMEOUT_AP: 0x7a]
Power class for 52MHz, DDR at 3.6V [PWR_CL_DDR_52_360: 0x00]
Power class for 52MHz, DDR at 1.95V [PWR_CL_DDR_52_195: 0x00]
Minimum Performance for 8bit at 52MHz in DDR mode:
 [MIN_PERF_DDR_W_8_52: 0x00]
 [MIN_PERF_DDR_R_8_52: 0x00]
TRIM Multiplier [TRIM_MULT: 0x06]
Secure Feature support [SEC_FEATURE_SUPPORT: 0x15]
Secure Erase Multiplier [SEC_ERASE_MULT: 0x02]
Secure TRIM Multiplier [SEC_TRIM_MULT: 0x03]
Boot Information [BOOT_INFO: 0x07]
 Device supports alternative boot method
 Device supports dual data rate during boot
 Device supports high speed timing during boot
Boot partition size [BOOT_SIZE_MULTI: 0x10]
Access size [ACC_SIZE: 0x06]
High-capacity erase unit size [HC_ERASE_GRP_SIZE: 0x08]
 i.e. 4096 KiB
High-capacity erase timeout [ERASE_TIMEOUT_MULT: 0x01]
Reliable write sector count [REL_WR_SEC_C: 0x01]
High-capacity W protect group size [HC_WP_GRP_SIZE: 0x01]
 i.e. 4096 KiB
Sleep current (VCC) [S_C_VCC: 0x08]
Sleep current (VCCQ) [S_C_VCCQ: 0x08]
Sleep/awake timeout [S_A_TIMEOUT: 0x10]
Sector Count [SEC_COUNT: 0x00728000]
 Device is block-addressed
Minimum Write Performance for 8bit:
 [MIN_PERF_W_8_52: 0x08]
 [MIN_PERF_R_8_52: 0x08]
 [MIN_PERF_W_8_26_4_52: 0x08]
 [MIN_PERF_R_8_26_4_52: 0x08]
Minimum Write Performance for 4bit:
 [MIN_PERF_W_4_26: 0x08]
 [MIN_PERF_R_4_26: 0x08]
Power classes registers:
 [PWR_CL_26_360: 0x00]
 [PWR_CL_52_360: 0x00]
 [PWR_CL_26_195: 0x00]
 [PWR_CL_52_195: 0x00]
Partition switching timing [PARTITION_SWITCH_TIME: 0x01]
Out-of-interrupt busy timing [OUT_OF_INTERRUPT_TIME: 0x02]
Card Type [CARD_TYPE: 0x07]
 HS Dual Data Rate eMMC @52MHz 1.8V or 3VI/O
 HS eMMC @52MHz - at rated device voltage(s)
 HS eMMC @26MHz - at rated device voltage(s)
CSD structure version [CSD_STRUCTURE: 0x02]
Command set [CMD_SET: 0x00]
Command set revision [CMD_SET_REV: 0x00]
Power class [POWER_CLASS: 0x00]
High-speed interface timing [HS_TIMING: 0x01]
Erased memory content [ERASED_MEM_CONT: 0x00]
Boot configuration bytes [PARTITION_CONFIG: 0x00]
 Not boot enable
 No access to boot partition
Boot config protection [BOOT_CONFIG_PROT: 0x00]
Boot bus Conditions [BOOT_BUS_CONDITIONS: 0x00]
High-density erase group definition [ERASE_GROUP_DEF: 0x01]
Boot write protection status registers [BOOT_WP_STATUS]: 0x00
Boot Area Write protection [BOOT_WP]: 0x00
 Power ro locking: possible
 Permanent ro locking: possible
 ro lock status: not locked
User area write protection register [USER_WP]: 0x00
FW configuration [FW_CONFIG]: 0x00
RPMB Size [RPMB_SIZE_MULT]: 0x01
Write reliability setting register [WR_REL_SET]: 0x00
 user area: existing data is at risk if a power failure occurs during a write operation
 partition 1: existing data is at risk if a power failure occurs during a write operation
 partition 2: existing data is at risk if a power failure occurs during a write operation
 partition 3: existing data is at risk if a power failure occurs during a write operation
 partition 4: existing data is at risk if a power failure occurs during a write operation
Write reliability parameter register [WR_REL_PARAM]: 0x05
 Device supports writing EXT_CSD_WR_REL_SET
 Device supports the enhanced def. of reliable write
Enable background operations handshake [BKOPS_EN]: 0x00
H/W reset function [RST_N_FUNCTION]: 0x00
HPI management [HPI_MGMT]: 0x01
Partitioning Support [PARTITIONING_SUPPORT]: 0x03
 Device support partitioning feature
 Device can have enhanced tech.
Max Enhanced Area Size [MAX_ENH_SIZE_MULT]: 0x0001ca
 i.e. 1875968 KiB
Partitions attribute [PARTITIONS_ATTRIBUTE]: 0x00
Partitioning Setting [PARTITION_SETTING_COMPLETED]: 0x00
 Device partition setting NOT complete
General Purpose Partition Size
 [GP_SIZE_MULT_4]: 0x000000
 [GP_SIZE_MULT_3]: 0x000000
 [GP_SIZE_MULT_2]: 0x000000
 [GP_SIZE_MULT_1]: 0x000000
Enhanced User Data Area Size [ENH_SIZE_MULT]: 0x000000
 i.e. 0 KiB
Enhanced User Data Start Address [ENH_START_ADDR]: 0x000000
 i.e. 0 bytes offset
Bad Block Management mode [SEC_BAD_BLK_MGMNT]: 0x00

EDIT: Achieved optimal alignment as suggested by "Глеб Майоров", Except first 3 partition(which I can't change) other small partitions are changed to minimum of 1MiB size. And except for 3 partitions, all other partitions seems to be aligned. Here is the latest partitioning script I used for eMMC.(Please note: In below script I have changed partition sizes w.r.t above script)

parted --script -a optimal /dev/mmcblk0 \
  mklabel gpt \
  mkpart primary 128KiB 255KiB \
  mkpart primary 256KiB 383KiB \
  mkpart primary 384KiB 511KiB \
  mkpart primary 1MiB 2MiB \
  mkpart primary 2MiB 3MiB \ 
  mkpart primary 3MiB 4MiB \
  mkpart primary 4MiB 5MiB \ 
  mkpart primary 5MiB 10MiB \
  mkpart primary 10MiB 15MiB \
  mkpart primary 15MiB 20MiB \
  mkpart primary 20MiB 21MiB \
  mkpart primary 21MiB 22MiB \
  mkpart primary 22MiB 23MiB \
  mkpart primary 23MiB 30MiB \
  mkpart primary ext4 30MiB 530MiB \
  mkpart primary ext4 530MiB 1030MiB \
  mkpart primary ext4 1030MiB 1130MiB \
  mkpart primary ext4 1130MiB 1190MiB \
  mkpart primary ext4 1190MiB 1720MiB \
  mkpart primary ext4 1720MiB 1755MiB \
  mkpart primary ext4 1755MiB 100%

Best Answer

Try to align to eMMC erasure block size. It usually equals 0.5, 1, 2, 4, 8 MiB depending on eMMC datasheet. If you find block size alignment too much memory wasting, then stick to the page size, generally found in the range of 4..16 KiB.

Try to make partition sizes and borders a multiple of erasure block size, so when file system writes to the first or last FS block, memory card doesn't have to erase and rewrite beginning/end of next/previous partition.

Don't rely on parted's features to align, just take a calculator, pen and a sheet of paper, and count up a correct borders in sectors or bytes.

Personally, I prefer aligning to 8 MiB border, because it isn't waste too much memory, and any partition starts and ends on erasure block border regardless of specific erasure block size, so I don't need to search for memory card documentation.

Optimal alignment reduces write amplification factor, so your memory could last longer.

Related Solutions

Linux – LVM2 partition alignment

On a recent Linux distribution, the kernel should provide the physical sector size of the device and the partition/lvm/mkfs tools should automatically chose the alignment such that it is compatible with the physical sector size (for best performance).

For example on a Debian system of mine:

# cat /sys/block/sdb/queue/physical_block_size
4096
# cat  /sys/block/sdb/queue/logical_block_size
512

Update: To check for kernel support, you can check if /sys contains the mentioned files, you can call fdisk -l to check if it prints this information (it should), you can check the specification of your hard disk (available by your vendor), you can check the changelog and/or source of LVM tools. Most mkfs commands provide a verbose option to see what block size is used. Last but not least you can just do a simple benchmark - e.g. one without any LVM (e.g. whole disk as device) and repeat it when your LVM setup is in place.

Linux – Safely use SD cards when power can go out at any time

Well, the way you can fix this is to fix the "power can be cut at any time" problem. Is it impossible to add even a minute of battery power?

Alternatively, maybe you could use two SD cards. Write the data to one card, sync, write to the other. Each block of your data would need a checksum and block number, but then even with some pretty unlucky power failures, one of the cards should be right.

Your basic problem is going to be wear leveling on the SD cards, which AFAIK depends on the card vendor (and maybe even the batch, they can change it whenever). It probably doesn't handle power outage correctly. And depending on what it does, that may not just mean corrupting the block you're writing to.

Assume trivially small card—3 (flash) blocks. Block 1 has received more writes than 2 or 3. I'll call the physical blocks by number, and logical blocks A, B, C by letter. Right now, A=1, B=2, C=3.
You issue a write to block A . SD card is like aha! we need wear leveling here, else block 1 is going to wear out before 2 and 3. It decides to swap block 1 and 2.
It reads block 1 into RAM position i (on the SD card, not system RAM). It updates the part you wanted to change.
It reads block 2 into RAM position ii
It erases block 1
It writes RAM position ii to block 1.
It updates the mapping table to say B=1
It erases block 2.
It writes RAM position i to block 2.
It updates the mapping table to say A=2

Of course, "updates the mapping table" isn't always trivial. And the order of 5–10 could be different (if they all complete, it doesn't matter, well the erases have to come before writes, of course). But a power failure happens, you could wind up with not only A corrupted (as you expect) but B as well. Or, if power failure happens during a mapping update, who knows what kind of corruption that'll cause.

Best Answer

Related Solutions

Linux – LVM2 partition alignment

Linux – Safely use SD cards when power can go out at any time

Related Question