Setting Partition Type To 0x7

0 views

Skip to first unread message

Marsilius Boa

unread,

Aug 3, 2024, 4:18:37 PM8/3/24

to sinletzcenliu

This command is intended for use by original equipment manufacturers (OEMs) only. Changing partition type fields with this parameter might cause your computer to fail or be unable to boot. Unless you are an OEM or experienced with gpt disks, you should not change partition type fields on gpt disks by using this parameter. Instead, always use the create partition efi command to create EFI system partitions, the create partition msr command to create Microsoft Reserved partitions, and the create partition primary command without the ID parameter to create primary partitions on gpt disks.

Four-digit (two-byte hexadecimal) partition type codes are, AFAIK, unique to my GPT fdisk (gdisk, sgdisk, and cgdisk) program and any programs that might mimic it. (The fdisk clone in busybox is one of these, IIRC.) These codes are not industry-standard; I created them just because I needed a compact way to describe partition types and to accept partition typing data from users. GPT actually uses 16-byte GUIDs as type codes, and those are very awkward, from a user interface perspective!

GPT fdisk does not have a type code of "DA00," so any documentation that refers to such a code is either flawed or is referring to something other than my GPT fdisk. (Somebody might have a patched version of GPT fdisk that implements such a code, though.)

AFAIK, there's no such thing as a generic "non-FS" partition type for GPT. The most complete list of GPT type codes I'm aware of is on the Wikipedia entry on GPT, and I don't see anything close to that meaning in its table.

According to this site, which holds a good list of known MBR type codes, 0xDA is the MBR type code for "non-FS data." Given the way I create GPT fdisk type codes, that would translate to DA00 if there were a GPT equivalent. Since there is no GPT equivalent, though, DA00 remains invalid in GPT fdisk.

Tools based on libparted, such as parted and GParted, do a terrible job at presenting partition type code data to users. I've just skimmed it, but the page to which you refer, s1ln7m4s7r, appears to set up RAID data on a partition with a GUID of EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 -- "Microsoft Basic Data". That is, the RAID partition will be flagged as holding an NTFS or FAT filesystem! That's one of the worst possible ways to set up a Linux RAID, in terms of its partition type code.

For the most part, Linux doesn't care about type codes, on either MBR or GPT. There are a few exceptions to this rule, though. Thus, on a Linux-only system, using a bad partition type code won't have dire consequences; but on a dual-boot system, or if the disk gets moved to another computer for some reason, a bad type code choice could result in data loss. Windows might try to reformat the partition to use NTFS, for instance.

The Linux RAID partition type code (GUID A19D880F-05FC-4D3B-A006-743F0F84911E on GPT; represented in GPT fdisk as FD00) was created to hold RAID data. Although I do recall running across advice somewhere to not use this type code for RAID data, I honestly don't recall what the reason was, but my recollection is that I was unimpressed.

Since you didn't post a link to the page that recommended using "DA00" for RAID devices, Nairou, I can't comment on that advice in context; however, I suspect the author was confused or that the wiki went through some edits and something got mangled. Unless somebody can provide a good reason otherwise, I recommend using the RAID data type code on a partition that holds RAID data. If you want to use something else, create your own random GUID; do not use the type code for a Microsoft filesystem, especially if the computer dual-boots with Windows!

Humble apologies for resurecting this, but I stumbled upon this thread as one of the top Google searches when looking for more info on 0xDA, and the above post by srs5694, which makes some very solid points, kind of clashes with info I saw on kernel.org

I have inherited a few LVM volumes and I noticed that fdisk reports the disks that make up the volume group as partition type 83 (Linux) and not 8e (Linux LVM). Is this a problem and how important are the fdisk partion types? Do they affect anything or are they just labels for convenience sake? Thanks for your help.

LVM does not look at the partition table at all - it doesn't even knows it actually exist.So you can set whatever "partition type" value you want there and it won't change anything as far as LVM is concerned.

The partition type is not important for lvm, md or mount. All of them are checking for signatures and internal structures to determine if they can use the device. Only user friendly partitioning programs might get confused. You can safely change the partition type if you want to be correct.

