On 11/29/2016 04:23 PM, Jes Sorensen wrote: > Artur Paszkiewicz <artur.paszkiewicz@xxxxxxxxx> writes: >> On 11/29/2016 12:51 AM, Jes Sorensen wrote: >>>> @@ -3177,6 +3195,9 @@ static void getinfo_super_imsm(struct supertype *st, struct mdinfo *info, char * >>>> >>>> disk = &super->disks->disk; >>>> info->data_offset = total_blocks(&super->disks->disk) - reserved; >>>> + /* mpb anchor sector - see store_imsm_mpb() */ >>>> + info->sb_start = total_blocks(&super->disks->disk) - >>>> + ((2 * super->sector_size) >> 9); >>>> info->component_size = reserved; >>>> info->disk.state = is_configured(disk) ? (1 << MD_DISK_ACTIVE) : 0; >>>> /* we don't change info->disk.raid_disk here because >>> >>> Hi Artur, >>> >>> I have been sitting staring at the above for a while, and looking at >>> store_imsm_mpb() it is not clear to me what is meant to happen here. >>> >>> For 4k sector drives, aren't you pushing back sb_start way further than >>> you are for 512 byte sector drives? Ie. you are subtracting 16 sectors >>> for the 4k drive but only two sectors for the 512 byte sector drive? >>> >>> Maybe it's because it's Monday or I lost the last of my marbles, but >>> could you possibly enlighten me here please? >> >> Jes, >> >> You read it correctly. The reason for this is that the IMSM anchor is >> located in the second _logical_ sector from the end of the drive. So for >> 4k drives this will be 16 512-byte sectors from the end. > > I see, so the IMSM implementation uses 512 byte logical sectors on top > of 4k drives? Could I ask you to add a note explaining this in the code? IMSM uses logical (4k or 512b) sector sizes in the metadata, but mdadm implementation uses just 512 byte sectors. This is how it works since Pawel's 4k support patches - it converts 4k metadata internally to 512b sector values. Plus here the sb_start value is passed to the kernel, so it must be in 512 byte sectors. Sure, I can add a comment about this. Thanks, Artur -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
