Re: the umount() saga for regular linux desktop users

Re: the umount() saga for regular linux desktop users

[Bodo Eggert]

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)

Re: the umount() saga for regular linux desktop users

[Adrian Bunk]

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

Re: the umount() saga for regular linux desktop users

[Bodo Eggert]

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.

Re: the umount() saga for regular linux desktop users

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 582 bytes --]

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???

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: the umount() saga for regular linux desktop users

[Lee Revell]

On Sun, 2005-01-02 at 17:43 -0500, Valdis.Kletnieks@vt.edu 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

Re: the umount() saga for regular linux desktop users

[Bodo Eggert]

(Aplologies for the indirect reply, I didn't see the cited message yet)

> On Sun, 2005-01-02 at 17:43 -0500, Valdis.Kletnieks@vt.edu 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
$

Re: the umount() saga for regular linux desktop users

[Bodo Eggert]

Adrian Bunk wrote:
> On Sun, Jan 02, 2005 at 09:34:16PM +0100, Oliver Neukum wrote:

>> 3. Is a race condition.
> 
> Then put it into a while loop that executes until umount returns 0.

#!/bin/sh
for ((i=0;i<7;i++))
do while true; do sh -c 'chdir /mnt/cdrom;sleep 2147483647';done&
done

Re: the umount() saga for regular linux desktop users

[Pavel Machek]

Hi!
>X-Original-To: pavel@atrey.karlin.mff.cuni.cz
>From: Andy Lutomirski <luto@myrealbox.com>
>To: Andries Brouwer <aebr@win.tue.nl>
>Cc: linux-kernel@vger.kernel.org
>Subject: Re: the umount() saga for regular linux desktop users
>
>Andries Brouwer wrote:
>>On Fri, Dec 31, 2004 at 05:41:02PM +0000, William wrote:
>>
>>
>>>Regularly, when attempting to umount() a filesystem I receive 
>>>'device is busy' errors. The only way (that I have found) to solve 
>>>these problems is to go on a journey into processland and kill all 
>>>the guilty ones that have tied themselves to the filesystem 
>>>concerned.
>>
>>
>>Do you know about the existence of the MNT_DETACH flag of umount(2),
>>or the -l option of umount(8)?
>>
>>It seems that does at least some of the things you are asking for.

Well, umount -l can be handy, but it does not allow you to get your CD
back from the drive.

umount --kill that kills whoever is responsible for filesystem being
busy would solve part of the problem (that can be done in userspace,
today).

Of course, even nicer would be "filesystem goes away now, all
operations fail", but that needs kernel support.

>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_.

Agreed. When some machine refuses to eject cd because it is
busy... That's bad. I have strong temptation to just remove AC power,
plug it back and then claim my CD...

								Pavel

-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: the umount() saga for regular linux desktop users

[Adrian Bunk]

On Sun, Jan 02, 2005 at 08:37:24PM +0100, Pavel Machek wrote:

> Well, umount -l can be handy, but it does not allow you to get your CD
> back from the drive.
> 
> umount --kill that kills whoever is responsible for filesystem being
> busy would solve part of the problem (that can be done in userspace,
> today).
>...

What's wrong with

  fuser -k /mnt && umount /mnt

?


> 								Pavel

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

Re: the umount() saga for regular linux desktop users

[Pavel Machek]

Hi!

> > Well, umount -l can be handy, but it does not allow you to get your CD
> > back from the drive.
> > 
> > umount --kill that kills whoever is responsible for filesystem being
> > busy would solve part of the problem (that can be done in userspace,
> > today).
> >...
> 
> What's wrong with
> 
>   fuser -k /mnt && umount /mnt

Okay, probably nothing (I knew about fuser, but did not know about -k
option...). fuser followed by ps and kill is not nice.

[Perhaps umount could tell user about fuser -k ?]
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: the umount() saga for regular linux desktop users

[Oliver Neukum]

Am Sonntag, 2. Januar 2005 21:11 schrieb Adrian Bunk:
> On Sun, Jan 02, 2005 at 08:37:24PM +0100, Pavel Machek wrote:
> 
> > Well, umount -l can be handy, but it does not allow you to get your CD
> > back from the drive.
> > 
> > umount --kill that kills whoever is responsible for filesystem being
> > busy would solve part of the problem (that can be done in userspace,
> > today).
> >...
> 
> What's wrong with
> 
>   fuser -k /mnt && umount /mnt

1. Would need suid.
2. Is a mindless slaughter of important processes.
3. Is a race condition.

	Regards
			Oliver

Re: the umount() saga for regular linux desktop users

[Adrian Bunk]

On Sun, Jan 02, 2005 at 09:34:16PM +0100, Oliver Neukum wrote:
> Am Sonntag, 2. Januar 2005 21:11 schrieb Adrian Bunk:
> > On Sun, Jan 02, 2005 at 08:37:24PM +0100, Pavel Machek wrote:
> > 
> > > Well, umount -l can be handy, but it does not allow you to get your CD
> > > back from the drive.
> > > 
> > > umount --kill that kills whoever is responsible for filesystem being
> > > busy would solve part of the problem (that can be done in userspace,
> > > today).
> > >...
> > 
> > What's wrong with
> > 
> >   fuser -k /mnt && umount /mnt
> 
> 1. Would need suid.

It needs suid only if you aren't root and you want to kill processes you 
don't own.

Yes, this might cause problems e.g. if users are allowed to mount their 
cdroms, but simply allowing them to kill processes of other users who 
access this device isn't a solution, too.

> 2. Is a mindless slaughter of important processes.

It's what Pavel wanted to get included in umount.

Usually, you'll let fuser give you the list of processes and inspect 
them manually.

> 3. Is a race condition.

Then put it into a while loop that executes until umount returns 0.

I still fail to see why I should implement half of fuser in umount. 
Either you are working at the command line and know about fuser or you 
are working through a GUI which can offer you a "kill all applications 
accessing this device" button that calls fuser.

> 	Regards
> 			Oliver

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

Re: the umount() saga for regular linux desktop users

[Pavel Machek]

Hi!
> > > > Well, umount -l can be handy, but it does not allow you to get your CD
> > > > back from the drive.
> > > > 
> > > > umount --kill that kills whoever is responsible for filesystem being
> > > > busy would solve part of the problem (that can be done in userspace,
> > > > today).
> > > >...
> > > 
> > > What's wrong with
> > > 
> > >   fuser -k /mnt && umount /mnt
> > 
> > 1. Would need suid.
> 
> It needs suid only if you aren't root and you want to kill processes you 
> don't own.
> 
> Yes, this might cause problems e.g. if users are allowed to mount their 
> cdroms, but simply allowing them to kill processes of other users who 
> access this device isn't a solution, too.
> 
> > 2. Is a mindless slaughter of important processes.
> 
> It's what Pavel wanted to get included in umount.
> 
> Usually, you'll let fuser give you the list of processes and inspect 
> them manually.
> 
> > 3. Is a race condition.
> 
> Then put it into a while loop that executes until umount returns 0.
> 
> I still fail to see why I should implement half of fuser in umount. 
> Either you are working at the command line and know about fuser or you 
> are working through a GUI which can offer you a "kill all applications 
> accessing this device" button that calls fuser.

Okay, so the right solution is probably something more like

while umount /mnt; do
	fuser -km -TERM /mnt
	sleep 1
	fuser -km /mnt
done

Not sure how many command line users can do this... Perhaps including
fumount script doing this is good idea?
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: the umount() saga for regular linux desktop users

[Adrian Bunk]

On Sun, Jan 02, 2005 at 09:56:50PM +0100, Pavel Machek wrote:
> 
> Okay, so the right solution is probably something more like
> 
> while umount /mnt; do
> 	fuser -km -TERM /mnt
> 	sleep 1
> 	fuser -km /mnt
> done
> 
> Not sure how many command line users can do this... Perhaps including
> fumount script doing this is good idea?

A command line user only needs to know about fuser, and in the unlikely 
case if the race condition Oliver thought of occurs he'll note since 
umount will give an error message.

I'd even say the more common case is to use fuser to get the PIDs of the 
processes and manually check which they are - e.g. you might not want to 
kill your OpenOffice with many open documents only because you'd 
forgotten that it still has one document open on the file system you are 
trying to remove.

> 								Pavel

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

Re: the umount() saga for regular linux desktop users

[Frank van Maarseveen]

On Sun, Jan 02, 2005 at 10:05:36PM +0100, Adrian Bunk wrote:
> On Sun, Jan 02, 2005 at 09:56:50PM +0100, Pavel Machek wrote:
> > 
> > Okay, so the right solution is probably something more like
> > 
> > while umount /mnt; do
> > 	fuser -km -TERM /mnt
> > 	sleep 1
> > 	fuser -km /mnt
> > done
> 
> A command line user only needs to know about fuser, and in the unlikely 
> case if the race condition Oliver thought of occurs he'll note since 
> umount will give an error message.

There's a much more interesting race: another process succesfully umounting
the thing while this one's asleep.

-- 
Frank

Re: the umount() saga for regular linux desktop users

[Ingo Oeser]

Frank van Maarseveen schrieb:
> On Sun, Jan 02, 2005 at 10:05:36PM +0100, Adrian Bunk wrote:
> > On Sun, Jan 02, 2005 at 09:56:50PM +0100, Pavel Machek wrote:
> > > Okay, so the right solution is probably something more like
> > >
> > > while umount /mnt; do
> > >  fuser -km -TERM /mnt
> > >  sleep 1
> > >  fuser -km /mnt
> > > done
> There's a much more interesting race: another process succesfully umounting
> the thing while this one's asleep.

For those who don't know what happens: fuser -km /mnt will act like
fuser -km / in that race and kill all processes.

BTDT :-(

Re: the umount() saga for regular linux desktop users

[Adrian Bunk]

On Sun, Jan 02, 2005 at 09:11:47PM +0100, Adrian Bunk wrote:
> On Sun, Jan 02, 2005 at 08:37:24PM +0100, Pavel Machek wrote:
> 
> > Well, umount -l can be handy, but it does not allow you to get your CD
> > back from the drive.
> > 
> > umount --kill that kills whoever is responsible for filesystem being
> > busy would solve part of the problem (that can be done in userspace,
> > today).
> >...
> 
> What's wrong with
> 
>   fuser -k /mnt && umount /mnt
>...

I meant

  fuser -km /mnt && umount /mnt

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

Re: the umount() saga for regular linux desktop users

[Puneet Vyas]

Adrian Bunk wrote:

>On Sun, Jan 02, 2005 at 09:11:47PM +0100, Adrian Bunk wrote:
>  
>
>>On Sun, Jan 02, 2005 at 08:37:24PM +0100, Pavel Machek wrote:
>>
>>    
>>
>>>Well, umount -l can be handy, but it does not allow you to get your CD
>>>back from the drive.
>>>
>>>umount --kill that kills whoever is responsible for filesystem being
>>>busy would solve part of the problem (that can be done in userspace,
>>>today).
>>>...
>>>      
>>>
>>What's wrong with
>>
>>  fuser -k /mnt && umount /mnt
>>...
>>    
>>
>
>I meant
>
>  fuser -km /mnt && umount /mnt
>
>cu
>Adrian
>
>  
>
I'm as newbie as they get but the above command just made my system 
freeze hard and I could do nothing but reboot (use the power switch). I 
had nothing mounted there but have a directory
under /mnt where I occasionaly mount my samba share. (which was not 
mounted when I tried this) . So much for user friendlyness ... oh well ...

~puneet

Re: the umount() saga for regular linux desktop users

[Andreas Schwab]

Adrian Bunk <bunk@stusta.de> writes:

> What's wrong with
>
>   fuser -k /mnt && umount /mnt

Better: fuser -km /mnt

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

the umount() saga for regular linux desktop users

[William]

Hi

I am a linux desktop user. I love linux and all the wonderfull 
open-source/free software that comes with it... blah, blah, blah :). The 
following comments and suggestions about umount() stem from personal 
experience and are meant as friendly feedback for all you clever people. (I 
wish I understook how the kernel works)

Regularly, when attempting to umount() a filesystem I receive 'device is busy' 
errors. The only way (that I have found) to solve these problems is to go on 
a journey into processland and kill all the guilty ones that have tied 
themselves to the filesystem concerned.

In order to help solve this problem is it possible to modify the behaviour of 
the linux kernel.

In my opinion, in order for linux to be trully user friendly, "a umount() 
should NEVER fail" (even if the device containing the filesystem is no 
longuer attached to the system). The kernel should do it's best to satisfy 
the umount request and cleanup. Maybe the kernel could try some of the 
following:

