util-linux: libblkid: UDF superblock
---------- Forwarded Message ----------
Subject: Re: util-linux: libblkid: UDF superblock
Date: Sunday 30 November 2014, 12:51:54
From: Pali Rohár <[email protected]>
To: Karel Zak <[email protected]>
Quoted 69 lines · On Sunday 30 November 2014 12:36:49 Pali Rohár wrote:
Hello!
I looked at UDF specifications 1.50 [1] and 2.01 [2] and then on libblkid UDF superblock code.
If I understand libblkid udf code then it set LABEL string from Primary Volume Descriptor --> VolumeIdentifier. This field can be set by mkudffs --vid= option.
But in both UDF specifications for LogicalVolumeIdentifier is written:
===
This field is extremely important in logical volume identification when multiple media are present within a jukebox. This name is typically what is displayed to the user. ===LogicalVolumeIdentifier can be set by mkudffs --lvid= option.
About VolumeIdentifier (which is used by libblkid udf code) there is only one part in both specifications:
===
Part 3 ISO/IEC 13346 (in 2.01: ECMA 167) contains various Identifiers which, depending upon the implementation, maybe have to be presented to the user.
* VolumeIndentifier
===So I think that it is better to use LogicalVolumeIdentifier for libblkid LABEL. And not current VolumeIdentifier.
What do you think?
See also discussion about these identifiers at [3].
And I have another question. UDF does not support UUID identifiers. But in both specifications there is something which can be used. Read description about VolumeSetIdentifier:
===
Interpreted as specifying the identifier for the volume set.The first 16 characters of this field should be set to unique value. The remainder of the field may be set to any allowed value. Specifically, software generating volumes conforming to this specification shall not set this volume to a fixed or trivial value. Duplicate disks which are intended to be identical may contain the same value in this field.
NOTE: The intended purpose of this is to guarantee Volume Sets with unique identifiers. The first 8 characters of the unique part should come from CS0 hexadecimal representation of a 32-bit time value. The remaining 8 characters are fee for implementation use.
===So first 16 characters are good candidate for libblkid UUID. What do you think about it?
mkudffs set first 8 characters of VolumeSetIdentifier really to that time time. Next characters can be configured by mkudffs option --vsid=. Default is fixed "LinuxUDF". But we still have unique time identifier.
Quoted 5 lines
[1] - http://www.osta.org/specs/pdf/udf150.pdf
[2] - http://www.osta.org/specs/pdf/udf201.pdf
[3] -
http://superuser.com/questions/366808/in-udf-whats-the-differ
ence-between-a-volume-identifier-volume-set-identifier
Now I looked at newfs_udf implementation (part of UDFclient package [1], alternative to mkudffs) and it show this warning message
newfs_udf: no logical volume name passed; not creating logical volume descriptor
if you do not set -L option:
-L volumename use `volumename' as logical volume name (discname)
which is presented as discname -- good candidate for LABEL. That volumename is LogicalVolumeIdentifier what I suggested to use as LABEL in previous name.
By default VolumeIdentifier (option -P) is set to some random garbage and blkid identify UDF disk as:
/dev/loop0: LABEL="555e3160" TYPE="udf"
(I set volumename to human readable disk name)
So now I think that linux blkid should for LABEL use LogicalVolumeIdentifier instead VolumeIdentifier.
newfs_udf set by default for VolumeSetIdentifier some random 8 chars (not 16!) but allows you to set also first 8 by option -S. mkudffs does not allow you to set first 8 chars. They are always time stamp.
[1] - http://www.13thmonkey.org/udfclient/
Signature · 4 lines
Pali Rohár [email protected] -----------------------------------------
Quoted 4 lines · Pali Rohár
Quoted 4 lines
So I think that it is better to use LogicalVolumeIdentifier for libblkid LABEL. And not current VolumeIdentifier.
What do you think?
If you change how the LABEL value is read from the disk, every user will see different LABEL values than they saw in the past.
Dale
Quoted 11 lines · On Friday 05 December 2014 03:09:11 Dale R. Worley wrote:
Quoted 4 lines · Pali Rohár
Quoted 4 lines
So I think that it is better to use LogicalVolumeIdentifier for libblkid LABEL. And not current VolumeIdentifier.
What do you think?
If you change how the LABEL value is read from the disk, every user will see different LABEL values than they saw in the past.
Dale
Yes, but apparently other systems are using LABEL from LogicalVolumeIdentifier. So now you see different labels on different systems which is not good too.
Also that bsd project UDFclient (which is working on Linux too!) is using LogicalVolumeIdentifier as volume/disk name in newfs_udf tool.
I looked into grub2 code and it is identifying UDF label also from LogicalVolumeIdentifier. So if you want to boot something from UDF FS via grub you probably see label problems...
So I think that rather than using broken linux implementation is better to fix it (which could bring problems with different label names in new version). And I would like to see human readable label as "555e3160".
Signature · 2 lines
Pali Rohár [email protected]
Karel Zak
maintainerQuoted 21 lines · Pali Rohár
Quoted 11 lines · On Friday 05 December 2014 03:09:11 Dale R. Worley wrote:
Quoted 4 lines · Pali Rohár
Quoted 4 lines
So I think that it is better to use LogicalVolumeIdentifier for libblkid LABEL. And not current VolumeIdentifier.
What do you think?
If you change how the LABEL value is read from the disk, every user will see different LABEL values than they saw in the past.
Dale
Yes, but apparently other systems are using LABEL from LogicalVolumeIdentifier. So now you see different labels on different systems which is not good too.
Also that bsd project UDFclient (which is working on Linux too!) is using LogicalVolumeIdentifier as volume/disk name in
newfs_udftool.
Quoted 8 lines
I looked into grub2 code and it is identifying UDF label also from LogicalVolumeIdentifier. So if you want to boot something from UDF FS via grub you probably see label problems...
So I think that rather than using broken linux implementation is better to fix it (which could bring problems with different label names in new version). And I would like to see human readable label as "
555e3160".
It's more important to not introduce regression, if you have LABEL= in your fstab then you don't want to see that after util-linux update your setting is obsolete and filesystem unmounted.
It would be possible use another header field (LogicalVolumeIdentifier) for LABEL= only if the currently used field is empty.
Karel
Signature · 2 lines
Karel Zak <[email protected]> http://karelzak.blogspot.com
Quoted 38 lines · On Tuesday 09 December 2014 11:35:20 Karel Zak wrote:
Quoted 27 lines · Pali Rohár
Quoted 5 lines · On Friday 05 December 2014 03:09:11 Dale R. Worley wrote:
Quoted 4 lines · Pali Rohár
Quoted 4 lines
So I think that it is better to use LogicalVolumeIdentifier for libblkid LABEL. And not current VolumeIdentifier.
Quoted 7 lines
Quoted 1 line
Quoted 1 line
What do you think?
If you change how the LABEL value is read from the disk, every user will see different LABEL values than they saw in the past.
Dale
Yes, but apparently other systems are using LABEL from LogicalVolumeIdentifier. So now you see different labels on different systems which is not good too.
Also that bsd project UDFclient (which is working on Linux too!) is using LogicalVolumeIdentifier as volume/disk name in
newfs_udftool.I looked into grub2 code and it is identifying UDF label also from LogicalVolumeIdentifier. So if you want to boot something from UDF FS via grub you probably see label problems...
Quoted 4 lines
So I think that rather than using broken linux implementation is better to fix it (which could bring problems with different label names in new version). And I would like to see human readable label as "
555e3160".It's more important to not introduce regression, if you have LABEL= in your fstab then you don't want to see that after util-linux update your setting is obsolete and filesystem unmounted.
Quoted 5 lines
It would be possible use another header field (LogicalVolumeIdentifier) for LABEL= only if the currently used field is empty.
Karel
Karel, problem is that other software (for formatting udf fs) set VolumeIdentifier to some random string (like "555e3160"). Which means that in Linux we do not see correct LABEL. All other implementations which I saw are using LogicalVolumeIdentifier for LABEL (it is also written in specification). And more... grub2 read LABEL from LogicalVolumeIdentifier, so you cannot specify UDF disk by its LABEL from linux for grub2. I think this is bug in util-linux which needs to be fixed. I understand that there could be regressions, but current implementation is not correct (it show wrong labels "555e3160"; show different as other systems; is not correct according to specification).
Signature · 2 lines
Pali Rohár [email protected]
Quoted 9 lines · Pali Rohár
[...] All other
implementations which I saw are using LogicalVolumeIdentifier for LABEL (it is also written in specification). And more... grub2 read LABEL from LogicalVolumeIdentifier, so you cannot specify UDF disk by its LABEL from linux for grub2. I think this is bug in util-linux which needs to be fixed. I understand that there could be regressions, but current implementation is not correct (it show wrong labels "555e3160"; show different as other systems; is not correct according to specification).
This is a messy problem to handle correctly, and I think that to bring about a good solution will take a considerable amount of research. The ultimate goal is to make things work as well as possible. So it would be quite helpful to accumulate information:
1) Talk to people who work on various Un*x kernels to identify what they use for the LABEL value of UDF partitions. This includes auxiliary programs like Grub which function as their own kernel.
2) Start conversations with users and system packagers to identify how much disruption would be caused by changing the util-linux behavior.
3) Start conversations to find out what would be the ideal behavior if we were not constrained by history -- We want to move toward ideal behavior rather than away from it.
In many situations, conversations like this gradually come to a consensus as to what is the best direction of progress.
Dale
Karel Zak
maintainerQuoted 4 lines · Karel Zak
Quoted 4 lines
I looked into grub2 code and it is identifying UDF label also from LogicalVolumeIdentifier. So if you want to boot something from UDF FS via grub you probably see label problems...
Quoted 8 lines
Quoted 4 lines
So I think that rather than using broken linux implementation is better to fix it (which could bring problems with different label names in new version). And I would like to see human readable label as "
555e3160".It's more important to not introduce regression, if you have LABEL= in your fstab then you don't want to see that after util-linux update your setting is obsolete and filesystem unmounted.
You have convinced me that fix the problem (and improve compatibility) with UDF LABEL= is a good idea.
Not sure, but I guess that for many users the change will be invisible because preferred way is to read the LABEL from ISO9660 header and UDF specific LABEL is just fallback solution only.
The latest Pali's patches are at:
https://github.com/karelzak/util-linux/pull/135
Karel
Signature · 2 lines
Karel Zak <[email protected]> http://karelzak.blogspot.com
Quoted 24 lines · On Friday 19 December 2014 14:56:08 Karel Zak wrote:
Quoted 10 lines · Karel Zak
Quoted 9 lines
I looked into grub2 code and it is identifying UDF label also from LogicalVolumeIdentifier. So if you want to boot something from UDF FS via grub you probably see label problems...
So I think that rather than using broken linux implementation is better to fix it (which could bring problems with different label names in new version). And I would like to see human readable label as "
555e3160".Quoted 4 lines
It's more important to not introduce regression, if you have LABEL= in your fstab then you don't want to see that after util-linux update your setting is obsolete and filesystem unmounted.
You have convinced me that fix the problem (and improve compatibility) with UDF LABEL= is a good idea.
Not sure, but I guess that for many users the change will be invisible because preferred way is to read the LABEL from ISO9660 header and UDF specific LABEL is just fallback solution only.
Quoted 4 lines
The latest Pali's patches are at:
https://github.com/karelzak/util-linux/pull/135Karel
Now I played with Windows format.exe command and it set UDF ids:
Volume identifier: "UDF Volume"
Logical volume identifier: "<label_from_user>" Volume set identifier: "<8_hex_numbers> UDF Volume Set"
Windows shows in My Computer label from Logical volume identifier
Signature · 2 lines
Pali Rohár [email protected]
Quoted 24 lines · On Friday 19 December 2014 14:56:08 Karel Zak wrote:
Quoted 10 lines · Karel Zak
Quoted 9 lines
I looked into grub2 code and it is identifying UDF label also from LogicalVolumeIdentifier. So if you want to boot something from UDF FS via grub you probably see label problems...
So I think that rather than using broken linux implementation is better to fix it (which could bring problems with different label names in new version). And I would like to see human readable label as "
555e3160".Quoted 4 lines
It's more important to not introduce regression, if you have LABEL= in your fstab then you don't want to see that after util-linux update your setting is obsolete and filesystem unmounted.
You have convinced me that fix the problem (and improve compatibility) with UDF LABEL= is a good idea.
Not sure, but I guess that for many users the change will be invisible because preferred way is to read the LABEL from ISO9660 header and UDF specific LABEL is just fallback solution only.
Quoted 4 lines
The latest Pali's patches are at:
https://github.com/karelzak/util-linux/pull/135Karel
Karel, can you review last version of my patch?
Signature · 2 lines
Pali Rohár [email protected]