> This commit is really hard to follow.  I wonder if it can be broken up
> to make it easier to review.  There seem to be at least two parts to
> the patch: (1) Changing the way that we detect if a device contains
> partitions.  (2) Changing the way that we filter out LDM partitions.

Agree. Splitted this commit to a series of more granular commits.

> "check_device", "check_partition" are really generic names.  Name the
> functions according to what they do, eg.  "is_not_partitioned_device".

Agree.

> > +and is_ignored_gpt_type gpt_type =
> > +  match gpt_type with
>
> You can write this as:
>
>   and is_ignored_gpt_type = function
>   | pattern -> result
>   | ...

I've got rid of separate function at all.

> > +  (* Windows Logical Disk Manager metadata partition. *)
> > +  | "5808C8AA-7E8F-42E0-85D2-E1E90434CFB3" -> Optgroups.ldm_available ()
> > +  (* Windows Logical Disk Manager data partition. *)
> > +  | "AF9B60A0-1431-4F62-BC68-3311714A69AD" -> Optgroups.ldm_available ()
>
> Why does the result depend on Optgroups.ldm_available ()?

Yes, it shouldn't.

> > +  (* Microsoft Reserved Partition. *)
> > +  | "E3C9E316-0B5C-4DB8-817D-F92DF00215AE" -> true
> > +  (* Windows Snapshot Partition. *)
> > +  | "CADDEBF1-4400-4DE8-B103-12117DCF3CCF" -> true
>
> You can combine the right hand sides of multiple matches, which helps
> the pattern match optimizer in the compiler, eg:
>
>   (* Microsoft Reserved Partition. *)
>   | "E3C9E316-0B5C-4DB8-817D-F92DF00215AE"
>   (* Windows Snapshot Partition. *)
>   | "CADDEBF1-4400-4DE8-B103-12117DCF3CCF" -> true
>   | _ -> false

Ah, thanks.

> Catching the generic exception is usually a big red flag.  What
> exceptions are you expecting here?  If you're not expecting an
> exception, don't try to catch anything.

Agree. There is no expected exceptions there.
I thought: If something went wrong - let's not filter out device or partition.

v6 is coming.

--
  Mykola Ivanets