I think it is better not to use MS-DOS disk-label (partition table) at all if the disk is the 2nd disk in the system and you intend to use LVM. You can use LVM disk-label directly on the disk. For x86 and x64 architecture you need to use MS-DOS partitions (or GPT for UEFI systems) for boot disk, but the rest can have the LVM disk-label directly on the unpatitioned disk.

Use table settings to specify any settings that you want to apply to a selected table or view for a specified operation. Table-settings rules are optional, depending on your endpoint and migration requirements.

Instead of using tables and views, MongoDB and Amazon DocumentDB databases store data records as documents that are gathered together in collections. A single database for any MongoDB or Amazon DocumentDB endpoint is a specific set of collections identified by the database name.

When migrating from a MongoDB or Amazon DocumentDB source, you work with parallel load settings slightly differently. In this case, consider the autosegmentation or range segmentation type of parallel load settings for selected collections rather than tables and views.

If it is, this parameter also specifies the mechanism to identify the table or view partitions, subpartitions, or other segments to load in parallel. Partitions are segments that are already defined and identified by name in the source table or view.

For MongoDB and Amazon DocumentDB endpoints, partitions are segments. AWS DMS can calculate these automatically given associated autosegmentation parameters. Or you can specify these manually using range segmentation parameters.

For Oracle endpoints only, subpartitions are an additional level of segments that are already defined and identified by name in the source table or view. You can identify other segments in the table-settings rule by specifying boundaries in the range of values for one or more table or view columns.

PostgreSQL endpoints support only this type of a parallel load. MongoDB and Amazon DocumentDB as a source endpoints support both this range segmentation type and the autosegmentation type of a parallel full load (partitions-auto).

In addition, AWS recommends that you don't load a great number of large collections using a single task with parallel-load. Note that AWS DMS limits resource contention as well as the number of segments loaded in parallel by the value of the MaxFullLoadSubTasks task settings parameter, with a maximum value of 49.

Instead, specify all collections for your source database for the largest collections by specifying each "schema-name" and "table-name" individually. Also, scale up your migration properly. For example, run multiple tasks across a sufficient number of replication instances to handle a great number of large collections in your database.

To speed up migration and make it more efficient, you can use parallel load for selected relational tables, views, and collections. In other words, you can migrate a single segmented table, view, or collection using several threads in parallel. To do this, AWS DMS splits a full-load task into threads, with each table segment allocated to its own thread.

Using this parallel-load process, you can first have multiple threads unload multiple tables, views, and collections in parallel from the source endpoint. You can then have multiple threads migrate and load the same tables, views, and collections in parallel to the target endpoint. For some database engines, you can segment the tables and views by existing partitions or subpartitions. For other database engines, you can have AWS DMS automatically segment collections according to specific parameters (autosegmentation). Otherwise, you can segment any table, view, or collection by ranges of column values that you specify.

MaxFullLoadSubTasks controls the number of tables or table segments to load in parallel. ParallelLoadThreads controls the number of threads that are used by a migration task to execute the loads in parallel. These settings are multiplicative. As such, the total number of threads that are used during a full load task is approximately the result of the value of ParallelLoadThreads multiplied by the value of MaxFullLoadSubTasks (ParallelLoadThreads * MaxFullLoadSubtasks).

To specify the maximum number of threads per table for Amazon DynamoDB, Amazon Kinesis Data Streams, Apache Kafka, or Amazon Elasticsearch Service targets, use the ParallelLoadThreads target metadata task setting.

For more information about the ParallelLoadThreads and ParallelLoadBufferSize settings, see Target metadata task settings. For more information about the MaxFullLoadSubTasks setting, see Full-load task settings. For information specific to target endpoints, see the related topics.

To use parallel load, create a table-mapping rule of type table-settings with the parallel-load option. Within the table-settings rule, you can specify the segmentation criteria for a single table, view, or collection that you want to load in parallel. To do so, set the type parameter of the parallel-load option to one of several options.