Hi, I just found out about e4rat and decided to give it a try. I encountered a problem when running e4rat-realloc, in the form on a "no space left on device" error.
The partition I'm trying to optimize is 15Gb in size, with around 900MB free. Should I assume that e4rat needs as much free space as the sum of the sizes of the files listed in the e4rat-collect log?
The error seems to come from a mv command rather than from e4rat itself - when it occurred e4rat had only created a 5MB temp file in the root directory, so the partition was not actually full by any means.
Thanks in advance for any help.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> Should I assume that e4rat needs as much free space as the sum of the sizes of the files listed in the e4rat-collect log?
Yes. That's how it works.
e4rat-realloc is not a defragger as usual. It looks for continues free disk space. The more your disk is fragmented (lack of continues free blocks) the less e4rat-realloc can reduce your boot time.
The current defrag algorithm allocates temporary files on disk. If those files are less defragmented it continues.
In your case the allocation step failed. All temporary files should be removed afterwards.
If I understand you correctly, this does not happen. Congratulations, you have just found a bug.
So do I assume rightly that your defrag-mode is "tld" (-use-tld)?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I might have found a bug, then. There was a single temporary file, in the root directory (/, not /root), named something like e4rat-R5dEg6, and like I said the filesystem was not close to being full (although probably there would be no room to duplicate all the files that e4rat wants to process).
As for the defrag-mode, I invoked e4rat-realloc without parameters - is "tld" the default mode? Do you want me to try something specific to help you find out if there's indeed a bug?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi, I just found out about e4rat and decided to give it a try. I encountered a problem when running e4rat-realloc, in the form on a "no space left on device" error.
The partition I'm trying to optimize is 15Gb in size, with around 900MB free. Should I assume that e4rat needs as much free space as the sum of the sizes of the files listed in the e4rat-collect log?
The error seems to come from a mv command rather than from e4rat itself - when it occurred e4rat had only created a 5MB temp file in the root directory, so the partition was not actually full by any means.
Thanks in advance for any help.
> Should I assume that e4rat needs as much free space as the sum of the sizes of the files listed in the e4rat-collect log?
Yes. That's how it works.
e4rat-realloc is not a defragger as usual. It looks for continues free disk space. The more your disk is fragmented (lack of continues free blocks) the less e4rat-realloc can reduce your boot time.
The current defrag algorithm allocates temporary files on disk. If those files are less defragmented it continues.
In your case the allocation step failed. All temporary files should be removed afterwards.
If I understand you correctly, this does not happen. Congratulations, you have just found a bug.
So do I assume rightly that your defrag-mode is "tld" (-use-tld)?
Thank for your reply and sorry about the delay…
I might have found a bug, then. There was a single temporary file, in the root directory (/, not /root), named something like e4rat-R5dEg6, and like I said the filesystem was not close to being full (although probably there would be no room to duplicate all the files that e4rat wants to process).
As for the defrag-mode, I invoked e4rat-realloc without parameters - is "tld" the default mode? Do you want me to try something specific to help you find out if there's indeed a bug?
Just wanted to make you know that I also encountered this error; I even tried to compile from git but it does the same.