1) if the device containing the filesystem (for local filesystems) is no 
longer physicaly attached to the system: revoke all process access to the 
filesystem and umount. Notify umount that the filesystem was not cleanly 
umounted.

2) notify all processes attached to the filesystem that they must release 
control of it.

3) the processes may respond to the notifications and request time to clean up 
in order to read/write any remaining data.

4) processes that do not respond within a given time-frame should have their 
filesystem access revoked.

5) once all the clean up has finnished...  umount the filesystem.....

I am not subscribed to the list so please email me on wh@designed4u.net

Kind Regards
      William Heyland

the new "a umount() should NEVER fail" campaign launched by me on december the 
31 of 2004.  Just in time for new year ;-)

PS:  I am currently teaching myself about kernels in general and am hoping to 
start contributing to linux soon. But until then... if the kernel can't 
handle a umount() then nothing in userspace can do any better... rant, rant, 
rant, ...  make umount() smarter.... Please?

Re: the umount() saga for regular linux desktop users

[Arjan van de Ven]

On Fri, 2004-12-31 at 17:41 +0000, William wrote:
> Hi
> 
> I am a linux desktop user. I love linux and all the wonderfull 
> open-source/free software that comes with it... blah, blah, blah :). The 
> following comments and suggestions about umount() stem from personal 
> experience and are meant as friendly feedback for all you clever people. (I 
> wish I understook how the kernel works)
> 
> Regularly, when attempting to umount() a filesystem I receive 'device is busy' 
> errors. The only way (that I have found) to solve these problems is to go on 
> a journey into processland and kill all the guilty ones that have tied 
> themselves to the filesystem concerned.
> 
> In order to help solve this problem is it possible to modify the behaviour of 
> the linux kernel.


