Kernel 2.6.4 Hang in utime() on swap file

Kernel 2.6.4 Hang in utime() on swap file

[Michael W. Shaffer]

I have a Debian Sarge system running a 2.6 kernel (tested with 2.6.2, 2.6.3,
2.6.4 with the same behavior as described here), and am seeing un-killable
hanging processes with our particular backup product.

When the backup disk agent process is running, one the the last files it
tries to back up is a swap file at the path /swapfile00. The read of the
file appears to work fine, but then it wants to call utime() to reset the
atime/mtime on the file, and at this point the process becomes infinitely
hung, doing nothing, no more output from strace, never terminating.

This only occurs if the swapfile is actively in use when the backup runs. If
I run swapoff to deactivate the swapfile, then the utime() call apparently
completes and the process immediately finishes and exits normally. If the
swapfile is not in use at all, everything works fine.

As a workaround, I am just going to leave this swapfile inactive, since it's
not really used much anyway. I do not observe this behavior on the same
machine running a 2.4.21-xfs kernel.


__________________________________
Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.
http://taxes.yahoo.com/filing.html

Re: Kernel 2.6.4 Hang in utime() on swap file

[Andrew Morton]

"Michael W. Shaffer" <mwshaffer@yahoo.com> wrote:
>
> I have a Debian Sarge system running a 2.6 kernel (tested with 2.6.2, 2.6.3,
> 2.6.4 with the same behavior as described here), and am seeing un-killable
> hanging processes with our particular backup product.
> 
> When the backup disk agent process is running, one the the last files it
> tries to back up is a swap file at the path /swapfile00. The read of the
> file appears to work fine, but then it wants to call utime() to reset the
> atime/mtime on the file, and at this point the process becomes infinitely
> hung, doing nothing, no more output from strace, never terminating.
> 
> This only occurs if the swapfile is actively in use when the backup runs. If
> I run swapoff to deactivate the swapfile, then the utime() call apparently
> completes and the process immediately finishes and exits normally. If the
> swapfile is not in use at all, everything works fine.
> 

ho hum.  We do this to prevent anyone from ftruncate()ing the swapfile
while it is in use.  That can destroy filesystems.  Let me think about it a
bit.

Re: Kernel 2.6.4 Hang in utime() on swap file

[Ingo Oeser]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Saturday 20 March 2004 22:55, Andrew Morton wrote:
> ho hum.  We do this to prevent anyone from ftruncate()ing the swapfile
> while it is in use.  That can destroy filesystems.  Let me think about it a
> bit.

Maybe you can deny to open such files with proxy file ops and proxy
block dev ops.

So you implement all file operations and just give back errors.
This has no speed penalty for the hot path and implements correct error
handling.

Only penalty is code bloat, but this is normal for additional error
handling ;-)


But maybe I'm totally wrong here and this is just another case of
"doctor it hurts...".


Regards

Ingo Oeser

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAXWXhU56oYWuOrkARAtRAAKDjjyxyXbuH1LS+cJjGIduWYvEc7gCg4Cy2
wfjw7RtJtABR0MtvL07UPGw=
=rB7n
-----END PGP SIGNATURE-----

Re: Kernel 2.6.4 Hang in utime() on swap file

[Michael W. Shaffer]

> ho hum.  We do this to prevent anyone from ftruncate()ing the swapfile
> while it is in use. That can destroy filesystems. Let me think about
> it a bit.

If it's a 'feature' and we just need to know to exclude swapfiles
from backups (since they don't need to be backed up anyway), then
that's an acceptable workaround, I just wanted to make sure that
it wasn't buggy behavior.

It is especially baffling because it leaves mysteriously un-killable
processes (not even kill -9 will get them, but I guess you know that
already). I don't know the internals behind this, but is there a non-
hideous way to have utime() return an error in this case rather than
entering this unkillable sleep or whatever? That might be a little
nicer since applications trying to do this would presumably handle
the error and proceed or exit rather than hanging infinitely with no
obvious way to free them.

Thanks for explaining what's going on anyway.


__________________________________
Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.
http://taxes.yahoo.com/filing.html