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

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.

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

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:

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?

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

@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.

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

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.

"You are like people in a dark room waiting for someone to turn the light on for you instead of groping around in the dark and turning it on for yourself." -J. Krishnamurti at age 19, to his students-www.jkrishnamurti.org

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

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.

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

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.

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

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"