what you describe is almost like lazy umounting.. which I think comes
quite close...

Re: the umount() saga for regular linux desktop users

[Ush]

On Fri, 31 Dec 2004 17:41:02 +0000, William <wh@designed4u.net> wrote:
 
> Regularly, when attempting to umount() a filesystem I receive 'device is busy'
> errors. The only way (that I have found) to solve these problems is to go on
> a journey into processland and kill all the guilty ones that have tied
> themselves to the filesystem concerned.

Even a lazy umount doesn't work?  "umount -l <filesystem-name>"

> In my opinion, in order for linux to be trully user friendly, "a umount()
> should NEVER fail" (even if the device containing the filesystem is no
> longuer attached to the system). The kernel should do it's best to satisfy
> the umount request and cleanup. Maybe the kernel could try some of the
> following:

Would it be user-friendly if this forcible umount caused the user to lose data?

Oisin

Re: the umount() saga for regular linux desktop users

[Gene Heskett]

On Friday 31 December 2004 12:48, Ush wrote:
>On Fri, 31 Dec 2004 17:41:02 +0000, William <wh@designed4u.net> 
wrote:
>> Regularly, when attempting to umount() a filesystem I receive
>> 'device is busy' errors. The only way (that I have found) to solve
>> these problems is to go on a journey into processland and kill all
>> the guilty ones that have tied themselves to the filesystem
>> concerned.
>
>Even a lazy umount doesn't work?  "umount -l <filesystem-name>"
>
>> In my opinion, in order for linux to be trully user friendly, "a
>> umount() should NEVER fail" (even if the device containing the
>> filesystem is no longuer attached to the system). The kernel
>> should do it's best to satisfy the umount request and cleanup.
>> Maybe the kernel could try some of the following:
>
>Would it be user-friendly if this forcible umount caused the user to
> lose data?

