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 <[email protected]>
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?
-----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-----
> 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.
Followup to: <[email protected]>
By author: Eugene Weiss <[email protected]>
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
--
<[email protected]> at work, <[email protected]> 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
> > 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
> 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
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: <[email protected]>
>By author: Eugene Weiss <[email protected]>
>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
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
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