https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-14985 Lustre <p>There seems no way to change stride/stripe-width on an existing live ldiskfs OST LUN. We used incorrect stride/stripe-width with mkfs.lustre initially and now are seeing poor write performance. </p> <p>Is there a supported way of changing stride/stripe-width values?</p> RHEL7.9 LU-14985

Change stride/stripe-width on an existing ldiskfs filesystem

Bug Minor Open Unresolved WC Triage Joe Frith Sat, 4 Sep 2021 19:18:41 +0000 Sun, 5 Sep 2021 00:16:46 +0000 Lustre 2.12.7 0 2 <p>Is it safe to use tune2fs  -E stride=x,stripe-width=x on a mounted OST with data on it to change stride and stripe-size for a ldiskfs type OST device? </p> <p>It would be useful if you included the "<tt>dumpe2fs -h</tt>" output for the device. Yes, it is fine to change these on a running filesystem, they only affect new allocations. In the past they also used to affect inode and block bitmap location, but the <tt>flexbg</tt> feature overrides this. </p> <p>That said, it is likely that the <tt>mmp</tt> feature will prevent <tt>tune2fs</tt> from running while the filesystem is mounted. </p> <p>Here is the output of dumpe2fs. The RAID backend is (8+2) with 512K chunk size. I believe the correct values are "<br/> -E stride=128,stripe-width=1024". I will change it by unmounting the OSD.</p> <p> </p> <p> </p> <p> <span class="error">&#91;root@oss2 ~&#93;</span># dumpe2fs -h /dev/mapper/lustredisk01-01<br/> dumpe2fs 1.45.6.wc2 (28-Sep-2020)<br/> Filesystem volume name: data-OST0000<br/> Last mounted on: /<br/> Filesystem UUID: 8f25e350-6203-4ee9-9c1f-62e9c00c8ced<br/> Filesystem magic number: 0xEF53<br/> Filesystem revision #: 1 (dynamic)<br/> Filesystem features: has_journal ext_attr dir_index filetype needs_recovery extent 64bit mmp flex_bg sparse_super large_file huge_file uninit_bg dir_nlink quota<br/> Filesystem flags: signed_directory_hash<br/> Default mount options: user_xattr acl<br/> Filesystem state: clean<br/> Errors behavior: Continue<br/> Filesystem OS type: Linux<br/> Inode count: 89649152<br/> Block count: 22950182912<br/> Reserved block count: 1147509145<br/> Overhead clusters: 13015772<br/> Free blocks: 21513452873<br/> Free inodes: 89293588<br/> First block: 0<br/> Block size: 4096<br/> Fragment size: 4096<br/> Group descriptor size: 64<br/> Blocks per group: 32768<br/> Fragments per group: 32768<br/> Inodes per group: 128<br/> Inode blocks per group: 16<br/> RAID stride: 32<br/> RAID stripe width: 256<br/> Flex block group size: 256<br/> Filesystem created: Sat Dec 19 13:16:33 2020<br/> Last mount time: Mon Jun 14 15:10:54 2021<br/> Last write time: Mon Jun 14 15:10:54 2021<br/> Mount count: 13<br/> Maximum mount count: -1<br/> Last checked: Sat Dec 19 13:16:33 2020<br/> Check interval: 0 (&lt;none&gt;)<br/> Lifetime writes: 13 TB<br/> Reserved blocks uid: 0 (user root)<br/> Reserved blocks gid: 0 (group root)<br/> First inode: 11<br/> Inode size: 512<br/> Required extra isize: 32<br/> Desired extra isize: 32<br/> Journal inode: 8<br/> Default directory hash: half_md4<br/> Directory Hash Seed: 539641ac-c91c-4f61-8a99-a4d496714eeb<br/> Journal backup: inode blocks<br/> MMP block number: 15562<br/> MMP update interval: 5<br/> User quota inode: 3<br/> Group quota inode: 4<br/> Journal features: journal_incompat_revoke journal_64bit<br/> Journal size: 400M<br/> Journal length: 102400<br/> Journal sequence: 0x000db5e3<br/> Journal start: 31899<br/> MMP_block:<br/> mmp_magic: 0x4d4d50<br/> mmp_check_interval: 10<br/> mmp_sequence: 0x15ab88<br/> mmp_update_date: Sat Sep 4 19:39:59 2021<br/> mmp_update_time: 1630798799<br/> mmp_node_name: oss2.example.com<br/> mmp_device_name: dm-2</p> <p><span class="error">&#91;root@oss2 ~&#93;</span>#</p> Development Rank 1|i023lb: Rank (Obsolete) 9223372036854775807 Severity