No, it wouldn't be user friendly, but it would sure be user 
educational when he asked why his resume dissappeared.

Let me toss this out for discussion.

There are some times when the usual 5 second flush schedule should be 
tossed out the window, and the data written immediately.  A quickly 
unpluggable usb memory dongle is a prime candidate to bite the user 
precisely where it hurts.  Floppies also fit this same scenario, I 
don't know at the times I've written an image with dd, got up out of 
my chair and went to the machine and slapped the eject button to 
discover to my horror, that when my hand came away from the button 
with disk in hand, the frigging access led was now on that wasn't 
when I tapped the button.

Usually just re-inserting the disk allows the write to continue and 
nothing is lost.  But I've learned to do a couple of sync's and the 
umount before pulling the disk.  But theres a whole lot more protocol 
to doing that with a usb device.

Thats one of the things that could be done to improve the user 
friendliness of linux.  Really Old Hands are used to those limits, 
but newbies just coming in from the dark side are not impressed when 
its something like that as nearly their first exposure to linux.

>Oisin
>-
>To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.31% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.

Re: the umount() saga for regular linux desktop users

[Miquel van Smoorenburg]

In article <200412311322.14359.gene.heskett@verizon.net>,
Gene Heskett  <gene.heskett@verizon.net> wrote:
>Let me toss this out for discussion.
>
>There are some times when the usual 5 second flush schedule should be 
>tossed out the window, and the data written immediately.  A quickly 
>unpluggable usb memory dongle is a prime candidate to bite the user 
>precisely where it hurts.  Floppies also fit this same scenario, I 
>don't know at the times I've written an image with dd, got up out of 
>my chair and went to the machine and slapped the eject button to 
>discover to my horror, that when my hand came away from the button 
>with disk in hand, the frigging access led was now on that wasn't 
>when I tapped the button.

