forced umount?

forced umount?

[Mike Snitzer]

I'm interested in understanding the state of Linux with regard to
_really_ forcing a filesystem to unmount.

There is a (stale) project at OSDL that has various implementations:
http://developer.osdl.org/dev/fumount/

Its fairly clear that these efforts (e.g. badfs patches) haven't been
given serious consideration for upstream inclusion.  Do others see
value in the ability to _reliably_ force a umount by having Linux
discard all IOs, open files, dirty inode buffers, etc of a "bad"
blockdevice?  The goal is to not impact the availability or integrity
of Linux while doing so.

Is this forced umount work even considered worthwhile by the greater
Linux community?  Is anyone actively working on this?

Mike

Re: forced umount?

[Jeremy Fitzhardinge]

Mike Snitzer wrote:
> Is this forced umount work even considered worthwhile by the greater
> Linux community?  Is anyone actively working on this?

Have a look at all the discussion about revoke/frevoke on lkml over the
last week or two.

    J

Re: forced umount?

[Mike Snitzer]

On 3/16/07, Jeremy Fitzhardinge <jeremy@goop.org> wrote:
> Mike Snitzer wrote:
> > Is this forced umount work even considered worthwhile by the greater
> > Linux community?  Is anyone actively working on this?
>
> Have a look at all the discussion about revoke/frevoke on lkml over the
> last week or two.

Thanks for the heads up; its good to see that Pekka Enberg's work has
continued.  I actually stumbled onto that line of work earlier while
searching for more info on Tigran Aivazian's forced unmount (badfs)
patches:
http://lwn.net/Articles/192632/

Mike

Re: forced umount?

[Pekka Enberg]

On 3/17/07, Mike Snitzer <snitzer@gmail.com> wrote:
> Thanks for the heads up; its good to see that Pekka Enberg's work has
> continued.  I actually stumbled onto that line of work earlier while
> searching for more info on Tigran Aivazian's forced unmount (badfs)
> patches:
> http://lwn.net/Articles/192632/

FYI, the revoke implementation have since been changed to follow the
badfs-style approach of the forced unmount patches. However, there are
some problems with the forced unmount patches that are now fixed in
the revoke implementation:

  - You can't use munmap() to take down shared memory mappings because the
    application can accidentally remap something completely different
to that region.
  - The ->f_light bits slow down other fget_light() users and  there's
a race between
    fcheck_files() and set_f_light().
  - The operation can live-lock if a malicious process keeps forking. The revoke
    implementation solves this by revoking in two passes: (1) take
down the descriptors
    and (2) take down the actual inodes.

                           Pekka

Re: forced umount?

[Phillip Susi]

Is this revoke system supported for the filesystem as a whole?  I 
thought it was just to force specific files closed, not the whole 
filesystem.  What if the filesystem itself has pending IO to say, update 
inodes or block bitmaps?  Can these be aborted?

Pekka Enberg wrote:
> FYI, the revoke implementation have since been changed to follow the
> badfs-style approach of the forced unmount patches. However, there are
> some problems with the forced unmount patches that are now fixed in
> the revoke implementation:
> 
>  - You can't use munmap() to take down shared memory mappings because the
>    application can accidentally remap something completely different
> to that region.
>  - The ->f_light bits slow down other fget_light() users and  there's
> a race between
>    fcheck_files() and set_f_light().
>  - The operation can live-lock if a malicious process keeps forking. The 
> revoke
>    implementation solves this by revoking in two passes: (1) take
> down the descriptors
>    and (2) take down the actual inodes.
> 
>                           Pekka

Re: forced umount?

[Pekka J Enberg]

On Mon, 26 Mar 2007, Phillip Susi wrote:
> Is this revoke system supported for the filesystem as a whole?  I thought it
> was just to force specific files closed, not the whole filesystem.  What if
> the filesystem itself has pending IO to say, update inodes or block bitmaps?
> Can these be aborted?

We never want to _abort_ pending updates only pending reads. So, even with 
revoke(), we need to be careful which is why we do do_fsync() in 
generic_revoke_file() to make sure pending updates are flushed before we 
declare the inode revoked.

But, I haven't looked at forced unmount that much so there may be other 
issues I am not aware of.

			Pekka

Re: forced umount?

[Phillip Susi]

Pekka J Enberg wrote:
> We never want to _abort_ pending updates only pending reads. So, even with 
> revoke(), we need to be careful which is why we do do_fsync() in 
> generic_revoke_file() to make sure pending updates are flushed before we 
> declare the inode revoked.
> 
> But, I haven't looked at forced unmount that much so there may be other 
> issues I am not aware of.

For the purposes of this thread we _do_ want to abort pending updates to
force the system to give up on a broken block device rather than block a 
bunch of tasks in the D state forever.

Re: forced umount?

[Gene Heskett]

On Saturday 17 March 2007, Mike Snitzer wrote:
>I'm interested in understanding the state of Linux with regard to
>_really_ forcing a filesystem to unmount.
>
>There is a (stale) project at OSDL that has various implementations:
>http://developer.osdl.org/dev/fumount/
>
>Its fairly clear that these efforts (e.g. badfs patches) haven't been
>given serious consideration for upstream inclusion.  Do others see
>value in the ability to _reliably_ force a umount by having Linux
>discard all IOs, open files, dirty inode buffers, etc of a "bad"
>blockdevice?  The goal is to not impact the availability or integrity
>of Linux while doing so.
>
>Is this forced umount work even considered worthwhile by the greater
>Linux community?  Is anyone actively working on this?

