[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <170fa0d20703181320j59ee759dtbc0e3c7c916cd190@mail.gmail.com>
Date: Sun, 18 Mar 2007 16:20:33 -0400
From: "Mike Snitzer" <snitzer@...il.com>
To: "Arjan van de Ven" <arjan@...radead.org>
Cc: linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: forced umount?
On 3/18/07, Arjan van de Ven <arjan@...radead.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?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists