[parted-devel] [PATCH] libparted: Add support for MBR id and GPT GUID of UDF filesystem

Phillip Susi psusi at ubuntu.com
Thu Aug 23 18:18:58 BST 2018


On 8/23/2018 12:53 PM, Pali Rohár wrote:
> UDF must have VRS and AVDP. So first check if there is VRS. Check for
> AVDP does not make sense if VRS was not detected (VRS = Volume

Right... with you so far.

> Recognition Sequence). And normally AVDP should be at block 256 (but
> other 3 locations are possible too). So algorithm is:
> 
> for possible AVDP locations do:
>     for every valid block size do:
>         if there is no valid VRS for block size:
>             continue
>         if AVDP at location for block size is missing:
>             continue
>         report valid UDF with block size
> 
> But to prevent calling detection of VRS multiple times for different
> AVDP location, result of VRS detection is cached.

Right... you only need to check for vrs once per block size...

> And because size of VSD is min(2048, block size), detection for VRS with
> block sizes 512 - 2048 is same too.

Wait... the *size* of the vsd is min(2048, block size), but it's
*offset* is still a multiple of block size isn't it?  So only if it is
in block 0 will it look the same for 512-2048 block size right?  If it
is in some other block then it won't be detected for all 3 block sizes.

> So 3 loops is just optimization. First one checks VRS for block size 512
> - 2048 with (the most common) AVDP location 256. Second loop checks VRS

I see.  If the vrs *offset* is also always at a multiple of
min(2048,block size), then all 64 possible locations for the 3 sizes are
the same, so you only need to probe 2048 and check the two smaller sizes
too.

> and AVDP 256 for higher block sizes and last loop use cached result of
> VRS and checks remaining (less common) AVDP location for every block
> size.

So you are trying to check only the most common anchor position first
for each detected block size so that if one or two vrs checks were false
positives, you don't waste as much time checking the other 3 anchor
locations?

This will result in slightly less IO needed to correctly detect most
valid udf filesystems, but most of the time you are going to be probing
something that isn't udf, so you're still going to have to check all of
the less likely locations anyhow, so I think the optimization isn't
really worth the increased complexity.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/parted-devel/attachments/20180823/1bfcc18c/attachment.sig>


More information about the parted-devel mailing list