Hi Pali,

When you say udf requires a non-trivial amount of disk scanning,
how much do you mean?

Given that the cache of blkid output provides UTF8 labels and UUIDs for
all file systems why can't UDF just reply on those values?  Then udfinfo
can just be called once from udf::set_used_sector() to populate the file
system usage figures.

How much disk scanning does running "udflabel --utf8 /dev/ptn" take?
Could udf::read_label() just call it if we want to provide a udf
specific implementation.

Thanks,
Mike

Ok, I should have been more specific. For hard disk formatted by mkudffs when you know correct blocksize it is about 60 blocks. When you do not know blocksize, then you need for each blocksize test about 16 blocks. If UDF block size does not match logical sector size (or logical sector size is unknown), then there is nothing better as trying every possible blocksize and detect if it is UDF filesystem or not.

For hard disks formatted by other UDF utilities it should be similar number.

But, it is possible to prepare UDF structures on hard disk in such way, that whole disk scan would be needed. And it has exactly same as ISO9660 in Volume Recognition Sequence (it can be arbitrary long). Such disk would be probably unusable for normal things, but can cause problems. udfinfo has for each action upper limit how many blocks would read just to prevent whole disk scan. I think that it should not read more then 2000 or 3000 blocks.

On more places UDF use strategy "last win", therefore block where is stored label (Logical Volume Descriptor) is overridden by any following block. blkid read only first found block and ignore any later, therefore can provide incorrect (or better old) label. udfinfo is written to rather provide correct information at cost that it would read more disk blocks.

udflabel is doing exactly same thing as udfinfo, but just print label on stdout.

All above is about UDF on hard disk formatted by most standard or generic way.

UDF on sequentially written media (e.g. CD-R, DVD-R, BD-R) uses Virtual Allocation Table which is written at the last block and override some previous values (e.g. label). udfinfo support it, blkid not. And it is possible to "add" VAT also on hard disk (do not if it is a good idea or not), therefore it is more complicated to detect correct information about UDF filesystem.

So I wrote that it requires a non-trivial amount of disk scanning as on other filesystem all those information are generally available on fixed offset.

And also older versions of blkid have bug which cause that label incorrectly print (due to bug in blkid UDF encoding).

I've done some simple testing and find little benefit in avoiding
running udfinfo for a second time.

Test was: create a ~200 GiB UDF file system, put some data into it and
run udfinfo on it.  Target hardware was a spinning hard drive.

First run of udfinfo takes up to 0.5 seconds as the Linux kernel reads
the blocks from the hard drive.  Subsequent runs of udfinfo on the same
file system take on average 0.005 seconds because all the data is coming
from the Linux buffer cache.

Therefore there isn't the need to the extra complexity of the read_all()
method.  Please prepare a patch (or patchset) which just executes
udfinfo and udflabel for each call udf::set_used_sectors(), read_label()
and read_uuid() just as other file systems do.

Created attachment 366221 [details] [review]
Use udftools 2.0

Ok, I changed patch to not use/implement read_all().

But another disadvantage is if there are some problems/warnings, user would see all them 3 times (because every run produce same list of problems/warnings).

Created attachment 366253 [details] [review]
Use external tools udfinfo and udflabel for UDF file system (v3)

Here's Pali's patch updated as I intend to commit is a day or so.

Updates are:
* Makes a number of coding style changes to be more like the rest of
  GParted.
* Drops read_label() fallback of using udfinfo if udflabel is not
  available.  It is not like some other tools which changed executable
  named with different versions.  Both udfinfo and udflabel are
  available in the same version of udftools package.  I don't see a
  scenario that one is available and not the other.
* Cosmetic commit message update.

Successfully tested querying space usage, label and uuid querying and
updating on CentOS 6 w/ udftools 2.0 and Fedora 25 udftools 2.0.
As expected with older udftools (1.0.0b3) there's no space usage
reported and no changing the label or UUID.

Mike

From a quick visual inspection of the patch in comment #5, the updates look good to me.

The following patch has been pushed upstream ready for inclusion in the
next release of GParted.

Use external tools udfinfo and udflabel for UDF file system (#792052)
https://git.gnome.org/browse/gparted/commit/?id=2f532be9f973e2de9f259ec1c6ec29cff4d32815

Fine, looks good.

This enhancement was included in the GParted 0.31.0 release on March 19, 2018.