So the question now becomes "how do I find out which processes are
holding a file open on a given filesystem, thus preventing a umount?"
I was under the impression that this was what fuser was for -- apparently
not, since it told me nothing was using the filesystem. The kernel must
know internally that a file is open in order for it to return EBUSY on a
umount(2). I guess this information is available somewhere in /proc. If
so, where? If not, is there an ioctl() or something around which I can
wrap a noddy C program to get the info?
>Actually, it was the act of dropping down to single-user which caused
>the process which was holding the file to exit, which caused the space
>to be reclaimed. If you know what the file is, you can also simply
>restart the process without needing to take the whole machine down to
>single-user mode.
As it happens, I've just found the cause of the problem. I scanned the
process list, completely unable to see any processes that could even
conceivably be using the only file that was on the filesystem. Then
I realised I still had a loopback device associated with that file,
which was preventing the space being freed. Fixed it with:
losetup -d /dev/loop0
Maybe fuser needs updating to take account of this. It's very misleading
when it tells you nothing's using a filesystem, and yet the kernel still
tells you the filesystem's busy when you try to umount it.
Tet
-- ``I am an outcast on the path of no return. Punisher and swordsman, I was born to burn. Black wind always follows where my black horse rides. Fire's in my soul, steel is on my side'' -- "Black wind, fire and steel", Manowar --------------------+--------------+---------------------------------------- tethys@ml.com | Micro$oft: | Linux, the choice of a GNU generation. tet@astradyne.co.uk | Just say no! | See http://www.uk.linux.org for details