Andy Lutomirski wrote:
> I have this complaint too, and MNT_DETACH doesn't really do it.
> Sometimes I want to "unmount cleanly, damnit, and I don't care if
> applications that are currently accessing it lose data." Windows can do
> this, and it's _useful_.
I have an additional feature request: The umount -l will currently not work
for unmounting the cwd of something like the midnight commander without
closing it. On the other hand, rmdiring the cwd of running application
works just fine.
Maybe it's possible to extend the semantics of umount -l to change all
cwds under that mountpoint to be deleted directories which will no
longer cause the mountpoint to be busy (e.g. by redirecting them to a
special inode on initramfs). Most applications can cope with that (if
not, they're buggy), and it will do 90% of the usural cases while still
avoiding data loss.
Pseudocode:
on boot:
mkdir("/deleteddirectory");
deleted_dir_fd=open("/deleteddirectory");
rmdir("/deleteddirectory");
on umount -l:
if mountpoints - mountpoints_in_lazy_unmount_state == 0
then for each process
do if process->cwd->device == umount_device
then process->fchdir(deleted_dir_fd)
On Sun, Jan 02, 2005 at 01:38:29PM +0100, Bodo Eggert wrote:
> Andy Lutomirski wrote:
>
> > I have this complaint too, and MNT_DETACH doesn't really do it.
> > Sometimes I want to "unmount cleanly, damnit, and I don't care if
> > applications that are currently accessing it lose data." Windows can do
> > this, and it's _useful_.
>
> I have an additional feature request: The umount -l will currently not work
> for unmounting the cwd of something like the midnight commander without
> closing it. On the other hand, rmdiring the cwd of running application
> works just fine.
A rm does not actually remove things that are still accessed.
As an example, do the following (1 and 2 are shells, cdimage is a full
CD image):
1> less cdimage
2> df .
2> rm cdimage
2> df .
1> q (quit less)
2> df .
> Maybe it's possible to extend the semantics of umount -l to change all
> cwds under that mountpoint to be deleted directories which will no
> longer cause the mountpoint to be busy (e.g. by redirecting them to a
> special inode on initramfs). Most applications can cope with that (if
> not, they're buggy), and it will do 90% of the usural cases while still
> avoiding data loss.
>...
If the appication of a user was writing some important output to a file
on the NFS mount you want to umount there will be data loss...
If you _really_ want to umount something still accessed by applications
simply kill all applications with "fuser -k".
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Sun, 02 Jan 2005 13:38:29 +0100, Bodo Eggert said:
> Maybe it's possible to extend the semantics of umount -l to change all
> cwds under that mountpoint to be deleted directories which will no
> longer cause the mountpoint to be busy (e.g. by redirecting them to a
> special inode on initramfs). Most applications can cope with that (if
> not, they're buggy),
You mean that a program is *buggy* if it does:
cwd("/home/user");
/* do some stuff while we get our cwd ripped out from under us */
file = open("./.mycconfrc");
and expects the file to be opened in /home/user???
On Sun, 2 Jan 2005, Adrian Bunk wrote:
> On Sun, Jan 02, 2005 at 01:38:29PM +0100, Bodo Eggert wrote:
> > I have an additional feature request: The umount -l will currently not work
> > for unmounting the cwd of something like the midnight commander without
> > closing it. On the other hand, rmdiring the cwd of running application
> > works just fine.
>
> A rm does not actually remove things that are still accessed.
ACK, but rmdir will leave the applications in a directory with no way in
or out. This directory can as well be on the moon, so there is no need to
keep the fs busy.
> > Maybe it's possible to extend the semantics of umount -l to change all
> > cwds under that mountpoint to be deleted directories which will no
> > longer cause the mountpoint to be busy (e.g. by redirecting them to a
> > special inode on initramfs). Most applications can cope with that (if
> > not, they're buggy), and it will do 90% of the usural cases while still
> > avoiding data loss.
> >...
>
> If the appication of a user was writing some important output to a file
> on the NFS mount you want to umount there will be data loss...
If the file is open, the modified version will wait for the file to be
closed. If the nfs daemon has closed the file handle, you can unmount with
or without the modification, and with always the same data loss.
> If you _really_ want to umount something still accessed by applications
> simply kill all applications with "fuser -k".
*This* will give you guaranteed data loss on more than the mounted fs.
Murphy will make some long-running jobs depend on the screen session that
was originally started from the mounted dir. Off cause screen doesn't
chdir to "/" after starting the shell.
On Sun, 2005-01-02 at 17:43 -0500, [email protected] wrote:
> On Sun, 02 Jan 2005 13:38:29 +0100, Bodo Eggert said:
>
> > Maybe it's possible to extend the semantics of umount -l to change all
> > cwds under that mountpoint to be deleted directories which will no
> > longer cause the mountpoint to be busy (e.g. by redirecting them to a
> > special inode on initramfs). Most applications can cope with that (if
> > not, they're buggy),
>
> You mean that a program is *buggy* if it does:
>
> cwd("/home/user");
> /* do some stuff while we get our cwd ripped out from under us */
> file = open("./.mycconfrc");
>
> and expects the file to be opened in /home/user???
Yes, of course. Any program that doesn't check the return value of a
system call is buggy. Unless it really, really doesn't care - clearly
not the case here.
Lee
(Aplologies for the indirect reply, I didn't see the cited message yet)
> On Sun, 2005-01-02 at 17:43 -0500, [email protected] wrote:
> > On Sun, 02 Jan 2005 13:38:29 +0100, Bodo Eggert said:
> >
> > > Maybe it's possible to extend the semantics of umount -l to change all
> > > cwds under that mountpoint to be deleted directories which will no
> > > longer cause the mountpoint to be busy (e.g. by redirecting them to a
> > > special inode on initramfs). Most applications can cope with that (if
> > > not, they're buggy),
> >
> > You mean that a program is *buggy* if it does:
> >
> > cwd("/home/user");
> > /* do some stuff while we get our cwd ripped out from under us */
> > file = open("./.mycconfrc");
> >
> > and expects the file to be opened in /home/user???
If the user was bad, the user directory *will* just vanish ("what was your
login, please"), and any other directory may vanish, too:
$ mkdir /tmp/test;cd /tmp/test
$ ls -la
total 0
drwx------ 2 7eggert users 40 2005-01-05 03:00 .
drwx------ 3 7eggert users 60 2005-01-05 03:00 ..
$ # /tmp/test gets removed here
$ ls -la
total 0
$ echo foo>bar
-bash: bar: No such file or directory
$