NetApp
filesystem alignment for block storage
Describe the bug
Use proper mkfs.foo commands to align fs with underlying block properties.
Environment Provide accurate information about the environment to help us reproduce the issue.
- Trident version: [e.g. 20.01]
- Trident installation flags used: [e.g. -d -n trident --use-custom-yaml]
- Container runtime: [e.g. Docker 19.03.1-CE]
- Kubernetes version: [e.g. 1.15.1]
- Kubernetes orchestrator: [e.g. OpenShift v3.11, Rancher v2.3.3]
- Kubernetes enabled feature gates: [e.g. CSINodeInfo]
- OS: [e.g. RHEL 7.6, Ubuntu 16.04]
- NetApp backend types: [ONTAP]
- Other:
To Reproduce Steps to reproduce the behavior:
Create a PVC. Observe the properties of the block device and filesystem.
[root@na01lstxwebt10 dev]# fdisk -l /dev/mapper/3600a098038303462343f464f77446761
Disk /dev/mapper/3600a098038303462343f464f77446761: 31 MB, 31457280 bytes, 61440 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 65536 bytes
[root@na01lstxwebt10 ~]# dumpe2fs -h /dev/mapper/3600a098038303462343f464f77446761
dumpe2fs 1.42.9 (28-Dec-2013)
Filesystem volume name: <none>
Last mounted on: /mnt/data
Filesystem UUID: 80332748-ec34-4d51-a878-6523b3014b89
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: signed_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 7680
Block count: 30720
Reserved block count: 1536
Free blocks: 27990
Free inodes: 7669
First block: 1
Block size: 1024
Fragment size: 1024
Group descriptor size: 64
Reserved GDT blocks: 239
Blocks per group: 8192
Fragments per group: 8192
Inodes per group: 1920
Inode blocks per group: 240
RAID stride: 4
RAID stripe width: 64
Flex block group size: 16
Filesystem created: Tue Apr 14 12:42:47 2020
Last mount time: Tue Apr 14 12:42:47 2020
Last write time: Tue Apr 14 12:42:47 2020
Mount count: 1
Maximum mount count: -1
Last checked: Tue Apr 14 12:42:47 2020
Check interval: 0 (<none>)
Lifetime writes: 1352 kB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: 2a9f2a8a-15d0-4572-ada3-9cd5fca4718c
Journal backup: inode blocks
Journal features: journal_64bit
Journal size: 1024k
Journal length: 1024
Journal sequence: 0x00000002
Journal start: 1
Expected behavior
Block size et al follow applicable best practices as described here: https://kb.netapp.com/app/answers/answer_view/a_id/1035691/~/how-to-create-aligned-partitions-in-linux-for-use-with-netapp-luns%2C-vmdks%2C-vhds
Obviously partitioning is not happening, but fs creation may be applicable.
Additional context
It may be nice to implement this as a generic parameter on the storage class(es) where additional args can be specified for the mkfs.<fsType> as appropriate.
@travisghansen thanks for doing the research on this.
ONTAP blocks are 4KB in size so overriding this to always be 4096 for ext4 and ext3 would be ideal. It isn't recommended to have a block size smaller than 4KB when using ONTAP.
We'll need to verify the block size for other Trident drivers.
@gnarl understood. xfs can be tweaked as well but looks like it defaults to 4k? I haven't tested this one yet.
- https://www.thegeekdiary.com/how-to-create-an-xfs-filesystem/
It may be nice to implement this as a generic parameter on the storage class(es) where additional args can be specified for the mkfs.<fsType> as appropriate.
Added with 1d5961d4fb65577857fbfdd3c3edfa05265a8559. Trident 24.10 supports filesystem format options as config parameters for ontap-san and ontap-san-economy backends. Other block drivers should follow. While primarily useful for fast formatting, other options like block size are supported by the mkfs tools.
