UFS Create and use disk partition labels

S

sprock

Hello,

I want to label pre-existing disk partitions (that contain filesystems) and use the labels to mount the partitions from /etc/fstab. I first tried using tunefs from an install CD but the labels did not persist on rebooting. I next tried booting into single user mode as per the handbook:

Code: 
https://www.freebsd.org/doc/handbook/geom-glabel.html

and using commands like
Code: 
glabel label -v home /dev/ada0p7
. In the latter case the labels are created in /dev/label but they are gone once I continue booting.

Code: 
kldload geom_label
tells me the module is either loaded or built into the (generic) kernel.

How can I create permanent disk labels? I am using FreeBSD 10.2 on an amd64.

Thanks,
Sprock
 
I played around with UFS labels on my 10.3/amd64 system and had a similar experience to what you described.
For the sake of simplicity, I stayed with newfs(8) and tunefs(8).
I tried creating new slices and labeling them with newfs -L "labelHere" da0s1a, or just formatting one without a label using newfs da0s2a and then adding a label using tunefs -L "anotherLabel" /dev/da0s2a.
I played with similar commands when booted a system installed onto my internal SATA drive (ada0) and FreeBSD_Install pendrive (da0). And I (re)labeled both my SATA volume and the volumes on another pendrive (da1).

The results I got are not consistent.
I do get different entries from ls -l /dev/ufs/ depending on booting the SATA system or the FreeBSD_Install pendrive.
However, I concluded that the SATA volume label stays permanent, albeit not visible when the SATA disk boots.
You can reproduce that by doing this:

1., boot from the FreeBSD_Install CD, select "Live CD", login as root. Then,
Code: 
tunefs -L "newTestLabel" /dev/ada0p7
ls -l /dev/ufs/
shutdown -p now
That ls will most likely show your new UFS label in its output.

2., boot from your harddisk, login as root, then
Code: 
ls -l /dev/ufs/
which will most likely NOT list your "newTestLabel" volume. Then issue a shutdown now to go to single-user mode, press Enter for a default /bin/sh shell. Then ...
Code: 
mount -u -r /
ls -l /dev/ufs/
which will remount your / volume as read-only, and will now most likely list that "newTestLabel" in its output.
Interestingly, if you then issue an exit to go back to multi-user mode, log in and run a ls -l /dev/ufs/ again, you no longer see that "newTestLabel".

Meanwhile, some other volume labels appear to be consistent/permanent. Even across reboots from the pendrive or the SATA disk.

So, this does not solve your problem. But at least proves that the problem is not in your particular configuration.

Regards,
Keve
 
http://www.wonkity.com/~wblock/docs/html/labels.html
If you mount the partition immediately after adding the label, it will be overwritten. I've never really investigated. It might be possible to avoid that by retasting. But that article just has the reader reboot, which works.

Don't use glabel(8) to write labels to existing filesystems. It will overwrite the last block. In fact, try to avoid using glabel(8) at all.

The easy way is to use GPT partitioning and GPT labels.
 
Last edited by a moderator:
Thanks Keve, that pretty much summarises my experience.

Thanks wblock. I was able to solve the problem using gpt labels. In single user mode:

gpart modify -i 7 -l home ada0
and so on.

Cheers,
sprock
 
