submount: another removeable media handler

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:

how is it different from what automounter does?

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

[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-----

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

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

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

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

-hpa