Google for "supermount".

Mike.

Re: the umount() saga for regular linux desktop users

[Tom Felker]

On Friday 31 December 2004 12:22 pm, Gene Heskett wrote:

> There are some times when the usual 5 second flush schedule should be
> tossed out the window, and the data written immediately.  A quickly
> unpluggable usb memory dongle is a prime candidate to bite the user
> precisely where it hurts.  Floppies also fit this same scenario, I
> don't know at the times I've written an image with dd, got up out of
> my chair and went to the machine and slapped the eject button to
> discover to my horror, that when my hand came away from the button
> with disk in hand, the frigging access led was now on that wasn't
> when I tapped the button.

For that you should add "sync" as an option when mounting the filesystem, in 
which case writes won't return until the data has actually been written.  man 
mount doesn't mention that being implemented for FAT, though - is that 
accurate, and if so, shouldn't it be?

-- 
Tom Felker, <tcfelker@mtco.com>
<http://vlevel.sourceforge.net> - Stop fiddling with the volume knob.

McBride: "I have here in my hand a list of two hundred and five..."

Re: the umount() saga for regular linux desktop users

[Gene Heskett]

On Friday 31 December 2004 16:48, Tom Felker wrote:
>On Friday 31 December 2004 12:22 pm, Gene Heskett wrote:
>> There are some times when the usual 5 second flush schedule should
>> be tossed out the window, and the data written immediately.  A
>> quickly unpluggable usb memory dongle is a prime candidate to bite
>> the user precisely where it hurts.  Floppies also fit this same
>> scenario, I don't know at the times I've written an image with dd,
>> got up out of my chair and went to the machine and slapped the
>> eject button to discover to my horror, that when my hand came away
>> from the button with disk in hand, the frigging access led was now
>> on that wasn't when I tapped the button.
>
>For that you should add "sync" as an option when mounting the
> filesystem, in which case writes won't return until the data has
> actually been written.  man mount doesn't mention that being
> implemented for FAT, though - is that accurate, and if so,
> shouldn't it be?

Don't know about vfat, which is how I mount a floppy, but I just put 
that in the options list in /etc/fstab & will test it the next time I 
need to sneakernet something small around here.  Many thanks for what 
might be a valuable bit of info!

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.31% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.

Re: the umount() saga for regular linux desktop users

[Andries Brouwer]

On Fri, Dec 31, 2004 at 05:41:02PM +0000, William wrote:

> Regularly, when attempting to umount() a filesystem I receive 'device is busy' 
> errors. The only way (that I have found) to solve these problems is to go on 
> a journey into processland and kill all the guilty ones that have tied 
> themselves to the filesystem concerned.

Do you know about the existence of the MNT_DETACH flag of umount(2),
or the -l option of umount(8)?

It seems that does at least some of the things you are asking for.

Andries

Re: the umount() saga for regular linux desktop users

[Andy Lutomirski]

