Re: [PATCHv5 00/14] dm-zoned: metadata version 2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 5/11/20 12:55 PM, Damien Le Moal wrote:
On 2020/05/11 11:46, Damien Le Moal wrote:
Mike,

I am still seeing the warning:

[ 1827.839756] device-mapper: table: 253:1: adding target device sdj caused an
alignment inconsistency: physical_block_size=4096, logical_block_size=4096,
alignment_offset=0, start=0
[ 1827.856738] device-mapper: table: 253:1: adding target device sdj caused an
alignment inconsistency: physical_block_size=4096, logical_block_size=4096,
alignment_offset=0, start=0
[ 1827.874031] device-mapper: table: 253:1: adding target device sdj caused an
alignment inconsistency: physical_block_size=4096, logical_block_size=4096,
alignment_offset=0, start=0
[ 1827.891086] device-mapper: table: 253:1: adding target device sdj caused an
alignment inconsistency: physical_block_size=4096, logical_block_size=4096,
alignment_offset=0, start=0

when mixing 512B sector and 4KB sector devices. Investigating now.


OK. Figured that one out: the 500GB SSD I am using for the regular device is
976773168 512B sectors capacity, that is, not a multiple of the 256MB zone size,
and not even a multiple of 4K. This causes the creation of a 12MB runt zone of
24624 sectors, which is ignored. But the start sector of the second device in
the dm-table remains 976773168, so not aligned on 4K. This causes
bdev_stack_limits to return an error and the above messages to be printed.

So I think we need to completely ignore the eventual "runt" zone of the regular
device so that everything aligns correctly. This will need changes in both
dmzadm and dm-zoned.

Hannes, I can hack something on top of your series. Or can you resend with that
fixed ?




Does this one help?

diff --git a/drivers/md/dm-zoned-target.c b/drivers/md/dm-zoned-target.c
index ea43f6892ced..5daca82b5ec7 100644
--- a/drivers/md/dm-zoned-target.c
+++ b/drivers/md/dm-zoned-target.c
@@ -1041,13 +1041,17 @@ static int dmz_iterate_devices(struct dm_target *ti,
 {
        struct dmz_target *dmz = ti->private;
        unsigned int zone_nr_sectors = dmz_zone_nr_sectors(dmz->metadata);
+       unsigned int nr_zones;
        sector_t capacity;
        int r;

-       capacity = dmz->dev[0].capacity & ~(zone_nr_sectors - 1);
+       nr_zones = DIV_ROUND_DOWN(dmz->dev[0].capacity, zone_nr_sectors);
+       capacity = nr_zones * zone_nr_sectors;
        r = fn(ti, dmz->ddev[0], 0, capacity, data);
        if (!r && dmz->ddev[1]) {
-               capacity = dmz->dev[1].capacity & ~(zone_nr_sectors - 1);
+               nr_zones = DIV_ROUND_DOWN(dmz->dev[1.capacity,
+                                                  zone_nr_sectors));
+               capacity = nr_zones * zone_nr_sectors;
                r = fn(ti, dmz->ddev[1], 0, capacity, data);
        }
        return r;

Cheers,

Hannes
--
Dr. Hannes Reinecke            Teamlead Storage & Networking
hare@xxxxxxx                               +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer


--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel




[Index of Archives]     [DM Crypt]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite Discussion]     [KDE Users]     [Fedora Docs]

  Powered by Linux