Linux – How do commands like fdisk -l find the sector size

Your multipath'ed device is just an abstraction of multiple paths to one disk. So the corresponding relationship you are asking about is that the mpathN device is the same as the underlying device at the far end of whatever fabric you have.

As you saw, you can view the partition table on the mpath device and it's constituent members and see the same layout.

Some folks see a similarity between the concepts of multipath and RAID1. They are not related, but I've found it a useful comparison. The underlying devices of a multipath device are not duplicate copies as in RAID1. They are just parallel attachments to the same, typically remote, disk/LUN.

Regarding your question about how the partitions are mounted, they are mounted as they could be without multipath (assuming devices aren't hardcoded in fstab and lvm.conf). So you have mpath0p1 mounted at /boot. In your case -- if these devices were not managed by multipathd -- this is the same as mounting /dev/sda1 at /boot (and in your example, sdi1, sdd1, or sdl1 could be substituted for sda1). The difference is that if your fiber (or whatever) connection that presents sda1 is disconnected, your disk will still be accessible, using the multipath driver, via sdd, sdi and sdl.

In this case, you have the first partition of the remote disk mpath0 mounted at /boot, the first partition of disk mpath2 at /u02. The second partition in your fdisk output of sda is marked as an LVM physical partition. Presumably this contains the volume group VolGroup00 and in turn the logical volume LogVol00, which is mounted at /

man blockdev

   --setbsz bytes
          Set blocksize. Note that the block size is specific to the  cur‐
          rent  file descriptor opening the block device, so the change of
          block size only persists for as long as blockdev has the  device
          open, and is lost once blockdev exits.

In block/ioctl.c:

case BLKBSZGET: /* get block device soft block size (cf. BLKSSZGET) */
    return put_int(arg, block_size(bdev));
case BLKSSZGET: /* get block device logical block size */
    return put_int(arg, bdev_logical_block_size(bdev));
case BLKPBSZGET: /* get block device physical block size */
    return put_uint(arg, bdev_physical_block_size(bdev));

So BSZ reported by blockdev is neither logical nor physical block size. It is the "soft block size".

Looking at this code, the part about soft block size being specific to the file descriptor does not appear to make sense. Nor does wanting to set that with blockdev, given that no other option is documented in terms of blocks (only fixed-size 512 byte sectors).

In my own tests, what actually happens is that BSZ is preserved for as long as any process holds the block device open. It looks like it gets reset on the last close().

Parted got confused by this too some years ago

belay that. BLKBSZGET is the kernel's chosen block size it will use to access the device (for normal disks turns out this is 1k, for ata_ram this is 4k), which is not the underlying disk's logical block size. :-( So we will likely need another ioctl() to get the right value from the kernel, and BLKSSZGET may wind up being the disks's logical block size, while a new ioctl() exports the disk's physical sector size. ugh.

Another quirk:

On Wed, Apr 09, 2003 at 06:53:17PM +0200, Rob van Nieuwkerk wrote:

I get 4096 with BLKBSZGET on several unmounted partitions on my system (RH 2.4.18-27.7.x kernel). Some give 1024 .. Maybe it is because I had them mounted first and unmounted them for the test ?

That would be the most likely answer. When you unmount, I don't believe the filesystem bothers to set_blocksize(get_hardsect_size(dev)).