* Fwd: Re: util-linux: libblkid: UDF superblock
@ 2014-12-04 19:42 Pali Rohár
2014-12-05 2:09 ` Dale R. Worley
0 siblings, 1 reply; 9+ messages in thread
From: Pali Rohár @ 2014-12-04 19:42 UTC (permalink / raw)
To: util-linux
[-- 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 --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Fwd: Re: util-linux: libblkid: UDF superblock
2014-12-04 19:42 Fwd: Re: util-linux: libblkid: UDF superblock Pali Rohár
@ 2014-12-05 2:09 ` Dale R. Worley
2014-12-05 2:25 ` Pali Rohár
0 siblings, 1 reply; 9+ messages in thread
From: Dale R. Worley @ 2014-12-05 2:09 UTC (permalink / raw)
To: Pali Rohár; +Cc: util-linux
Pali Rohár <pali.rohar@gmail.com> writes:
>> 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Fwd: Re: util-linux: libblkid: UDF superblock
2014-12-05 2:09 ` Dale R. Worley
@ 2014-12-05 2:25 ` Pali Rohár
2014-12-09 10:35 ` Karel Zak
0 siblings, 1 reply; 9+ messages in thread
From: Pali Rohár @ 2014-12-05 2:25 UTC (permalink / raw)
To: Dale R. Worley; +Cc: util-linux
[-- Attachment #1: Type: Text/Plain, Size: 1175 bytes --]
On Friday 05 December 2014 03:09:11 Dale R. Worley wrote:
> Pali Rohár <pali.rohar@gmail.com> writes:
> >> 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".
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Fwd: Re: util-linux: libblkid: UDF superblock
2014-12-05 2:25 ` Pali Rohár
@ 2014-12-09 10:35 ` Karel Zak
2014-12-09 11:11 ` Pali Rohár
2014-12-19 13:56 ` Karel Zak
0 siblings, 2 replies; 9+ messages in thread
From: Karel Zak @ 2014-12-09 10:35 UTC (permalink / raw)
To: Pali Rohár; +Cc: Dale R. Worley, util-linux
On Fri, Dec 05, 2014 at 03:25:06AM +0100, Pali Rohár wrote:
> On Friday 05 December 2014 03:09:11 Dale R. Worley wrote:
> > Pali Rohár <pali.rohar@gmail.com> writes:
> > >> 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".
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
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: Fwd: Re: util-linux: libblkid: UDF superblock
2014-12-09 10:35 ` Karel Zak
@ 2014-12-09 11:11 ` Pali Rohár
2014-12-09 21:08 ` Dale R. Worley
2014-12-19 13:56 ` Karel Zak
1 sibling, 1 reply; 9+ messages in thread
From: Pali Rohár @ 2014-12-09 11:11 UTC (permalink / raw)
To: Karel Zak; +Cc: Dale R. Worley, util-linux
[-- Attachment #1: Type: Text/Plain, Size: 2483 bytes --]
On Tuesday 09 December 2014 11:35:20 Karel Zak wrote:
> On Fri, Dec 05, 2014 at 03:25:06AM +0100, Pali Rohár wrote:
> > On Friday 05 December 2014 03:09:11 Dale R. Worley wrote:
> > > Pali Rohár <pali.rohar@gmail.com> writes:
> > > >> 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".
>
> 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
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).
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Fwd: Re: util-linux: libblkid: UDF superblock
2014-12-09 11:11 ` Pali Rohár
@ 2014-12-09 21:08 ` Dale R. Worley
0 siblings, 0 replies; 9+ messages in thread
From: Dale R. Worley @ 2014-12-09 21:08 UTC (permalink / raw)
To: util-linux
Pali Rohár <pali.rohar@gmail.com> writes:
> [...] 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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Fwd: Re: util-linux: libblkid: UDF superblock
2014-12-09 10:35 ` Karel Zak
2014-12-09 11:11 ` Pali Rohár
@ 2014-12-19 13:56 ` Karel Zak
2014-12-19 15:55 ` Pali Rohár
2014-12-22 10:53 ` Pali Rohár
1 sibling, 2 replies; 9+ messages in thread
From: Karel Zak @ 2014-12-19 13:56 UTC (permalink / raw)
To: Pali Rohár; +Cc: Dale R. Worley, util-linux
On Tue, Dec 09, 2014 at 11:35:20AM +0100, Karel Zak wrote:
> > 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.
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
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: Fwd: Re: util-linux: libblkid: UDF superblock
2014-12-19 13:56 ` Karel Zak
@ 2014-12-19 15:55 ` Pali Rohár
2014-12-22 10:53 ` Pali Rohár
1 sibling, 0 replies; 9+ messages in thread
From: Pali Rohár @ 2014-12-19 15:55 UTC (permalink / raw)
To: Karel Zak; +Cc: Dale R. Worley, util-linux
[-- Attachment #1: Type: Text/Plain, Size: 1536 bytes --]
On Friday 19 December 2014 14:56:08 Karel Zak wrote:
> On Tue, Dec 09, 2014 at 11:35:20AM +0100, Karel Zak wrote:
> > > 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.
>
> 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
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
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Fwd: Re: util-linux: libblkid: UDF superblock
2014-12-19 13:56 ` Karel Zak
2014-12-19 15:55 ` Pali Rohár
@ 2014-12-22 10:53 ` Pali Rohár
1 sibling, 0 replies; 9+ messages in thread
From: Pali Rohár @ 2014-12-22 10:53 UTC (permalink / raw)
To: Karel Zak; +Cc: Dale R. Worley, util-linux
[-- Attachment #1: Type: Text/Plain, Size: 1310 bytes --]
On Friday 19 December 2014 14:56:08 Karel Zak wrote:
> On Tue, Dec 09, 2014 at 11:35:20AM +0100, Karel Zak wrote:
> > > 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.
>
> 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
Karel, can you review last version of my patch?
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2014-12-22 10:53 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-12-04 19:42 Fwd: Re: util-linux: libblkid: UDF superblock Pali Rohár
2014-12-05 2:09 ` Dale R. Worley
2014-12-05 2:25 ` Pali Rohár
2014-12-09 10:35 ` Karel Zak
2014-12-09 11:11 ` Pali Rohár
2014-12-09 21:08 ` Dale R. Worley
2014-12-19 13:56 ` Karel Zak
2014-12-19 15:55 ` Pali Rohár
2014-12-22 10:53 ` Pali Rohár
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).