Fwd: Re: util-linux: libblkid: UDF superblock

["Pali Rohár" <pali.rohar@gmail.com>]

[-- Attachment #1: Type: Text/Plain, Size: 4075 bytes --]

----------  Forwarded Message  ----------

Subject: Re: util-linux: libblkid: UDF superblock
Date: Sunday 30 November 2014, 12:51:54
From: Pali Rohár <pali.rohar@gmail.com>
To: Karel Zak <kzak@redhat.com>

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

-- 
Pali Rohár
pali.rohar@gmail.com

-----------------------------------------

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]