Re: [ANNOUNCE] submount: another removeable media handler

Re: [ANNOUNCE] submount: another removeable media handler

[Andrey Borzenkov]

> Basically, in my opinion removable media should be handled by insert
> and removal detection, not by access detection.  Obviously, there are
> some sticky issues with that in the case where media can be removed
> without notice (like PC floppies or other manual-eject devices), but
> overall I think that is the correct approach.

You are absolutely right. Unfortunately, I am not aware of any general
way to request device to notify about media insertion/ejection.
Without such notification the only thing you can do is to poll - and
this is the same access detection in disguise. With disatvantage
that polling wastes system resources and is subject to races.

-andrey

Re: [ANNOUNCE] submount: another removeable media handler

[H. Peter Anvin]

Andrey Borzenkov wrote:
> 
>>Basically, in my opinion removable media should be handled by insert
>>and removal detection, not by access detection.  Obviously, there are
>>some sticky issues with that in the case where media can be removed
>>without notice (like PC floppies or other manual-eject devices), but
>>overall I think that is the correct approach.
> 
> 
> You are absolutely right. Unfortunately, I am not aware of any general
> way to request device to notify about media insertion/ejection.
> Without such notification the only thing you can do is to poll - and
> this is the same access detection in disguise. With disatvantage
> that polling wastes system resources and is subject to races.
> 

No, that is not correct.  Polling for insertion is different from 
probing from access.  There isn't a *general* way to obtain 
notification, but may devices offer it, so you need to develop a modular 
way to deal with it.

	-hpa

Re: [ANNOUNCE] submount: another removeable media handler

[H. Peter Anvin]

Steve Brueggeman wrote:
> Off Topic, sorry.
> 
> Is there a way to detect whether a floppy has been installed, without
> actually forcing the motor to spin, and heads to engage???
> 
> I'd like to create a simple auto-run utility that constantly looks for
> a special file on a MSDOS formatted floppy, and run it if found.
> Unfortunately, the only way I know of to determine if a floppy is
> installed is to open the floppy device, which causes the undesired
> motor spin-up, and head access.
> 
> Any help is greatly appreciated!!!
> 

Electrically it should be possible.  Whether or not the floppy device 
driver supports it is another matter.

	-hpa

Re: [ANNOUNCE] submount: another removeable media handler

[Steve Brueggeman]

Off Topic, sorry.

Is there a way to detect whether a floppy has been installed, without
actually forcing the motor to spin, and heads to engage???

I'd like to create a simple auto-run utility that constantly looks for
a special file on a MSDOS formatted floppy, and run it if found.
Unfortunately, the only way I know of to determine if a floppy is
installed is to open the floppy device, which causes the undesired
motor spin-up, and head access.

Any help is greatly appreciated!!!

Steve Brueggeman


On 16 May 2003 11:46:20 -0700, you wrote:

>Followup to:  <200305161027.20045.eweiss@sbcglobal.net>
>By author:    Eugene Weiss <eweiss@sbcglobal.net>
>In newsgroup: linux.dev.kernel
>>
>> 
>> > how is it different from what automounter does?
>> 
>> Autofs works by creating a special filesystem above the vfs layer, and passing 
>> requests and data back and forth.   Submount actually does much less than 
>> this- it puts a special filesystem underneath the real one, and the only 
>> things it returns to the VFS layer are error messages.  It handles no IO 
>> operations whatsoever.
>> 
>> Peter Anvin has called using the automounter for removeable media "abuse."
>> Submount is designed for it.
>> 
>
>Sure, but it's not clear to me that you have listened to me saying
>*why* it is abuse.
>
>Basically, in my opinion removable media should be handled by insert
>and removal detection, not by access detection.  Obviously, there are
>some sticky issues with that in the case where media can be removed
>without notice (like PC floppies or other manual-eject devices), but
>overall I think that is the correct approach.
>
>	-hpa

Re: [ANNOUNCE] submount: another removeable media handler

[Eugene Weiss]

> > how is it different from what automounter does?
> 
>>Autofs works by creating a special filesystem above the vfs layer, and 
passing 
>> requests and data back and forth.   Submount actually does much less than 
>> this- it puts a special filesystem underneath the real one, and the only 
>> things it returns to the VFS layer are error messages.  It handles no IO 
>>operations whatsoever.
>> 
>>Peter Anvin has called using the automounter for removeable media "abuse."
>> Submount is designed for it.
>> 

