Double your Manjaro eMMC speed
#1
It appears the default partitions Manjaro creates on the eMMC are not aligned.  This is really bad for performance!  Here's how to check this and fix it without re-installing or erasing eMMC.  You do need a boot from a bootable sdcard to do the final step.

First, check the alignment:
Quote:$ sudo sfdisk -l /dev/mmcblk2

Disk /dev/mmcblk2: 58.24 GiB, 62537072640 bytes, 122142720 sectors

Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x87129214

Device         Boot  Start       End   Sectors   Size Id Type
/dev/mmcblk2p1       62500    500000    437501 213.6M  [font=monospace]c W95 FAT32 (LBA)
 
/dev/mmcblk2p2      500001 122142719 121642719    58G 83 Linux[/font]

The start of the root partition should be aligned to a multiple of 4kB, if not more.  That means the start sector (500001) should be a multiple of 8 (8 sectors of 512 bytes is 4 kB).  It's not even a multiple of two!

The process to fix this will be shrink the boot partition, p1, to be a bit smaller and then move the root partition down so it's aligned.

Here's the process for shrinking the boot partition.  It can be done when booted from eMMC since the boot partition isn't actively used and can be unmounted.

There's a tool called fatresize that should be able to shrink it in place, but it doesn't work.  Since it's small, I just make a copy and reflash it.

As we can see in post #1, the current size of the boot partition is 437501 sectors.  I want to shrink that by 289 sectors, which will then align the root partition to 4MB.  The mkfs.vfat command wants the size in kilobytes, which are two sectors.

Quote:$ mkfs.vfat -v -n BOOT_MNJRO -C new-root.img $(( (437501 - 289) / 2 ))

mkfs.fat 4.1 (2017-01-24)
new-root.img has 64 heads and 32 sectors per track,
hidden sectors 0x0000;
logical sector size is 512,
using 0xf8 media descriptor, with 437212 sectors;
drive number 0x80;
filesystem has 2 16-bit FATs and 8 sectors per cluster.
FAT size is 216 sectors, and provides 54592 clusters.
There are 8 reserved sectors.
Root directory contains 512 slots and uses 32 sectors.
Volume ID is 7d933d98, volume label BOOT_MNJRO .

Now we want to loopback mount this filesystem and copy the contents of /boot into it.
Quote:$ sudo mount -o loop new-root.img /mnt

[font=Arial]# Check that the filesystems are mounted as expected and the new one is empty.

$ df /boot /mnt
Filesystem     1K-blocks  Used Available Use% Mounted on
/dev/mmcblk2p1    218512 40296    178216  19% /boot
/dev/loop0        218368     0    218368   0% /mnt

# Copy all the files
$ sudo cp -a /boot/. /mnt

# Check fs is filled as expected
# It wouldn't hurt to ls -l /mnt too

$ df /boot /mnt
Filesystem     1K-blocks  Used Available Use% Mounted on
/dev/mmcblk2p1    218512 40296    178216  19% /boot
/dev/loop0        218368 40296    178072  19% /mnt[/font]

Ok, now we'll umount both filesystems and copy the new image over the existing fs.  If anything goes wrong while copying then you're in trouble but should still be able to recover from SD since this doesn't wipe out the eMMC u-boot.  But it only takes a couple second to copy the data.
Quote:$ sudo umount /dev/mmcblk2p1

$ sudo umount /mnt


[font=Arial]# This is the command that writes the partition.  Be sure you have mmcblk2p1 here!

$ sudo dd if=new-root.img of=/dev/mmcblk2p1
[/font]


And now for the final step, we'll shrink the size of the boot partition table entry to be 289 sectors smaller.

Quote:
$ echo ",-289" | sudo sfdisk --no-reread -N 1 /dev/mmcblk2
[font=monospace]
Disk /dev/mmcblk2: 58.24 GiB, 62537072640 bytes, 122142720 sectors

Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x87129214

Old situation:

Device         Boot  Start       End   Sectors   Size Id Type
/dev/mmcblk2p1       62500    500000    437501 213.6M  c W95 FAT32 (LBA)
/dev/mmcblk2p2      500001 122142719 121642719    58G 83 Linux

/dev/mmcblk2p1:
New situation:
Disklabel type: dos
Disk identifier: 0x87129214

Device         Boot  Start       End   Sectors   Size Id Type
/dev/mmcblk2p1       62500    499711    437212 213.5M  c W95 FAT32 (LBA)
/dev/mmcblk2p2      500001 122142719 121642719    58G 83 Linux

The partition table has been altered.
Calling ioctl() to re-read partition table.
Re-reading the partition table failed.: Device or resource busy
The kernel still uses the old table. The new table will be used at the next reboot or after you run partprobe(8) or partx(8).
Syncing disks.

[/font]

And now reboot so the new table takes effect.  It can't be re-read because the root partition is still mounted from /dev/mmcblk2p2 and you can't unmount that.  If you were booted from SD then the table re-read will have worked.  You might want reboot from eMMC anyway just to be sure it all still works.
#2
And now to resize the root partition.  I don't know of any way to move the partition while it's in use, so it's necessary to boot from an SD card to do this.

sfdisk can adjust the partition to move all the data over.  This involves copying about 58 GB and takes over an hour.

