Feature Suggestion: Descriptive Mount Points

[SamK]

The machine used to make this post has two internal hard disks and one external (USB) hard disk.  In total, they hold eleven partitions which are correctly listed in /mnt.  Additionally there are two optical drives which are also listed in /mnt.  The result is thirteen mount points which are all either hdxx or sdxx.

The purpose or content of each partition is not immediately obvious and my memory is fallible.  Consequently, I often find it useful to run a command such as blkid /dev/[hs]d* -o list, use the contents of the label column, relate it to the device column and mount on the appropriate mount point.

My suggestion is that creation of the mount points takes account of an existing label and (when present) includes it in the mount point name in /mnt.  When a label is not present, the mount point might default to the current method.
For example:
APPLES on hda1
PEARS on hdc5
BANANAS on hdc6

or

sda1 ORANGES
sdc5 LEMONS
sdc6 LIMES

While not being aware of the coding effort required to implement this suggestion, two primary benefits are apparent:

• For those choosing not to use labels there is no change from current practice
• For those using labels, mounting/unmounting becomes more intuitive.  This may be particularly advantageous for users doing this via a file manager.

   

[ixbrian]

I think this is a good idea.   Below are some patches that implement this.  With these patches, any file system that has a label will have its mount point created at /mnt/labelname, and any filesystems that don't have a label will behave like they normally do.    If your label has spaces in it, the spaces will be changed to underscores for the mount directory. 

Brian

Patch for /usr/sbin/rebuildfstab:

Code: [Select]

--- rebuildfstab_orig
+++ rebuildfstab_updated
@@ -63,8 +63,15 @@
     ext2|ext3) OPTIONS="${OPTIONS},relatime" ;;
     swap) OPTIONS="defaults"; MOUNTPOINT="none" ;;
   esac
+ 
+  LABEL="$(blkid $DEVROOT/$DEVNAME -o udev 2>/dev/null | grep ID_FS_LABEL= | cut -f2 -d= )"
+
+  if [ -n "$LABEL" ]; then
+    MOUNTPOINT="/mnt/$LABEL"
+  fi
+ 
   if [ "$MOUNTPOINT" != "none" ]; then
-    mkdir -p "/mnt/$DEVNAME" 2>/dev/null >/dev/null
+    mkdir -p "$MOUNTPOINT" 2>/dev/null >/dev/null
   fi
   printf "%-15s %-15s %-8s %-20s %-s\n" "$DEVROOT/$DEVNAME" "$MOUNTPOINT" "$FSTYPE" "$OPTIONS" "0 0 $ADDEDBY" >>"$TMP"
 done

For mnttool to work, there are a couple of more changes needed.

/usr/bin/mountables.sh needs to be changed to:

Code: [Select]

#!/bin/sh
cat /etc/fstab | awk -F '/' '/\/mnt\// {print $5}' | awk '{print $1}' | awk '{ sub(/[ \t]+$/, ""); print }' | sort -r | awk 'a != $0; { a = $0 }' | sort > /tmp/mountables

mnttool.fl needs to be patched and recompiled with this patch:

Code: [Select]

--- mnttool.fl_orig
+++ mnttool.fl_updated
@@ -40,8 +40,8 @@
 
 ifstream fin("/tmp/mountables");
 string line;
-string commandHead = "grep /mnt/";
-string commandTail = " /etc/mtab >/dev/null";
+string commandHead = "grep '/mnt/";
+string commandTail = " ' /etc/mtab >/dev/null";
 
 while ( getline(fin,line) )
 {
@@ -89,7 +89,7 @@
    int results;
    if (mountState.at(selected) == 0)   // mounted
    {
-      results = system(("sudo umount /dev/" + mountList.at(selected)).c_str());
+      results = system(("sudo umount /mnt/" + mountList.at(selected)).c_str());
       if (results == 0)
       {
          btnState->color((Fl_Color)1);         
@@ -99,7 +99,7 @@
    }   
    else
    {
-      results = system(("sudo mount /dev/" + mountList.at(selected)).c_str());
+      results = system(("sudo mount /mnt/" + mountList.at(selected)).c_str());
       if (results == 0)
       {
          btnState->color((Fl_Color)2);         


[curaga]

IMHO naming it by the label is less descriptive to me. I know /mnt/sda1 is my usb stick, but what the heck is /mnt/asdf_asdf_fasd? Or /mnt/data, FWIW. Maybe the label could be a symlink to the main dir?

Then there's the issue of cd/dvd media. If there's a disc in at boot, the dir shall be /mnt/TheDayAfterTomorrow, even after it has been changed.

[SamK]

To help clarify the idea - the suggestion in the opening post is to include the pair of values. 
Example format
APPLES on and hda1
or
sda1 and ORANGES

defaulting to the current format when a label is not present.  I don't know if an underscore is required to replace spaces and will leave that to others.

Then there's the issue of cd/dvd media. If there's a disc in at boot, the dir shall be /mnt/TheDayAfterTomorrow, even after it has been changed.

Using the pair values would continue to indicate the CD drive device as at present  (in addition to the label of the media left in the drive at boot-up).
   

[ixbrian]

IMHO naming it by the label is less descriptive to me. I know /mnt/sda1 is my usb stick, but what the heck is /mnt/asdf_asdf_fasd? Or /mnt/data, FWIW. Maybe the label could be a symlink to the main dir?

Then there's the issue of cd/dvd media. If there's a disc in at boot, the dir shall be /mnt/TheDayAfterTomorrow, even after it has been changed.

Since the label is user customizable, it seems like it would be more descriptive. 

Another advantage is that device names are subject to change at reboot if your hardware has changes or if you are booting on another computer.  Using the labels as mount points would keep your mount points consistent even if your device names change. 

You're right on cd media, that would have to be handled in a different way. 

Having the label be a symlink to the device name is a good idea. 

I'll make some changes and post an update. 

[ixbrian]

IMHO naming it by the label is less descriptive to me. I know /mnt/sda1 is my usb stick, but what the heck is /mnt/asdf_asdf_fasd? Or /mnt/data, FWIW. Maybe the label could be a symlink to the main dir?

Then there's the issue of cd/dvd media. If there's a disc in at boot, the dir shall be /mnt/TheDayAfterTomorrow, even after it has been changed.

I updated rebuildfstab to auto create symlinks from the label to the device name in /mnt.   However, this won't really work because if you try to mount the symlink label, mount just says it can't find the symlink label in /etc/fstab.  I guess it would be possible to have 2 entries per filesystem in /etc/fstab (one for device name, one for label name), but that doesn't seem like a good idea to me.  

Anyway, I updated the rebuildfstab patch so that it will exclude CD/DVD devices from using a label name for the mount point due to the very good point you brought up about changing media.  

Here is the updated patch.

Code: [Select]

--- rebuildfstab_orig
+++ rebuildfstab_updated
@@ -41,13 +41,15 @@
   DEVMAJOR="$(cat $i|cut -f1 -d:)"
   FSTYPE=""
 
+  CDROM=no
+
   case "$DEVMAJOR" in
     2|98)
       FSTYPE="auto"
       ;;
     3|8|11|22|33|34)
       case "$FDISKL" in *"$DEVROOT/$DEVNAME "*) FSTYPE="$(fstype $DEVROOT/$DEVNAME)" ;; esac
-      case "$CDROMS" in *"$DEVROOT/$DEVNAME"*) FSTYPE="auto" ;; esac
+      case "$CDROMS" in *"$DEVROOT/$DEVNAME"*) FSTYPE="auto"; CDROM=yes ;; esac
       ;;
     179|9|259) # MMC or MD (software raid)
       FSTYPE="$(fstype $DEVROOT/$DEVNAME)"
