*This message was transferred with a trial version of CommuniGate(r) Pro*
This might have been discussed a few years ago, but things have changed.
I'm talking about patches like this one (I'm not the author):
http://developer.osdl.org/dev/fumount/#kernel1
The current situation requires a way to forcibly unmount removable
media. Consider the following (real) scenario. Someone has a box with
hald + dbus + ivman to support "supermounting" the CDROM drive. He has
to install a 2 CD application using Wine for example, but the setup
application prevents normal unmounting of the first one. Then he goes on
and pushes the button to eject the CD, lazy-unmounting the media. The
kernel goes mad and all attempts to load the second CD fail (the kernel
hasn't got rid of the first fs).
If there was anything like a real forced unmounting, things would have
worked well, as on MS Windows itself.
As far as I can see, there is no other sane way to solve such problems.
So, what's keeping such patches from making their way into the
mainstream kernel? All (but maybe I haven't searched enough) arguments
against such a feature that I've seen by now just say "it's not needed",
"it's not worth it" and so on, and many of them refer to network mounts.
P.S.: I'm not saying lazy unmounting should be replaced. They both make
sense, depending on the scenario.
Eduard-Gabriel Munteanu wrote:
> *This message was transferred with a trial version of CommuniGate(r) Pro*
> This might have been discussed a few years ago, but things have changed.
> I'm talking about patches like this one (I'm not the author):
> http://developer.osdl.org/dev/fumount/#kernel1
>
> The current situation requires a way to forcibly unmount removable
> media. Consider the following (real) scenario. Someone has a box with
> hald + dbus + ivman to support "supermounting" the CDROM drive. He has
> to install a 2 CD application using Wine for example, but the setup
> application prevents normal unmounting of the first one. Then he goes on
> and pushes the button to eject the CD, lazy-unmounting the media. The
> kernel goes mad and all attempts to load the second CD fail (the kernel
> hasn't got rid of the first fs).
>
> If there was anything like a real forced unmounting, things would have
> worked well, as on MS Windows itself.
>
> As far as I can see, there is no other sane way to solve such problems.
> So, what's keeping such patches from making their way into the
> mainstream kernel? All (but maybe I haven't searched enough) arguments
> against such a feature that I've seen by now just say "it's not needed",
> "it's not worth it" and so on, and many of them refer to network mounts.
>
> P.S.: I'm not saying lazy unmounting should be replaced. They both make
> sense, depending on the scenario.
There are patches in -mm for revokeat()/frevoke(), which can be used to
implement exactly that. If a device "vanishes" (CD is removed in the
middle of loading, USB pend rive yanked out the middle of I/O, NFS
server thats gone MIA), A user-space program (maybe HAL) could iterate
over the open files and revoke() them, at which point the system can be
cleanly unmounted.
*This message was transferred with a trial version of CommuniGate(r) Pro*
Salah Coronya wrote:
> There are patches in -mm for revokeat()/frevoke(), which can be used to
> implement exactly that. If a device "vanishes" (CD is removed in the
> middle of loading, USB pend rive yanked out the middle of I/O, NFS
> server thats gone MIA), A user-space program (maybe HAL) could iterate
> over the open files and revoke() them, at which point the system can be
> cleanly unmounted.
>
Sounds promising. Is there any glibc version that implements these
syscalls (googling for 'glibc' and 'frevoke' didn't help)? I'd like to
implement and test this on my Linux box with HAL.
On Fri, Aug 31, 2007 at 06:35:04PM +0300, Eduard-Gabriel Munteanu wrote:
> *This message was transferred with a trial version of CommuniGate(r) Pro*
> Salah Coronya wrote:
> >There are patches in -mm for revokeat()/frevoke(), which can be used to
> >implement exactly that. If a device "vanishes" (CD is removed in the
> >middle of loading, USB pend rive yanked out the middle of I/O, NFS
> >server thats gone MIA), A user-space program (maybe HAL) could iterate
> >over the open files and revoke() them, at which point the system can be
> >cleanly unmounted.
Bull. It will not help you at all if a syscall is stuck.
> Sounds promising. Is there any glibc version that implements these
> syscalls (googling for 'glibc' and 'frevoke' didn't help)? I'd like to
> implement and test this on my Linux box with HAL.
Implementation that is there in -mm is broken; see discussion on the list.
*This message was transferred with a trial version of CommuniGate(r) Pro*
Salah Coronya wrote:
> There are patches in -mm for revokeat()/frevoke(), which can be used to
> implement exactly that. If a device "vanishes" (CD is removed in the
> middle of loading, USB pend rive yanked out the middle of I/O, NFS
> server thats gone MIA), A user-space program (maybe HAL) could iterate
> over the open files and revoke() them, at which point the system can be
> cleanly unmounted.
>
Sounds promising. Is there any glibc version that implements these
syscalls (googling for 'glibc' and 'frevoke' didn't help)? I'd like to
implement and test this on my Linux box with HAL.