i reported a deadlocked mount -o remount,ro process a couple monthes
ago and got no response.
now today i have had a ordinary umount (not remount) go into an
unkillable D state permanently.
the situation is this:
i have limited resources and the only means of backup i have is to
simply rsync the filesystem to matching partitions on a slave disk,
its better then nothing which is the only alternative.
the script mounts the backup partition for the given mountpoint and
then runs rsync to syncronise the two filesystems, then it runs sync,
sleep 10 and them umount of the backup filesystem.
when the umount process locked i ls'ed the mountpoint, it was empty,
the kernel still believed there was a filesystem mounted there
however. since there was no way to unwedge this other then rebooting
that was done, i mounted the backup filesystem again and XFS recovery
was run, but the filesystem was intact (and not empty). xfs_check
reports no problems.
there was absolutly no messages from the kernel or anything unusal in
the logs.
my only uneducated guess is that there is some sort of race condition
in the umount path of XFS (or to be fair the kernel in general, but i
would think such a problem would have been noticed more widly if it
were not xfs specific).
i cannot reproduce this any time i wish so i am afraid it will be
difficult to gather more information for you (i also run powerpcs so
kdb is not an option anyway). I would request perhaps an audit of the
umount path in XFS to see if something might be found.
Linux version 2.4.19 (eb@ash) (gcc version 2.95.4 20011002 (Debian
prerelease)) #2 Tue Aug 13 01:10:37 AKDT 2002
SGI XFS snapshot 2.4.19-2002-08-03_04:15_UTC with ACLs, quota, no debug enabled
$ gcc -v
Reading specs from /usr/lib/gcc-lib/powerpc-linux/2.95.4/specs
gcc version 2.95.4 20011002 (Debian prerelease)
$ ld -v
GNU ld version 2.12.90.0.1 20020307 Debian/GNU Linux
--
Ethan Benson
http://www.alaska.net/~erbenson/
pgpaAmS04CxTt.pgp
Description: PGP signature
|