Le 25/04/2019 à 01:17, Didier Kryn a écrit :
Le 24/04/2019 à 20:43, Steve Litt a écrit :
On Wed, 24 Apr 2019 09:05:12 +0200
Didier Kryn <k...@in2p3.fr> wrote:
Le 24/04/2019 à 01:05, Evilham via Dng a écrit :
Am 24. April 2019 00:24:56 MESZ schrieb Steve Litt
3. Document the misbehaviour when users... Misbehave (okay, that
was a bad joke).
There's an infinite number of ways a human can misbehave. For
brutal extraction of the media, I don't think it is easy to
characterize.
There's a way. There can be a "superumount" that acquires a root
password and keeps doing umount until it's really unmounted on all
lists like mtab.
Here is what happens when a mounted filesystem is physically
removed while mounted :
It is still listed as a mountpoint in /proc/self/mountinfo,
although the device-file of the partition has been removed.
At this point, if the mountpoint is not in use in any process,
pumount unmounts it without error and deletes the mountpoint, but it
must be done from the command line because hopman doesn't show the
partition anymore. If pumount reports an error it is because some
process is using this mountpoint, eg a terminal-emulator or a file-manager.
Suppose the device-file of the partition was sdb1. If you re-insert
the device, it will be named sdc1, because the kernel still has sdb1
mounted.
If one wants to perform cleanup, meaning unmounting automatically
the partitions which have been removed, this can be done by a daemon
watching /dev. But a policy should be defined about the processes using
the mountpoints. Some of these processes may have chances to get IO
errors, but some don't perform any IO to their current working
directory. Should they be all killed ? What is going to happen to them
if umount() is invoked with the MNT_FORCE flag? That's kind of pulling
the carpet under their feet.
Didier
Didier
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
