e4rat - reduce boot time (into X) by some 50% for ext4

jgreen1tc · 2012-05-27 21:25:19

Yes, it didn't harm anything. I did a hard reset and it was fine afterwards. I was just wondering. I just started using e4rat so I don't know if it was because I hadn't collected in a while but I'll try to see if doing so regularly prevents it. Thanks guys.

olebowle · 2012-07-02 10:22:01

I'm using e4rat for quite a while now. To ensure that my boot-up time keeps low I repeat the collect and reallocation steps (based on the arch-wiki page of e4rat) from time to time (~once in 2 months). Today was one of these days. After a reboot I got the following message while start-up:

Mon Jul  2 11:10:17 2012: :: Configuring Virtual Consoles    [BUSY] %G   [DONE] 
Mon Jul  2 11:10:17 2012: :: Adjusting system time and setting kernel timezone    [BUSY]    [DONE] 
Mon Jul  2 11:10:17 2012: :: Starting UDev Daemon    [BUSY]    [DONE] 
Mon Jul  2 11:10:17 2012: :: Triggering UDev uevents    [BUSY]    [DONE] 
Mon Jul  2 11:10:17 2012: :: Loading User-specified Modules    [BUSY]    [DONE] 
Mon Jul  2 11:10:17 2012: :: Waiting for UDev uevents to be processed    [BUSY]    [DONE] 
Mon Jul  2 11:10:17 2012: :: Bringing up loopback interface    [BUSY]    [DONE] 
Mon Jul  2 11:10:17 2012: :: Activating LVM2 groups    [BUSY]    [DONE] 
Mon Jul  2 11:10:17 2012: :: Unlocking encrypted volumes:    [BUSY]    [DONE] 
Mon Jul  2 11:10:17 2012: :: Checking Filesystems    [BUSY] /dev/mapper/vgarch-home: sauber, 404514/11501568 Dateien, 40415068/45991936 Blöcke
Mon Jul  2 11:10:17 2012: /dev/sda2: sauber, 31/36288 Dateien, 33555/144584 Blöcke
Mon Jul  2 11:10:17 2012:    [DONE] 
Mon Jul  2 11:10:17 2012: :: Remounting Root and API filesystems    [BUSY]    [DONE] 
Mon Jul  2 11:10:17 2012: :: Mounting Local Filesystems    [BUSY]    [DONE] 
Mon Jul  2 11:10:18 2012: :: Acti
Mon Jul  2 11:10:18 2012: <F3>T^A^X(8P<FA>l^A<80><D2>s2^YX<E2><94><F1>^2^YX<E2><94><F1>^2^YX<E2><94><F1>^2^YX<E2><94><F1>^2^YX<E2><94><F1>^2^YX<E2><94><F1>^2
<C3>P<FD><9D><EA>l<D5>&<95>^Oh|^N'ת<DD>~<ED><89>   u<F5><D7>df6<FD><FE>^Gg<D0>-۩<92>q&(8<96>:<87>{<9A><B7><89><C1><D7><E8>^LS/<E4>j<98><E5>hX<BA>M<95>X<91>l/
<AC>o4Nk<B7>+ډ<D8>79<B1><8F><D2>k<D6>r/<FF>I;q<98><95>^<F3><9A><FE>k~<9A><E5>Rt<AC>^H$}<DF>^T<FE>!<E9><AC>^G^]d{<B6><ED>xI<BD><C8>ɯ/<F7>:)^To<A7><D6><E7>~<A1>
<F8><F0>4<ED><AB>@^<EC><9A><CC><DE>
Mon Jul  2 11:10:18 2012: /etc/rc.d/functions: Zeile 146: printf: `<BB>': Ungültiges Formatierungszeichen.
Mon Jul  2 11:10:18 2012: <A0>^]^H<AE>;<9E>y^C<94><FF>:<F8><FB><CF><EB><AD>jG<88>V<F6><AC>$<D1>^NS      P>_<CD>'<B0><89>Ė<EA><A4>x^_<A8>dw><BE><EB><97><D4>
<E7><BA><F0><B1>i<CC>^?<92><E1>Y^?<F2><E3><D3><ED><AC><ED><AA>P<A7><A6><C1><DF>ko<A8><A9>p|(<F6><BA>J<BB>4g<A7>fn<C9>lڰK<F5>$.<8C><D6><D2><DD>J<F1><D6>ib}3
<EB><FF>dWB^??<E5>骣<B5><EA><9A>^Tծ>2<E1>5Ǆ<E6>?<BB><95><AD>3<E4><C7><F6><E6>[f<9E><A0>NM   [BUSY]    [DONE] 
Mon Jul  2 11:10:18 2012: /etc/rc.sysinit: Zeile 132: $'\307\236\327H\354\372%\356z\227\023\035A\316\f\327\317\317l\272R\273r\336*\272\255p\356': Kommando nicht gefunden.
Mon Jul  2 11:10:18 2012: /etc/rc.sysinit: Zeile 132: V<B4><CF>H<E4>qʉ<AD><9C>sj<A8><F6><93><C8>q<F9><B1><C1>εs/<89>#ե<B5>y<83><B3>W<B9>^\W: Datei oder Verzeichnis nicht gefunden
Mon Jul  2 11:10:18 2012: /etc/rc.sysinit: Zeile 132: $'\023\275y\re\222': Kommando nicht gefunden.
Mon Jul  2 11:10:18 2012: /etc/rc.sysinit: Zeile 132: SU<E4><FE><DD>t<90>S]<F3>2^_<BE><AA>ܸ^<97><F3>j<D7>D<BA>^H^/<BC><FC><F8>_Ϧ^Z<AF>g: Datei oder Verzeichnis nicht gefunden
Mon Jul  2 11:10:18 2012: INIT: Entering runlevel: 3
Mon Jul  2 11:10:18 2012: :: Starting Syslog-NG    [BUSY]    [DONE] 
Mon Jul  2 11:10:19 2012: :: Starting D-BUS system messagebus    [BUSY]    [DONE] 
Mon Jul  2 11:10:19 2012: :: Starting NetworkManager    [BUSY]    [DONE] 
Mon Jul  2 11:10:20 2012: :: Mounting Network Filesystems    [BUSY]    [DONE] 
Mon Jul  2 11:10:20 2012: :: Starting Cron Daemon    [BUSY]    [DONE] 
Mon Jul  2 11:10:20 2012: :: Starting laptop-mode    [BUSY]    [DONE] 
Mon Jul  2 11:10:22 2012: :: Starting LIRC Daemon    [BUSY]    [DONE] 
Mon Jul  2 11:10:22 2012: :: Starting Up Sensors    [BUSY]    [DONE] 
Mon Jul  2 11:10:22 2012: :: Starting GDM    [BUSY]    [DONE]

So obviously /etc/rc.sysinit was somehow damaged. A look into this file confirmed this concern, the file was indeed garbled. I fixed this by reinstalling initscripts. Still in future I won't use e4rat-realloc anymore as I don't know if and what files it may have also damaged. Fortunately my system seems to be working fine so far.

I don't blame anyone, this is just a warning to be careful using e4rat-realloc. I will still use e4rat-collect from time to time and e4rat-preload for start-up. This should still give me an speed improvement?

PS: I use ext4 on all partitions and did not convert them from ext3.

Trilby · 2012-07-18 19:09:44

How do systemd users run th realloc process?

There is no runlevel 1, nor does rescue.target or any related target work in arch (afaik) because of this bug.

I just switched to systemd and would like to keep using e4rat.

nierro · 2012-07-18 19:31:55

I'm actually using e4rat...i only killed xserver and then realloc...everything is fine (or should i say "seems fine"?)
Btw, i'm using e4rat-lite-git from aur.

Trilby · 2012-07-18 19:36:13

I'll be darned. That worked. Thanks nierro.

nierro · 2012-07-18 19:37:53

Glad it helped you!

Cdh · 2012-07-18 22:03:02

Trilby wrote:

There is no runlevel 1, nor does rescue.target or any related target work in arch (afaik) because of this bug.

It worked fine for me to switch to runlevel 1 / rescue.target from an already running system.

For brevity I ususally just did

sudo telinit 1

which systemd understands and does something with.

bel3atar · 2012-07-19 13:20:59

Hello
I use e4rat and still my boot process is quite slow.
I don't know why the first 5 second the computer is almost idle.
Here's a boot chat if you could figure out why:
DAEMONS=(@dbus !syslog-ng !network !crond @wicd @laptop-mode)
http://img96.imageshack.us/img96/4451/bootcharth.png
Uploaded with ImageShack.us

moderator edit: Welcome to the forums. The image is too large. Please read Forum Etiquette: Pasting Pictures and Code. Thanks. --fsckd

Last edited by fsckd (2012-07-19 18:35:08)

Trilby · 2012-07-19 14:50:32

@Cdh,

I tried that too. The system seems to go down, but immediately comes back up into multiuser target (or equivalent of runlevel 5). This seems to be the gist of that bug. Perhaps it is only affecting some systems - I don't really understand it - but so far I have found no solution that works here.

It is handy to know that such a mode is (apparently) not necessary for the relocate process though.

Thme · 2012-10-18 02:03:20

Trilby wrote:

@Cdh,
It is handy to know that such a mode is (apparently) not necessary for the relocate process though.

I had updated the wiki to add a note on running systemd and just expanded it little for those that may be reading over this thread. And recently both I and and another Archer noticed that we could also switch to rescue mode just fine with

#systemctl rescue

and that when running e4rat-realloc while in this mode there were more inodes/blocks available for reallocation on both of our machines enabling us to reduce the fragmentation counts even further than while in multiuser/graphical.target.
So even though it isn't necessary it may, however, offer a slightly better result if one is able to enter rescue mode properly on a systemd setup before running e4rat-realloc. Doing it from ether mode hasn't caused me any issues so far on a pure systemd setup.

marvn · 2012-10-18 08:53:34

Thme wrote:

Trilby wrote:
@Cdh,
It is handy to know that such a mode is (apparently) not necessary for the relocate process though.
I had updated the wiki to add a note on running systemd and just expanded it little for those that may be reading over this thread. And recently both I and and another Archer noticed that we could also switch to rescue mode just fine with
#systemctl rescue
and that when running e4rat-realloc while in this mode there were more inodes/blocks available for reallocation on both of our machines enabling us to reduce the fragmentation counts even further than while in multiuser/graphical.target.
So even though it isn't necessary it may, however, offer a slightly better result if one is able to enter rescue mode properly on a systemd setup before running e4rat-realloc. Doing it from ether mode hasn't caused me any issues so far on a pure systemd setup.

according to these two man pages:
http://0pointer.de/public/systemd-man/s … pshot.html
http://www.freedesktop.org/software/sys … linit.html

the best way to do realoc with systemd is (IMHO):

$systemctl snapshot      # create snapshot of system state
$systemctl rescue        # init 1 equivalent 
$e4rat-realloc           # obvious
$systemctl isolate       # return to the snapshot state

doesn't test it yet, though...

Last edited by marvn (2012-10-18 08:54:15)

Šaran · 2012-10-18 09:10:45

Realloc in rescue mode shaved more than a second from my boot time. Thanks!

medeshago · 2012-11-08 02:36:44

This is what I'm getting:
$e4rat-collect -k
Cannot read pid from file /dev/.e4rat-collect.pid: No such file or directory

my syslinux.cfg:
MENU LABEL Arch Linux
	LINUX ../vmlinuz-linux
	APPEND root=/dev/sda5 ro init=/sbin/e4rat-collect init=/usr/lib/systemd/systemd
	INITRD ../initramfs-linux.img

And e4rat configuration is the default one.

I'm stupid and didn't read the wiki properly. I'm sorry.

Last edited by medeshago (2012-11-08 06:40:22)

Unia · 2012-11-08 10:59:28

AFAIK you can't have two init= parts in the APPEND line

Trilby · 2012-11-08 11:10:25

Apparently you can have two init parameters in the kernel line - but it looks like, as could be expected, the second one overrides the first. e4rat-collect did not start as PID 1.

This is covered in the e4rat wiki: use e4rat-collect as PID 1 (init in the kernel line) and set systemd to replace it in e4rat's config.

This is only an issue if one has one of those intermediate stages of "hybrid" sysVinit/systemd setup.

Edit: just saw the edit to the post with this question which may indicate that this was solved already. Nonetheless, the above may provide details of the solution to anyone else who faces the same problem.

Last edited by Trilby (2012-11-08 11:11:35)

medeshago · 2012-11-08 14:49:53

Trilby wrote:

Apparently you can have two init parameters in the kernel line - but it looks like, as could be expected, the second one overrides the first. e4rat-collect did not start as PID 1.
This is covered in the e4rat wiki: use e4rat-collect as PID 1 (init in the kernel line) and set systemd to replace it in e4rat's config.
This is only an issue if one has one of those intermediate stages of "hybrid" sysVinit/systemd setup.
Edit: just saw the edit to the post with this question which may indicate that this was solved already. Nonetheless, the above may provide details of the solution to anyone else who faces the same problem.

The solution was covered in the wiki. In this section: "e4rat with different init system, e.g. systemd"

Arch Linux

#251 2012-05-27 21:25:19

Re: e4rat - reduce boot time (into X) by some 50% for ext4

#252 2012-07-02 10:22:01

Re: e4rat - reduce boot time (into X) by some 50% for ext4

#253 2012-07-18 19:09:44

Re: e4rat - reduce boot time (into X) by some 50% for ext4

#254 2012-07-18 19:31:55

Re: e4rat - reduce boot time (into X) by some 50% for ext4

#255 2012-07-18 19:36:13

Re: e4rat - reduce boot time (into X) by some 50% for ext4

#256 2012-07-18 19:37:53

Re: e4rat - reduce boot time (into X) by some 50% for ext4

#257 2012-07-18 22:03:02

Re: e4rat - reduce boot time (into X) by some 50% for ext4

#258 2012-07-19 13:20:59

Re: e4rat - reduce boot time (into X) by some 50% for ext4

#259 2012-07-19 14:50:32

Re: e4rat - reduce boot time (into X) by some 50% for ext4

#260 2012-10-18 02:03:20

Re: e4rat - reduce boot time (into X) by some 50% for ext4

#261 2012-10-18 08:53:34

Re: e4rat - reduce boot time (into X) by some 50% for ext4

#262 2012-10-18 09:10:45

Re: e4rat - reduce boot time (into X) by some 50% for ext4

#263 2012-11-08 02:36:44

Re: e4rat - reduce boot time (into X) by some 50% for ext4

#264 2012-11-08 10:59:28

Re: e4rat - reduce boot time (into X) by some 50% for ext4

#265 2012-11-08 11:10:25

Re: e4rat - reduce boot time (into X) by some 50% for ext4

#266 2012-11-08 14:49:53

Re: e4rat - reduce boot time (into X) by some 50% for ext4

Board footer