Having been 'caught out' on this subject more than a few times, usually by 
shutting down a remotely located box that was mounted via smb or cifs, 
and found the only way to get sanity back to the rest of the system was a 
hard reset of every other box that was also sharing that mount, I would 
think this is a worthwhile project.

Take that as a yes vote, from somebody who isn't franchised to vote on it 
in the first place, I'm just a user, usually playing the part of the 
canary in the coal mine.

>Mike

-- 
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)
QOTD:
	"There may be no excuse for laziness, but I'm sure looking."

Re: forced umount?

[Arjan van de Ven]

On Fri, 2007-03-16 at 23:06 -0500, Mike Snitzer wrote:
> I'm interested in understanding the state of Linux with regard to
> _really_ forcing a filesystem to unmount.
> 
> There is a (stale) project at OSDL that has various implementations:
> http://developer.osdl.org/dev/fumount/


the problem with the people who say they want forced umount is.. that
most of the time they either want
1) get rid of the namespace entry
or
2) want to stop any and all IO to a certain device/partition 

1) is already supported with lazy umount (umount -l)
for 2), it's not forced umount that they want, it's really an IO
disconnect (which scsi supports btw in 2.6 kernels).

So.. depending on which of the 2 you are, it's there. Just it's not
called "forced umount".....

Re: forced umount?

[Matthew Wilcox]

On Sun, Mar 18, 2007 at 08:16:19PM +0100, Arjan van de Ven wrote:
> the problem with the people who say they want forced umount is.. that
> most of the time they either want
> 1) get rid of the namespace entry
> or
> 2) want to stop any and all IO to a certain device/partition 

There is a third component - they want to deliver a fatal signal to
all processes which are waiting on IO to that sb.  My scenario here is a
machine with an NFS mount of a server which has gone down.  Cronjobs which
scan the whole filesystem (eg updatedb) soon pile up sleeping on access.
Equally, if one has one's ogg collection stored on said NFS server, the
ogg player will be in uninterruptible sleep while holding the sound device
open, preventing other applications from making sounds.  It's desirable
to be able to kill these apps dead, and the usual suggestion of 'mount
it soft,intr' isn't the greatest idea (and somewhat hard to change after
the fact).

I remember Linus suggesting a sleeping state between UNINTERRUPTIBLE and
INTERRUPTIBLE which would be FATAL_SIGNALS_ONLY.  The usual problem (of
short reads) isn't a problem if the task is only going to die when it
receives them.  Has anyone investigated this in any detail?  Perhaps
I'll take a look at doing it next week.

Re: forced umount?

[Jan Engelhardt]

On Mar 18 2007 14:13, Matthew Wilcox wrote:
>
>Equally, if one has one's ogg collection stored on said NFS server, the
>ogg player will be in uninterruptible sleep while holding the sound device
>open, preventing other applications from making sounds.

Only if you have
  - a card with no hardware mixing or
  - using the obsolete OSS
:)


Jan
-- 

Re: forced umount?

[Mike Snitzer]

On 3/18/07, Arjan van de Ven <arjan@infradead.org> wrote:
> On Fri, 2007-03-16 at 23:06 -0500, Mike Snitzer wrote:
> > I'm interested in understanding the state of Linux with regard to
> > _really_ forcing a filesystem to unmount.
> >
> > There is a (stale) project at OSDL that has various implementations:
> > http://developer.osdl.org/dev/fumount/
>
>
> the problem with the people who say they want forced umount is.. that
> most of the time they either want
> 1) get rid of the namespace entry
> or
> 2) want to stop any and all IO to a certain device/partition
>
> 1) is already supported with lazy umount (umount -l)
> for 2), it's not forced umount that they want, it's really an IO
> disconnect (which scsi supports btw in 2.6 kernels).
>
> So.. depending on which of the 2 you are, it's there. Just it's not
> called "forced umount".....

I'd be interested to know more about the IO disconnect support.  Do
you have any pointers on what interfaces are exposed to trigger such
an event?

The problem I'd like to solve is this:
A mounted blockdevice is considered "bad".  Given the device is "bad"
I don't care about flushing any outstanding IO.  I'd like the ability
to purge that blockdevice from the system; dropping all IOs on the
floor.  This would have to include invalidating inodes and more no?
Ultimately the superblock would need to be released too right?  Would
this happen for free with IO disconnect?

Does IO disconnect reliably and cleanly sever all associations a
mounted blockdevice has with Linux?

Re: forced umount?

[Pozsar Balazs]

On Sun, Mar 18, 2007 at 08:16:19PM +0100, Arjan van de Ven wrote:
> On Fri, 2007-03-16 at 23:06 -0500, Mike Snitzer wrote:
> > I'm interested in understanding the state of Linux with regard to
> > _really_ forcing a filesystem to unmount.
> > 
> > There is a (stale) project at OSDL that has various implementations:
> > http://developer.osdl.org/dev/fumount/
> 
> 
> the problem with the people who say they want forced umount is.. that
> most of the time they either want
> 1) get rid of the namespace entry
> or
> 2) want to stop any and all IO to a certain device/partition 
> 
> 1) is already supported with lazy umount (umount -l)
> for 2), it's not forced umount that they want, it's really an IO
> disconnect (which scsi supports btw in 2.6 kernels).


Could please tell me more about this IO disconnect?
How to trigger it etc, any pointers welcome.


thanks,
-- 
pozsy