6

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

illiterate
  • 953
  • 7
  • 22

3 Answers3

6

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.

LustreOne
  • 1,555
  • 5
  • 19
  • 1
    I believe you are right :https://lwn.net/Articles/334531/ https://fotisl.com/blog/2009/12/ext4-online-defrag-and-how-you-can-mess-up-everything-when-implementing-it/ so just kill without power lost is safe. – illiterate Sep 29 '18 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 '18 at 18:27
  • It doesn't matter whether program is killed by regular or root user. – LustreOne Oct 01 '18 at 02: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 01 '18 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 03 '18 at 05:56
5

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.

agc
  • 7,045
  • 3
  • 23
  • 53
  • 1
    The 3rd bullet point might be overcautious, [*LustreOne*'s answer argues even `kill -9` is safe.](https://unix.stackexchange.com/a/472207/165517) – agc Oct 01 '18 at 15:00
0

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

/* EXT4_IOC_MOVE_EXT */
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.

mt42
  • 133
  • 2
  • 6