Andries Brouwer wrote:
> On Fri, Dec 31, 2004 at 05:41:02PM +0000, William wrote:
> 
> 
>>Regularly, when attempting to umount() a filesystem I receive 'device is busy' 
>>errors. The only way (that I have found) to solve these problems is to go on 
>>a journey into processland and kill all the guilty ones that have tied 
>>themselves to the filesystem concerned.
> 
> 
> Do you know about the existence of the MNT_DETACH flag of umount(2),
> or the -l option of umount(8)?
> 
> It seems that does at least some of the things you are asking for.


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_.

<rant>
I think part of the nastiness is that mount now means too things:
1) Read the superblock, fire up the fs, etc.
2) Shove the thing into the namespace.

The fact that the current mount/umount interface papers over the 
distinction is at least confusing.  It made sense before there were bind 
mounts.  Now, for example, mount /dev/hda2 /mnt/whatever does something 
_different_ depending on whether hda2 is already mounted.  And the mount 
options will be silently ignored sometimes.  Then, I can MNT_DETACH 
something to separate it from the namespace, but I can't force it to 
actually shut down the fs.  There is no interface for it.

Shouldn't these be separate syscalls with separate parameters?  For 
example, ro applied to the fs should mean "don't touch the device" and 
ro applied to the view in the namespace should mean "don't write to this 
view."
</rant>

Re: the umount() saga for regular linux desktop users

[Gene Heskett]

On Friday 31 December 2004 12:41, William wrote:
>Hi
>
>I am a linux desktop user. I love linux and all the wonderfull
>open-source/free software that comes with it... blah, blah, blah :).
> The following comments and suggestions about umount() stem from
> personal experience and are meant as friendly feedback for all you
> clever people. (I wish I understook how the kernel works)
>
>Regularly, when attempting to umount() a filesystem I receive
> 'device is busy' errors. The only way (that I have found) to solve
> these problems is to go on a journey into processland and kill all
> the guilty ones that have tied themselves to the filesystem
> concerned.
>
If you are running kernel.org kernels, the fix is to update to at 
least 2.6.10-ac1, where much of this malarkey, particularly with 
regard to samba, has been attended to.

>In order to help solve this problem is it possible to modify the
> behaviour of the linux kernel.
>
>In my opinion, in order for linux to be trully user friendly, "a
> umount() should NEVER fail" (even if the device containing the
> filesystem is no longuer attached to the system). The kernel should
> do it's best to satisfy the umount request and cleanup. Maybe the
> kernel could try some of the following:
>
>1) if the device containing the filesystem (for local filesystems)
> is no longer physicaly attached to the system: revoke all process
> access to the filesystem and umount. Notify umount that the
> filesystem was not cleanly umounted.
>
>2) notify all processes attached to the filesystem that they must
> release control of it.
>
>3) the processes may respond to the notifications and request time
> to clean up in order to read/write any remaining data.
>
>4) processes that do not respond within a given time-frame should
> have their filesystem access revoked.
>
>5) once all the clean up has finnished...  umount the
> filesystem.....
>
>I am not subscribed to the list so please email me on
> wh@designed4u.net
>
>Kind Regards
>      William Heyland
>
>the new "a umount() should NEVER fail" campaign launched by me on
> december the 31 of 2004.  Just in time for new year ;-)
>
>PS:  I am currently teaching myself about kernels in general and am
> hoping to start contributing to linux soon. But until then... if
> the kernel can't handle a umount() then nothing in userspace can do
> any better... rant, rant, rant, ...  make umount() smarter....
> Please?
>-
>To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.31% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.

Re: the umount() saga for regular linux desktop users

[Greg Stark]

William <wh@designed4u.net> writes:

> In my opinion, in order for linux to be trully user friendly, "a umount() 
> should NEVER fail" (even if the device containing the filesystem is no 
> longuer attached to the system). The kernel should do it's best to satisfy 
> the umount request and cleanup. Maybe the kernel could try some of the 
> following:

What you're asking for is for the umount -f option to be supported. This isn't
a new fangled idea. BSD supported has supported it since sometime in the last
millennium. Seriously, it's pretty basic functionality and really ought to be
supported.

The semantics of umount -f are simpler than you make it sound. It just
unmounts the file system normally and revokes any file descriptors for that
file system. Any further i/o on those file descriptors just gets an error
(EINVAL I expect). 

This is one of my biggest pet peeves about Linux.

-- 
greg