>Sure, but it's not clear to me that you have listened to me saying
>*why* it is abuse.

>Basically, in my opinion removable media should be handled by insert
>and removal detection, not by access detection.  Obviously, there are
>some sticky issues with that in the case where media can be removed
>without notice (like PC floppies or other manual-eject devices), but
>overall I think that is the correct approach.
>
>	-hpa

I managed to read several of your warnings about using autofs for media 
without coming across an explanation of why.  I just assumed that as 
maintainer, you had good reasons to do so.  I more-or-less agree with you 
about the desirability of insert and removal detection.  I'm not sure if it 
could ever be made to work for floppies, but there is no reason why one 
solution should fit all cases.  If there were common ioctls which could check 
the insertion and removal status of the various drives, I might have taken 
that approach.  

I wanted to get the same functionality as supermount without the instability, 
and as far as I can tell, I have succeeded.  It's not ideal, but it works for 
me, and hopefully will work for others as well until something better is 
produced.

Eugene

Re: [ANNOUNCE] submount: another removeable media handler

[H. Peter Anvin]

Followup to:  <200305161027.20045.eweiss@sbcglobal.net>
By author:    Eugene Weiss <eweiss@sbcglobal.net>
In newsgroup: linux.dev.kernel
>
> 
> > how is it different from what automounter does?
> 
> Autofs works by creating a special filesystem above the vfs layer, and passing 
> requests and data back and forth.   Submount actually does much less than 
> this- it puts a special filesystem underneath the real one, and the only 
> things it returns to the VFS layer are error messages.  It handles no IO 
> operations whatsoever.
> 
> Peter Anvin has called using the automounter for removeable media "abuse."
> Submount is designed for it.
> 

Sure, but it's not clear to me that you have listened to me saying
*why* it is abuse.

Basically, in my opinion removable media should be handled by insert
and removal detection, not by access detection.  Obviously, there are
some sticky issues with that in the case where media can be removed
without notice (like PC floppies or other manual-eject devices), but
overall I think that is the correct approach.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64

Re: [ANNOUNCE] submount: another removeable media handler

[Eugene Weiss]

> how is it different from what automounter does?

Autofs works by creating a special filesystem above the vfs layer, and passing 
requests and data back and forth.   Submount actually does much less than 
this- it puts a special filesystem underneath the real one, and the only 
things it returns to the VFS layer are error messages.  It handles no IO 
operations whatsoever.

Peter Anvin has called using the automounter for removeable media "abuse."
Submount is designed for it.

Re: [ANNOUNCE] submount: another removeable media handler

[Michael Buesch]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 16 May 2003 07:06, Eugene Weiss wrote:
> Submount:  Yet another attempt at solving the removeable media problem.
>
> It has been tested only on 2.5.66 and 2.5.69 so far, but should work on
> many earlier 2.5.x kernels as well.  I would greatly appreciate feedback
> from anyone who would like to check it out.  It is available at
> http://sourceforge.net/projects/submount/
[SNIP]

I'm not able to download version 0.1 from any of the sourceforge servers:
"The requested URL /sourceforge/submount/submount-0.1.tar.gz was not found on this server."

- -- 
Regards Michael Büsch
http://www.8ung.at/tuxsoft
 14:15:12 up 45 min,  2 users,  load average: 1.26, 1.24, 1.20

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+xNbBoxoigfggmSgRArZJAJ0Y/TADeiqRVJqoG5lASZ2oGbipUQCeJfMn
muC06834+wVEXYD3BmuedTs=
=y9iE
-----END PGP SIGNATURE-----

Re: [ANNOUNCE] submount: another removeable media handler

[Alex Riesen]

Eugene Weiss, Fri, May 16, 2003 07:06:37 +0200:
> Submount:  Yet another attempt at solving the removeable media problem.  
>  
> It has been tested only on 2.5.66 and 2.5.69 so far, but should work on many
> earlier 2.5.x kernels as well.  I would greatly appreciate feedback from
> anyone who would like to check it out.  It is available at
> http://sourceforge.net/projects/submount/ 
>  
> How it Works: 
>  
> It is composed of two parts: a kernel module and a userspace program.  
>  