If anything interrupts this process, you've pretty much lost the root partition and will need to re-install.  So make sure you have plenty of power in the battery and are plugged in and don't suspend in the middle!

One should run lsblk and make sure nothing from /dev/mmcblk2 is mounted.  At some point the desktop environment might auto-mount a partition after a command.  So always check and umount them first.

This will use sfdisk to move the entire partition and all its data to be 289 sectors earlier.  So far, the size remains the same and the contents aren't altered.
Quote:$ echo "-289," | sudo sfdisk -N 2 /dev/mmcblk2 --move-data

Checking that no-one is using this disk right now ... OK 

Disk /dev/mmcblk2: 58.24 GiB, 62537072640 bytes, 122142720 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x87129214

Old situation:

Device         Boot  Start       End   Sectors   Size Id Type
/dev/mmcblk2p1       62500    499711    437212 213.5M  c W95 FAT32 (LBA)
/dev/mmcblk2p2      500001 122142719 121642719    58G 83 Linux 

/dev/mmcblk2p2:
New situation:
Disklabel type: dos
Disk identifier: 0x87129214 

Device         Boot  Start       End   Sectors   Size Id Type 
/dev/mmcblk2p1       62500    499711    437212 213.5M  c W95 FAT32 (LBA)
/dev/mmcblk2p2      499712 122142430 121642719    58G 83 Linux

Data move:
 start sector: (from/to) 500001 / 499712
 sectors:  121642719
 step size: 1048576 bytes

Moved 121642719 from 121642719 sectors (100%).

The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.

Notice how the start sector, 499712, is now a multiple of 8192.  Much better.

We could stop here, but there are now 289 wasted sectors at the end of the device.  We can enlarge the filesystem to fill them.  The next command is to make the partition larger, in this case to fill all available space and then resize the filesystem to fill the larger partition.

Quote:
$ echo ",+" | sudo sfdisk -N 2 /dev/mmcblk1

Checking that no-one is using this disk right now ... OK 

Disk /dev/mmcblk2: 58.24 GiB, 62537072640 bytes, 122142720 sectors
Units: sectors of 1 * 512 = 512 bytes 
Sector size (logical/physical): 512 bytes / 512 bytes 
I/O size (minimum/optimal): 512 bytes / 512 bytes 
Disklabel type: dos 
Disk identifier: 0x87129214

Old situation: 

Device         Boot Start       End    Sectors   Size Id Type
/dev/mmcblk2p1       62500    499711    437212 213.5M  c W95 FAT32 (LBA) 
/dev/mmcblk2p2      500001 122142430 121642719    58G 83 Linux 

/dev/mmcblk2p2: 
New situation: 
Disklabel type: dos 
Disk identifier: 0x87129214 

Device         Boot  Start       End   Sectors   Size Id Type 
/dev/mmcblk2p1       62500    499711    437212 213.5M  c W95 FAT32 (LBA)
/dev/mmcblk2p2      499712 122142719 121643008    58G 83 Linux

$ sudo e2fsck -f -y /dev/mmcblk2p2

e2fsck 1.45.6 (20-Mar-2020)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
ROOT_MNJRO: 235853/312624 files (0.6% non-contiguous), 1103444/15205340 blocks

$ sudo resize2fs /dev/mmcblk2p2

resize2fs 1.45.6 (20-Mar-2020)
Resizing the filesystem on /dev/mmcblk2p2 to 15205376 (4k) blocks.
The filesystem on /dev/mmcblk1p2 is now 15205376 (4k) blocks long.


Possibly Related Threads…
Thread Author Replies Views Last Post
  Manjaro - Internet connection sharing requires dnsmasq (but the dep isn't declared) Dendrocalamus64 0 82 09-11-2021, 05:25 PM
Last Post: Dendrocalamus64
  Pinebook pro nearly unusable after using manjaro-arm-installer TheCounselor 3 675 09-07-2021, 08:34 PM
Last Post: TRS-80
  Sound stuttering on Manjaro gnome after latest kernel upgrade? pjsf 1 285 08-27-2021, 06:09 AM
Last Post: bikerlatt1
  Working suspend on Manjaro brzegorz 2 506 07-30-2021, 06:21 AM
Last Post: vssz
  Manjaro and Arch repository with privacy oriented software as400 78 48,142 07-28-2021, 05:24 AM
Last Post: llsf
  Manjaro [ARM Stable Update] 2021-07-23 issues Bocanila 0 271 07-24-2021, 09:09 AM
Last Post: Bocanila
  Kernel crash on Manjaro ARM mfashby 0 252 07-06-2021, 03:17 PM
Last Post: mfashby
  Manjaro wont recognize eMMC after booting with it disabled peasant 1 378 06-27-2021, 02:39 AM
Last Post: Arwen
  Pinebook Pro Manjaro Power Savinng Tips HelpMyBatteryIsDraining 1 600 06-15-2021, 08:42 AM
Last Post: moonwalkers
  [LibreOffice & Gimp] ARM support: no hardware acceleration on [Manjaro] Pinebook Pro regivanx 0 418 06-15-2021, 04:04 AM
Last Post: regivanx

Forum Jump:


Users browsing this thread: 1 Guest(s)