@@ -63,8 +65,15 @@
     ext2|ext3) OPTIONS="${OPTIONS},relatime" ;;
     swap) OPTIONS="defaults"; MOUNTPOINT="none" ;;
   esac
+ 
+  LABEL="$(blkid $DEVROOT/$DEVNAME -o udev 2>/dev/null | grep ID_FS_LABEL= | cut -f2 -d= )"
+
+  if [ -n "$LABEL" -a "$CDROM" = "no" ]; then
+    MOUNTPOINT="/mnt/$LABEL"
+  fi
+ 
   if [ "$MOUNTPOINT" != "none" ]; then
-    mkdir -p "/mnt/$DEVNAME" 2>/dev/null >/dev/null
+    mkdir -p "$MOUNTPOINT" 2>/dev/null >/dev/null
   fi
   printf "%-15s %-15s %-8s %-20s %-s\n" "$DEVROOT/$DEVNAME" "$MOUNTPOINT" "$FSTYPE" "$OPTIONS" "0 0 $ADDEDBY" >>"$TMP"
 done




[maro]

Just a quick question: What happens if a LABEL is not unique amongst the set of devices? I could quite easily imagine to have a file system labeled 'DATA' on two different devices (e.g. a USB hard disk and a USB pendrive).

Another quick thought: Would using hard links instead of soft links make a difference?

[gerald_clark]

How would you hard link them?

[ixbrian]

Just a quick question: What happens if a LABEL is not unique amongst the set of devices? I could quite easily imagine to have a file system labeled 'DATA' on two different devices (e.g. a USB hard disk and a USB pendrive).

Good point.  It wouldn't be too difficult to add in some logic to work around having non-unique labels.  If there is interest in moving forward with using labels as mount points I can work on adding it in. 

Brian

[SamK]

The inclusion of labels as announced in this topic http://forum.tinycorelinux.net/index.php?topic=7949.0 is a welcome move.  It led me to ponder further...

In this topic http://forum.tinycorelinux.net/index.php?topic=7935.msg42672 a patch was accepted in recognition that multiple partitions are now more likely due to the ready availability of large disks.  It may therefore become more desirable for them to indicate their purpose/content.

An example of the adopted manner of displaying labels is of course not yet available.  From the announcement, it appears that only those using mnttool will obtain the benefit of enhanced identification.  In contrast, a descriptive mount point would be available to all users whatever method they choose. 

Currently, I conduct mounting/unmounting by command line (including scripts), mnttool, and file manager.  From my point of view, the ideal outcome would be that each method is able to use the enhancement.  This is in no way suggesting that TC/MC should be designed to take account of the vagaries of third-party extensions.  In view of the offer of a patch, it is regrettable that only one of these methods will benefit in future.

Just a quick question: What happens if a LABEL is not unique amongst the set of devices? I could quite easily imagine to have a file system labeled 'DATA' on two different devices (e.g. a USB hard disk and a USB pendrive).

Good point.  It wouldn't be too difficult to add in some logic to work around having non-unique labels.  If there is interest in moving forward with using labels as mount points I can work on adding it in. 

Brian

Would this not be automatically taken account of if the mount point name is constructed of the two values device-id_label or vice versa?  It may be possible for a system to have multiple labels such as 'DATA' but not multiple 'sda1_DATA' etc.