how is it different from what automounter does?

[ANNOUNCE] submount: another removeable media handler

[Eugene Weiss]

Submount:  Yet another attempt at solving the removeable media problem.  
 
It has been tested only on 2.5.66 and 2.5.69 so far, but should work on many
earlier 2.5.x kernels as well.  I would greatly appreciate feedback from
anyone who would like to check it out.  It is available at
http://sourceforge.net/projects/submount/ 
 
How it Works: 
 
It is composed of two parts: a kernel module and a userspace program.  
 
The kernel module, titled subfs, implements a dummy filesystem which is
mounted on the desired mountpoint.  Before a process can access a directory,
or any file bellow it, one of two filesystem methods must be called: open() or
lookup().  When subfs gets a call to either of these functions, it calls the
userspace part of submount, which then mounts the appropriate filesystem on
top of the subfs mountpoint, forks off a daemon for unmounting, and exits.  If
the mount was successful, subfs uses the signal handling system to restart the
system call, which then is executed on the real filesystem.  Subfs then
restarts the system calls of any other requests that arrived while the mount
was taking place. 
 
The userspace portion of submount is titled /sbin/submountd.  It is a small
program that does some minimal options processing, and then makes the mount()
system call.  If the mount is successful, it forks off a new process which
enters a one second loop checking whether the filesystem can be unmounted.   
 
 
Advantages: 
 
Small, light, and fast.  The kernel module is about 11kB, the user program
about 21kB. 
 
Requires no changes to the kernel code outside its own module. 
 
The kernel portion is very simple.  The feature set is implemented in
userspace. 
 
All IO is handled through the real filesystem at its full speed.  When the IO
is heaviest, submount imposes no performance penalty at all. 

Flexible.  Another program can be substituted for submountd if the system in
question has particular needs.  One could even use a shell script that calls
the regular mount and umount utilities. 
 
No configuration needed, except fstab. 
 
 
Problems: 
 
Not quite as fast as a permanently mounted filesystem, since the dentry cache
is purged on unmounting.  Directories must be read again each time they are
called after unmounting even though the disk hasn't changed. 
 
Errors are registered quietly.  If the user makes a typo in the mount command,
or in the fstab file, it may be necessary to read the system log to discover
it.  (Perhaps mount could be made to do some syntax checking when a subfs
filesystem is mounted?) 
 
Programs which automatically mount a cdrom directory from fstab can mount a
second subfs directory over the filesystem mounted by the first.  This could
be checked for in subfs, but it would be better to do it in the mount utility. 

 
Installation and usage: 
 
The sources, both kernel and userspace, can be downloaded from
http://sourceforge.net/projects/submount/ .  The userspace program is built in
the usual way, and a makefile is provided for building the kernel module. 
 
To mount a drive under subfs, use the usual syntax, except put subfs in the
filesystem type field, and add the option fs=<fstype> in the options list. 
 
for example	mount -t subfs /dev/scd0 /mnt/cdrom -o fs=iso9660,ro 
or for fstab	/dev/scd0 /mnt/cdrom subfs fs=iso9660,ro 
 
I've copied the function to find the filesystem type by reading the superblock
from mount, so fs=auto will work.  It can, however, cause a noticeable pause,
particularly on floppies, so there is another method for using multiple
filesystems.  If a keyword is used in the fs= option, submountd will attempt
to mount filesystems from a list.  Currently there are two options: 
fs=floppyfss attempts vfat and ext2, and fs=cdfss tries iso9660 and udf. 
Submountd will strip the options "codepage", "iocharset" and "umask" from
filesystems that don't take them, so these can be included in list mounts, or
auto-detected mounts. 
 
These fstab lines should work: 
 
/dev/scd0 /mnt/cdrom subfs fs=cdfss,ro,iocharset=iso8859-1,umask=0 0 0 
/dev/fd0 /mnt/floppy subfs fs=floppyfss,iocharset=iso8859-1,sync,umask=0 0 0 
 
Once this is done, just access the mountpoint directory as usual. 
 
Eugene Weiss <eweiss@NOSPAM.sbcglobal.net>