Excellent article on using labels, Warren. Thanks for that!
I found a couple of points worth discussing a bit further.
  • The comment of Labeling a read-only filesystem seems weird until you realize that the label isn’t part of the filesystem may cause some misunderstanding/confusion. Right there, you are actually working with UFS labels. And UFS labels -as the name suggests- are very much part of the filesystem. If I format ada0s1a as UFS2 and assign a label too (say, using newfs -L), then overwrite ada0s1a with zeros, the label will be destroyed too. Proof that the UFS label is indeed stored as part of the UFS filesystem. The same thing reversed, you cannot assign an UFS label to ada0s1a (say, using tunefs -L) unless you create a proper UFS filesystem on it once again. Or for another proof, one can actually find multiple instances of the UFS label as part of the filesystem by examining the disk contents (say, using hexdump -C /dev/ada0s1a).
    Perhaps a better phrasing of that comment could be: Labeling a read-only filesystem may seem weird, yet here it is perfectly appropriate as UFS labels are handled in a special way, allowing them to be modified independent of other filesystem data.
  • The statement If you immediately mount / so you can edit /etc/fstab, the new label on / will go away is also somewhat misleading. It implies that either mount() writes to the disk (overwriting the fresh label), or the label change of tunefs() did not actually write to the disk but got cached/buffered somehow. Neither of which implications are true. Both tunefs -L and newfs -L permanently write the new label inside the UFS filesystem, as can be verified immediately by something like hexdump -C /dev/ada0s1a.
  • The actual issue sprock raised. Further investigation shows that although the problem is not as serious as it looks, something is definitely fishy in the way /dev/ufs/ is populated. I have tested it with 3 different systems on two different computers, a FreeBSD 9.2R/i386 on a HP 7700, a FreeBSD 9.2R/amd64 on that same HP 7700, and a FreeBSD 10.3R/amd64 on a HP 8000. Each case the GENERIC kernel was used, ada0 having an MBR schema and ada0s1 having a BSD schema. Here is what I found:
    1. Booting off of a standard 10.3R-memstick pendrive (live CD option) and issuing
      Code: 
      tunefs -L "FBSD92amd64" /dev/ada0s1a
tunefs -L "FBSD92i386" /dev/ada0s3a
tunefs -L "dumpStorage" /dev/ada0s4a
ls -l /dev/ufs/
      shows 4 entries. The "FreeBSD_Install" label on da0 and the 3 new labels I just added to ada0.
    2. Rebooting to FreeBSD 9.2R/amd64 with /dev/ada0s1a / ufs ... in /etc/fstab and issuing ls -l /dev/ufs/ will list 3 entries only, with the label for the root fs (ada0s1a) not shown. Then going to single-user mode and remounting / as read-only, ls -l /dev/ufs/ immediately shows all 4 entries, including the label of the root fs. Issuing exit and returning the system back to multi-user mode, ls -l /dev/ufs/ once again lacks the entry of the root fs.
    3. Booting FreeBSD 9.2R/i386 with /dev/ada0s3a / ufs ... in /etc/fstab and issuing ls -l /dev/ufs/ will list 3 entries only, with the label for the root fs (ada0s3a) not shown. But nicely showing the one that was playing hide-and-seek earlier, ada0s1a. Otherwise the experience is similar to that of #2. The entry of the then actual root fs is not available in /dev/ufs/ when the fs is mounted RW, but immediately becomes available when it is mounted RO, then vanishes again when its remounted RW again.
    4. Changing /etc/fstab to mount the root fs using UFS labels eliminates this odd behaviour. Even though the entry of the root fs was never visible in /dev/ufs/ before, the system can apprently find it and use it at boot time. In addition, when the system is booted this way (using a /dev/ufs/somelabel entry in fstab) the entry of the root fs will show in /dev/ufs/. And so will all the other UFS labels, just as they did before.
    5. Each time FreeBSD is booted using the /dev/ada0xxx notation in fstab, the entry of the root fs is missing from the /dev/ufs/ directory as long as the fs is mounted RW. The actual UFS label is still on the disk and can be verified via hexdump. With the root fs remounted as RO, its entry in /dev/ufs/ appears. Remount as RW, and its /dev/ufs/ entry vanishes again.
  • I don't think this was the intended behaviour. And I am considering to file this as a bug.
Comments are very much appreciated.
 
Last edited:
Keve said:
The comment of Labeling a read-only filesystem seems weird until you realize that the label isn’t part of the filesystem may cause some misunderstanding/confusion. Right there, you are actually working with UFS labels. And UFS labels -as the name suggests- are very much part of the filesystem.
Click to expand...
They are metadata, not actually part of the filesystem. That's why they can be changed on a read-only filesystem.

