transitmount 0.5 documentation: Possible future of transitmount and todo-list

Possible future of transitmount and todo-list

I've thrown out here misc ideas about enhancements.

Update with v0.5: I think caching volume management is a different feature. It will probably go into a different project. Transitmount will remain a program that allows easy access to partitions and partition-like devices.

Possible future of transitmount

Initially, transitmount aimed at simply making transitting hard disk available.

transitmount may be extended in the following design: you can access a volume by its referer label whatever the way it is currently accessible. For example, a CD-Rom volume may be currently accessible via your CD-Rom drive, your CD-burner drive, or as an image somewhere on your hard disk or somewhere on the network. If a program needs it, it only has to look in /mnt/transit/volumename.

It seems that up to now, the trend was to ignore volumes and focus on files instead. The Internet seems to work this way. Still, your personal collection of CD-Rom, and iso images you find on the internet (Linux distributions, for example) are volumes.

Other collections of files and resources that are not, technically speaking, volumes, but conceptually, are considered as a whole and may be accessed locally from a drive or on the net, may benefit from this way of thinking. For example, when your laptop is connected to the net, if might be most convenient to access most resources via network, whereas when you're far from the network, you want to access them transparently as easily and without always the same manipulations. The system would ask for a volume (insert the proper CD-Rom) if it isn't already available without your intervention.

Perhaps other solutions are better.

If you have any comments, please e-mail me: gouri at amphi-gouri dot org .

Todo-list

packaging: rpm, debian package, ...

config file, to specify devices to ignore, etc...

(DONE since 0.2) fsck the filesystem with the correct fs type before mounting (easier if fs type is guessed correctly, even easier we modify fstab accordingly)

resolve conflicts if two filesystems are to be mounted on the same place

(DONE since 0.4) be devfs-aware. Actually, we don't need to explicitely deal with devfs, but follow the symlinks when checking if a filesystem is already mounted. What about broken systems where devfs is enabled in kernel (and therefore in /proc/partitions) but devfs is not mounted on /dev ? ... For now, transitmount will complain about candidate devices not existing, but it won't do any harm.

allow hooks to be run, e.g. for /sbin/hdparm -S nnn device to setup sleep delay (hard drives in racks heat more because of poor ventilation)

update fstab, to allow users to mount/umount those partitions

alternative ways to take care of those devices: setup an autofs "auto.transit" config file, to mount on demand only

(DONE since 0.2, uses e2label) a cleaner, faster way to extract the ext2 volume label, currently we dumpe2fs | grep.

(DONE since 0.3) "pre-mount read only trick": if no sensible volume name was found, try to mount the filesystem read-only on a temp place, look for a file with a specific name whose content would be the volume name ?

Find some clean way to identify other filesystem types, especially iso9660 and related (we may use the "pre-mount read only" trick, relying on the kernel). Then use "isoinfo" to find iso9660 volume label.

NEW. Support for linked operation, if the device is already mountable at some place. In this case we mount the device (cdrom, etc...) to the standard place (usually /mnt/cdrom, as mount allows it without root permissions), then put a symlink in the shared place ( /mnt/transit/volumename/ -> /mnt/cdrom or /mnt/cdrom2 or wherever it is really mounted ). This seems useless if one has only one cdrom, but wait, there's more. First, this allows the system to ask "please insert volume named Debian_2.2r2_1 into any suitable drive", when it needs it, then access it at /mnt/transit/volumename/, instead of only looking in /mnt/cdrom, thus only relying on the first available cdrom, which is dumb (urpmi does the dumb way in Mandrake). Second, it allows one to have a collection of iso (or other) images ready to mount (say, on a big hard drive or a network drive) and have it mounted on a sensible place depending on its volume name. Perhaps this feature has more to do with autofs ?

For the abovementioned operation, allow a config file to specify place to look for volume images

NEW. Support of operation as non-root user ( if fstab was prepared by a root instance of transitmount at boot time ), the volumename place may then becomes ~/transit/ instead of /mnt/transit.

NEW. Support for images instead of real devices: transitmount would add "-o loop" when trying to mount a non-device.

NEW. Have an interactive facility to help the unexperienced user set volume labels: it would call the appropriate tool to set the label, or put a "soft label".

urgency: low. setup DOS-like mount points for FAT partitions without volume name. Does anyone still want those ill-defined ugly drive letters anyway ?

maybe integrate this into kudzu or harddrake ? (those do general purpose hardware config at boot, but nothing yet for hard disks)

have it work on other Unices (*BSD, ...). For now relies on /proc/partitions .

Bug:

Relies on file(1) for guessing the filesystem type, which doesn't always work, even for ext2 filesystems (the version shipped with Mandrake 8.0 beta3, for example). We could also pre-mount read-only, thus letting the kernel guess the fs type.

Is it safe to call mount() on a disk that may contain arbitrary data ? mount(8) says it may crash the system. I've never seen this, which means it's ok for a desktop machine. (You won't use transitmount on a server anyway.)

The html page generated by doxygen is not 100% standard-compliant. It's probably temporary anyway.

As you see, there are many ideas, but not much time to make them real. If you feel you can contribute, e-mail me! <gouri whose email is hosted at amphi-gouri.org>

Back to transitmount

Transitmount is available on the following mirrors:

Documentation generated by doxygen