[systemd-devel] How to speed up detection of emmc partition and mount the filesystem

[Lennart Poettering]

On Mo, 04.02.19 20:22, Petr (coran at atlas.cz) wrote:

> Hello,
>
> I have custom linux on embedded machine generated with Buildroot
> using  emmc drive which contains  root filesystem on /dev/mmcblk0p2
> and application data on  /dev/mmcblk0p4. The root fileystem is
> mounted pretty quickly, but the application data are mounted about
> 1.7s after systemd starts, the main reason is that the mmcbl0p4 is
> found by systemd after 1.4s. As a workaround I created service that

systemd will "see" the device as soon as udev reports it to be around,
i.e. after it was triggered via "systemd-udev-trigger.service", then
reported to userspace, then probed by udev's blkid logic, and finally
reported to systemd by udev.

There are plenty tools available that help you analyzing what is being
done in early boot that delays stuff, for example systemd-bootchar
(a separate project from systemd itself).

If you want to tune this, you could trigger storage devices first,
which also generally means they are announced, probed and so on first.

> is executed right after the local-fs-pre.target which execute "mount
> /dev/mmcblk0p4 /app" and that works, but I would like to know if
> there is correct way how to tell systemd that I want to mount the
> root fs and application fs sooner than everything else (I believe
> that what I want is to tell systemd to mount /dev/mmcblk0p4 without
> waiting for udev to find /dev/mmcblk0p4 as new device and start auto
> mount).
>
> This log appears after 1.4s from systemd starts, but I need that device much sooner:

You can mark any mount as automount in /etc/fstab, by adding
x-systemd.automount to the mount options. If so systemd will generate
both an .automount unit, and a .mount unit for it, and only the
.automount unit is started early. This is an effective parallelization
technique and allows you to have any mount you like appear in the file
system at a moment where its backing device hasn't shown up yet, its
fsck hasn't run yet or its kernel mount not established yet. It works
very well for every fs that isn#t needed immediately during early
boot, since it basically allows establishing of mounts ahead of time,
where direct access will block but not the simple act of mounting.

Lennart

--
Lennart Poettering, Red Hat