If I kill a running e4defrag, is there a risk of data loss/corruption? Is there a safe way to interrupt it?

For example: running e4defrag on large partition (such as the root directory) or large file (such as a squashfs system image file) is very slow, so sometimes, stopping/killing e4defrag before it is done is needed, but I'm not sure whether killing it (by sending either of SIGINT,SIGTERM,SIGKILL, etc. to it) e4defrag is safe?

I'm running Debian Stretch and the filesystem is ext4.
My kernel version:4.14.13
My e2fsprogs version:1.43.4-2

3 Answers 3


I haven't checked the code itself, but since e4defrag is only working on a single file at a time, it definitely can't corrupt the whole filesystem.

In any case, the actual data movement is done in the kernel in the context of a journal transaction, so it should be immune to whatever you do in userspace. It shouldn't even be able to cause a problem if you reboot in the middle.

  • 1
    I believe you are right :lwn.net/Articles/334531 fotisl.com/blog/2009/12/… so just kill without power lost is safe.
    – illiterate
    Sep 29, 2018 at 12:36
  • Please say whether or not the root user has the power to do something worse to e4defrag than a regular user.
    – agc
    Sep 29, 2018 at 18:27
  • It doesn't matter whether program is killed by regular or root user.
    – LustreOne
    Oct 1, 2018 at 2:45
  • @LustreOne, Sorry, didn't describe it correctly -- I meant as root in general, for example could a root user kill -9 some kernel process that e4defrag was using...
    – agc
    Oct 1, 2018 at 14:56
  • Not even root can kill a kernel process, unless that process is expecting it (i.e. waiting interruptibly for some event), and even then the signal will only be delivered to the process when it returns to userspace.
    – LustreOne
    Oct 3, 2018 at 5:56

Since e4defrag works on a mounted file system, using standard file system calls, killing it would have the same dangers as killing any program that writes to files... and that depends on which signal kill sends to e4defrag.

  • SIGINT should be OK

  • SIGTERM should be OK

  • SIGKILL seems potentially hazardous, and may corrupt a file -- perhaps an important file. Therefore avoid using SIGKILL with e4defrag.


Apparently, the defrag magic is all in a single ioctl() call (per extent):

defraged_ret =
    ioctl(fd, EXT4_IOC_MOVE_EXT, &move_data);

So, it appears that the entire process of defragmentation is done in the kernel. It should be thereof protected by journaling and safe even in case of grid power loss and kill -9.

Only a journal replay on the next reboot should occur in the latter case. Hope this helps.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .