You are not logged in.
Pages: 1
Hello arch users,
I'm currently trying to improve performance on my netbook that runs arch linux.
Today I installed a custom kernel (optimized for Atom processor) and rebuilt the initramfs and I'm pretty satisfied with my boot speed.
Still there is this 'dev-sda1.device' thing in my 'systemd-analyze blame':
4.699s dev-sda1.device
1.926s systemd-journald.service
1.765s systemd-vconsole-setup.service
963ms systemd-tmpfiles-setup-dev.service
962ms systemd-journal-flush.service
844ms lightdm.service
697ms systemd-udevd.service
457ms tmp.mount
440ms udisks2.service
416ms sys-kernel-debug.mount
372ms systemd-remount-fs.service
359ms systemd-fsck@dev-sda6.service
323ms sys-kernel-config.mount
318ms systemd-sysctl.service
318ms dev-mqueue.mount
316ms dev-hugepages.mount
301ms systemd-udev-trigger.service
294ms polkit.service
234ms systemd-random-seed.service
145ms systemd-backlight@backlight:acpi_video0.service
144ms user@620.service
139ms home.mount
126ms systemd-tmpfiles-setup.service
122ms kmod-static-nodes.service
This seems to be very time consuming. What is 'dev-sda1.device'? I tried "find . -name 'dev-sda1.device'" with no results and I searched Google...
Is it just a "virtual" name for the process which mounts /dev/sda1? (which is my / partition by the way, where /dev/sda is a HDD)
And why does it take "this long"? I would like to improve everything I can
Offline
From 'man systemd.device':
systemd will dynamically create device units for all kernel devices that are marked with the "systemd" udev tag
(by default all block and network devices, and a few others)
These units are not present on the file system.
4.699s dev-sda1.device
I think that this time includes the fsck running time, which depends on the partition size.
On my machine, where sda3 is my root partition, I get:
$ systemd-analyze blame|grep device
3.647s dev-sda3.device
$ systemctl status dev-sda3.device
● dev-sda3.device - Hitachi_HDP725050GLA360 3
Follow: unit currently follows state of sys-devices-pci0000:00-0000:00:0e.0-ata1-host0-target0:0:0-0:0:0:0-block-sda-sda3.device
Loaded: loaded
Active: active (plugged) since mer. 2015-04-29 10:19:21 CEST; 6h ago
Device: /sys/devices/pci0000:00/0000:00:0e.0/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda3
$ journalctl -b|grep sda3
avril 29 10:19:18 arch64 kernel: sda: sda1 sda2 sda3 sda4 < sda5 sda6 sda7 >
avril 29 10:19:18 arch64 kernel: EXT4-fs (sda3): mounting ext3 file system using the ext4 subsystem
avril 29 10:19:18 arch64 kernel: EXT4-fs (sda3): mounted filesystem with ordered data mode. Opts: (null)
avril 29 10:19:19 arch64 systemd-fsck[130]: /dev/sda3: clean, 206507/1313280 files, 1624052/5242880 blocks
avril 29 10:19:19 arch64 kernel: EXT4-fs (sda3): re-mounted. Opts: (null)
Since the '10:19:18' boot time to the '10:19:21' 'dev-sda3.device' activation time there is the 3.647s lapse.
The journal shows that the 'systemd-fsck[130]: /dev/sda3' is included.
Maybe preventing the fsck on this partition might reduce the activation time of your 'dev-sda1.device'.
But is 4.7s so long?
Last edited by berbae (2015-04-29 15:01:36)
Offline
Thanks! great answer!
Compared to the other processes takes long, but I want fsck on boot, so I will accept that
As far as I have heard disabling fsck on boot is a very bad idea unless you're using btrfs.
Offline
Pages: 1