0

For every multipath disk label in /dev/mapper I have another with 1 in the end. Are they the same? is there some relationship?

For example:

/dev/mapper/mpathaj and /dev/mapper/mpathaj1 or /dev/mapper/mpathai and /dev/mapper/mpathai1

when I issue the command od --read-bytes=128 --format=c /dev/mapper/mpathai, the disk seems clean:

[root@server02 ~]# od --read-bytes=128 --format=c /dev/mapper/mpathai
0000000  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
*
0000200

But the other with 1 in the end show some rows:

[root@server02 ~]# od --read-bytes=128 --format=c /dev/mapper/mpathai1
0000000 001 202 001 001  \0  \0  \0  \0 003  \0  \0 200 220   .   5 213
0000020  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
0000120   3  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
   some characters I needed to remove to don't show costumer content.
0000160  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
0000200

That happen to every disk. One is clean and the other no.

And, the reason I am asking it: Can I lost one (mpathaj) without lost the other (mpathaj1)? I've seen they point to different /dev/dm-xx.

ie: /dev/mapper/mpathaj is /dev/dm-18 and /dev/mapper/mpathaj1 is /dev/dm-19

1 Answer 1

3

I would expect that /dev/mapper/mpathai to be the whole disk/LUN, and /dev/mapper/mpathai1 the first partition on that disk/LUN. But it also could be something like a LUKS encryption layer with a confusingly chosen name.

On device-mapper based devices (multipaths, encrypted disks, software RAID...), partition detection is done in userspace (often via the command kpartx), and a new device-mapper entry (/dev/dm-<number>) is created for each of them.

The only way to be sure would be to use dmsetup ls and/or dmsetup table as root to view the mappings and see their relations to each other.

On a modern Linux system, you might begin with dmsetup ls --tree -o blkdevname: it's probably the easiest way to visualize the relationships between the different device-mapper entries, if there are any.

Unfortunately, the dmsetup ls --tree listing won't include the type of mapping, so you may still need to refer to dmsetup table to identify the type: if the mapping of mpathai1 is of type linear and refers to the mpathai device by major:minor numbers, then mpathai1 is a linear sub-mapping of mpathai, which usually means it's a partition within the disk device.

If mpathai1 is of type crypt, then mpathai could be an encrypted disk (LUKS or some other method that is understood by cryptsetup), which has been configured to have the decrypted view of the device appear as mpathai1 whenever encryption is unlocked. In other words, the encryption would be unlocked with a command like:

cryptsetup open /dev/mapper/mpathai mpathai1 --type <luks,loopaes,tcrypt,bitlk...>

If encryption is used, I would expect /etc/crypttab to also mention the device(s).

If you can't identify the mapping type on your own, please post the output of e.g. dmsetup table mpathai1 and dmsetup table mpathaj1.

If mpathaj1 is a partition of mpathaj, you could lose mpathaj1 by e.g. corrupting/overwriting the partition table. If the partition table no longer has a valid entry for the mpathaj1 partition, the system would no longer show it, even if the underlying disk mpathaj is 100% fine.

The same is true if mpathaj1 is the decrypted view of encrypted mpathaj, then if the encryption key (e.g. the encrypted master key within the LUKS header) is lost for any reason, you will no longer be able to unlock the encryption, and then mpathaj1 and all data within it are effectively lost to you.

4
  • You are right, it's a partition! but can I lose the mpathaj and not lose the mpathaj1 (partition)? I mean, overwrite mpathaj with redirect command (>)
    – Astora
    May 2, 2022 at 15:49
  • 1
    Since the partition is just a limited portion of the whole-disk device, if you write to mpathaj as much data as will fit, you will definitely overwrite everything that was in mpathaj1. But if you write less than 1 MiB, you might lose nothing but the partition table, which may be easy to recover with testdisk; most modern partitioning tools will place the beginning of the first partition exactly 1 MiB away from the beginning of the disk.
    – telcoM
    May 2, 2022 at 16:15
  • In this case, it was only some characters (maybe 10 or 15) and redirected with > to the device (the one without 1 in the end). This has happened yesterday, and no trouble until now. As I 've posted, the others seems clean as well, only the partition has data. Thanks for the help.
    – Astora
    May 2, 2022 at 16:55
  • 1
    10 or 15 characters starting from the beginning of the disk would only overwrite the beginning of the Master Boot Record boot code - and if it's not your boot disk, the boot code area (the first 446 bytes) is not used at all. The MBR-style partition table is in the last 68 bytes of the first 512-byte block. If you used GPT partitioning instead, the entire block #0 would be ignored by Linux as soon as it detected a valid GPT partition table starting from block #1... or the backup GPT partition table at the very last blocks on the disk.
    – telcoM
    May 2, 2022 at 22:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .