2002-10-18 18:36:05

by Carl-Daniel Hailfinger

[permalink] [raw]
Subject: Re: Forced umount

On Mon, 17 Sep 2001, Alexander Viro wrote:
> > > On Sun, Sep 16, 2001, Alex Stewart wrote:
> > > > Basically, I want a 'kill -KILL' for filesystems.
>
> Look at it that way: we have two actions that need to be done upon umount.
> 1) detach it from the mountpoint(s)
> 2) shut it down
>
> For the latter we need to have no active IO on that fs _and_ nothing
> that could initiate such IO. We can separate #1 and #2, letting fs
> shutdown happen when it's no longer busy. That's what MNT_DETACH
> does.
>
> What you are asking for is different - you want fs-wide revoke().
> That's all nice and dandy, but it's an independent problem and it
> will take a _lot_ of work. Including work in fs drivers. It _is_
> worth doing, but it's 2.5 stuff (along with normal revoke(2)).

Has this been done during 2.5 development or is the patch mentioned below
still the only option? And if it is the only option, what prevents it from
being included in 2.5? (I couldn't find anything about it in the archives.)
http://marc.theaimsgroup.com/?l=linux-kernel&m=103443466225915&w=4

To put it another way: Is there any chance to umount / cleanly if / is local
and /smbserver is a mounted remote SMB filesystem where the network link to
the SMB server just went down? (Without waiting half an hour for a timeout.)

Thanks for your answer

Carl-Daniel


2002-10-18 19:14:34

by Richard B. Johnson

[permalink] [raw]
Subject: Re: Forced umount

On Fri, 18 Oct 2002, Carl-Daniel Hailfinger wrote:
[SNIPPED,,,]
>
> To put it another way: Is there any chance to umount / cleanly if / is local
> and /smbserver is a mounted remote SMB filesystem where the network link to
> the SMB server just went down? (Without waiting half an hour for a timeout.)
>
> Thanks for your answer
>
> Carl-Daniel
>


You don't need to unmount a network drive (or any drive)
from a mount-point on a file-system before you umount that
file-system!

In other words, if I have quark:/tmp mounted on /tmp, I can
umount / without unmounting quark:/tmp.

If the network file-system is r/o or otherwise immune to
incomplete operations, you can shut down your client system
with impunity.


For example:

Script started on Fri Oct 18 15:01:59 2002
# mount quark:/tmp /tmp
# df
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/sdb1 16603376 6434704 9325264 41% /
/dev/sdc1 6356624 1198700 4835020 20% /alt
/dev/sdc3 2253284 1768580 370244 83% /home/users
/dev/sda1 1048272 282768 765504 27% /dos/drive_C
/dev/sda5 1046224 181280 864944 17% /dos/drive_D
quark:/tmp 813598 430482 341082 56% /tmp
# umount /dos/drive_C
# umount /dos/drive_D
# umount /home/users
# umount /alt
# umount /
# df
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/sdb1 16603376 6434704 9325264 41% /
quark:/tmp 813598 430482 341082 56% /tmp
# > /xxx
bash: /xxx: Read-only file system
# > /tmp/xxx
# df
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/sdb1 16603376 6434704 9325264 41% /
quark:/tmp 813598 430482 341082 56% /tmp
# exit
exit

Script done on Fri Oct 18 15:05:39 2002

As you can see, '/' is now read-only, but /tmp is read-write.
It is save to hit the reset button or otherwise halt the CPU
at this time.

If your shutdown scripts or code 'think' you need to unmount
all the mount-points before you unmount '/', they are broken
and need to be fixed.


Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
The US military has given us many words, FUBAR, SNAFU, now ENRON.
Yes, top management were graduates of West Point and Annapolis.