AWS EBS卷的ZFS ashift属性

Question

AWS EBS卷的实际物理扇区大小是多少？

EBS将physical_block_size和logical_block_size作为512通告给OS

ubuntu@ip-172-31-28-17:~$ cat /sys/block/xvdi/queue/physical_block_size 
512
ubuntu@ip-172-31-28-17:~$ cat /sys/block/xvdi/queue/logical_block_size 
512

我们正在从RDS迁移到Postgres到EC2实例（带有压缩的EBS上的ZFS）。在创建zpool时，没有给出ashift值

ubuntu@ip-172-31-28-17:~$ sudo zpool create pgstripe /dev/xvdf1 /dev/xvdg1 /dev/xvdh1 /dev/xvdi1
....
ubuntu@ip-172-31-28-17:~$ sudo zpool get ashift
NAME      PROPERTY  VALUE   SOURCE
pgstripe  ashift    0       default

据说ashift=9的价值可能会影响现代存储设备的性能。因此，在验证ashift为游泳池的实际价值时，发现它确实是ashift=9

ubuntu@ip-172-31-28-17:~$ sudo zdb -U /etc/zfs/zpool.cache 
pgstripe:
    version: 5000
    name: 'pgstripe'
    state: 0
    txg: 21518
    pool_guid: 18259321190878592884
    errata: 0
    hostname: 'ip-172-31-28-17'
    vdev_children: 4
    vdev_tree:
        type: 'root'
        id: 0
        guid: 18259321190878592884
        create_txg: 4
        children[0]:
            type: 'disk'
            id: 0
            guid: 6596053233879303485
            path: '/dev/xvdf1'
            whole_disk: 0
            metaslab_array: 39
            metaslab_shift: 31
            ashift: 9
            asize: 322116780032
            is_log: 0
            create_txg: 4
        children[1]:
            type: 'disk'
            id: 1
            guid: 10755479908569617562
            path: '/dev/xvdg1'
            whole_disk: 0
            metaslab_array: 37
            metaslab_shift: 31
            ashift: 9
            asize: 322116780032
            is_log: 0
            create_txg: 4
        children[2]:
            type: 'disk'
            id: 2
            guid: 7517133622037333375
            path: '/dev/xvdh1'
            whole_disk: 0
            metaslab_array: 36
            metaslab_shift: 31
            ashift: 9
            asize: 322116780032
            is_log: 0
            create_txg: 4
        children[3]:
            type: 'disk'
            id: 3
            guid: 17044638243598443214
            path: '/dev/xvdi1'
            whole_disk: 0
            metaslab_array: 34
            metaslab_shift: 31
            ashift: 9
            asize: 322116780032
            is_log: 0
            create_txg: 4
    features_for_read:
        com.delphix:hole_birth
        com.delphix:embedded_data

所以来到实际的问题

1. ebs卷的实际块大小是多少？
2. ashift=9是否已针对基础EBS卷进行了优化？
3. 对于EBS，考虑到zfs总是在128K块中执行i / o，ashift=12在ashift=9池上的性能会比recordsize=128K更高吗？

已经使用此默认值ashift完成了postgres负载测试，因此将使用显式ashift=12重复相同的操作。

Answer 1

对于EBS，物理磁盘扇区大小完全被抽象掉了。 EBS卷是联网的附加存储。该存储可包含数千个磁盘驱动器。现代SAN控制器可以同时支持多种类型的磁盘驱动器。

在今天的磁盘驱动器中，报告的物理扇区大小为512字节和4096字节。然而，这仅仅是一种寻址方案，因为轨道大小决定了性能。磁盘外磁道上的磁道大小大于内磁道上的磁道大小。某些磁盘驱动器会增加内部磁道的BPI，但这会产生更高错误率的副作用。

如果您认为可以根据某些理论扇区大小优化EBS卷，那么您就错了。你在这个瞬间看到的数字明天可能会完全不同。诸如控制器，网络延迟，网络速度，到物理驱动器的距离等因素都具有相互作用。

使用更大的块大小可以获得更好的结果。实际的物理部门规模不再是一个相关的概念。此外，您无法控制AWS向VM报告的“逻辑”物理扇区大小。