I don't know the mechanism that was causing labels to be lost, but others noted it at the time. It's possible that has been fixed in the meantime. (Incidentally, 9.2 is three years old now.)

The later questions seem to revolve around GEOM devices "withering". That is, when a device is mounted, other labels or paths to that device disappear because it is mounted. This has never seemed entirely consistent to me. Some device names or labels remain visible. However, I've been told that there is no inconsistency. There was some "these are not the droids you're looking for handwaving" and I don't recall the rest of that explanation.
 
wblock@ said:
They are metadata, not actually part of the filesystem. That's why they can be changed on a read-only filesystem.
Click to expand...
What confuses me is the fact that this metadata is stored INSIDE the filesystem, not outside of it. For example, the GPT label of a freebsd-ufs volume ada0p3 is NOT actually stored inside the filesystem one creates with newfs ada0p3. That GPT label is stored on ada0, but outside the area of ada0p3. So if I do a dd if=/dev/zero of=/dev/ada0p3 the GPT label survives. So the GPT label is NOT part of the filesystem. I couldn't make that statement about an UFS label. Metadata or not, it lives in the filesystem area. Or at least it looks that way.

wblock@ said:
when a device is mounted, other labels or paths to that device disappear because it is mounted
Click to expand...
Looks like this is right. If I mount() any UFS-labelled volume in RW mode using its /dev/adaXsY name, the corresponding entry vanishes from /dev/ufs/. Unmounting it brings the vanished entry back. If I mount the same volume using its /dev/ufs/labelHere name, its entry in /dev/ufs/ remains.
As you said, this IS the intended behaviour, so now I just need to understand the WHY behind this logic.
The only thing I can think of is that once the volume is mounted using its /dev/adaXsY name, its entry vanishes from /dev/ufs/ so that you cannot accidentally refer to it. But, if that is something to avoid, then the /dev/adaXsY entry should also vanish. If that doesn't disappear, then the chances of e.g. trying to mount the same volume again using the adaX name is the same as using the ufs-volume name. Also, if the /dev/ufs/ entry remains when the volume is mounted using that name, then by the same rationale, the /dev/adaXsY entry should vanish, right?
So I am still not getting how somebody considers the current behaviour to be logical, sensible and intended. What is the danger in keeping that /dev/ufs/ entry there after the volume is mounted as /dev/adaXsY?
 
The UFS labels are metadata, stored separately from files. Yes, it's stored in the UFS are, but not as a file, which is why it can be changed when the filesystem is not mounted. GPT labels are part of the partitioning, not built into any filesystem.

UFS withering makes sense. When something is mounted, nothing else should be able to mount it. In fact, nothing else should even be able to see it. But as you saw, not all the device entries wither. I decided to ignore that rather than try to figure it out.
 
Apparently the trouble is when people run into this behaviour, they find it defying normal logic, they get confused, and they believe it to be an error (rightfully so, in my opinion). It happened to me, happened to sprok, so it seems reasonable enough to assume that it can/will mislead others too. This is far from being a critical issue, I would rather file it in the annoying set. But as we have already spent a considerable amount of time and effort to investigate and analyse the nature of the issue, we should try to make some sort of permanent improvement out of it.
I see two equally satisfying ways to turn this discussion into something that improves FreeBSD:
  • File this as a bug and expect the developer team to admit that the current behaviour is not consistent, and hope to get it fixed.
  • Add our findings to an appropriate section of the documentation, so when users run into this behaviour they will know or can learn what is going on.
Warren, how do you think the devteam would take such a bug report?
 
Keve said:
Warren, how do you think the devteam would take such a bug report?
Click to expand...
Well, it probably wouldn't do any harm. Documenting a behavior is not difficult, either, provided the system being documented is understood.
 
You must log in or register to reply here.
Back
Top