[lustre-discuss] Putting mdtidx in lmm_stripe_offset field for lfs getstripe
Tancheff, Shaun
shaun.tancheff at hpe.com
Fri May 29 15:48:50 UTC 2026
fwiw ("LU-18982 lov: Do not display lmm_stripe_offset for mdt file") added 'lmm_mdt_index:' ... ex:
lfs getstripe /mnt/lustre/sanity909/mdt-stripe
/mnt/lustre/sanity909/mdt-stripe
lcm_layout_gen: 1
lcm_mirror_count: 1
lcm_entry_count: 1
lcme_id: 1
lcme_mirror_id: 0
lcme_flags: init
lcme_extent.e_start: 0
lcme_extent.e_end: 1048576
lmm_stripe_count: 0
lmm_stripe_size: 1048576
lmm_pattern: mdt
lmm_layout_gen: 1
lmm_mdt_index: 1
# lfs getstripe --mdt /mnt/lustre/sanity909/mdt-stripe
1
________________________________
From: lustre-discuss <lustre-discuss-bounces at lists.lustre.org> on behalf of Mohr, Rick via lustre-discuss <lustre-discuss at lists.lustre.org>
Sent: Friday, May 29, 2026 10:29 PM
To: John Bauer <bauerj at iodoctors.com>; lustre-discuss at lists.lustre.org <lustre-discuss at lists.lustre.org>
Subject: Re: [lustre-discuss] [EXTERNAL] Putting mdtidx in lmm_stripe_offset field for lfs getstripe
I wouldn’t mind seeing the mdt index be listed in the getstripe output regardless of whether or not the file had a DoM component. That way I wouldn't have to run "lfs getstripe --mdt" separately to get that info. But the current getstripe output seems to closely mimic the internal data structure of the layout, so adding the mdt index would somewhat deviate from that. I don't know if that would be considered undesirable or not.
--Rick
On 5/29/26, 10:08 AM, "lustre-discuss on behalf of John Bauer via lustre-discuss" wrote:
Would it be reasonable to change the output of lfs getstripe to have the mdtidx reflected in the lmm_stripe_offset field? I have noticed that for DoM components the value is always 0. It would make sense as the stripe_offset is normally the OST index where striping starts for that component, and for DoM components it could indicate the MDT where the striping starts and ends for the component. This would add a bit of value to the lfs getstripe command without adding extra lines. The following lfs getstripe output is for a file that llapi_file_fget_mdtidx() reports that the mdtidx is 3.
John
% lfs getstripe b.dat
b.dat
lcm_layout_gen: 3
lcm_mirror_count: 1
lcm_entry_count: 2
lcme_id: 1
lcme_mirror_id: 0
lcme_flags: init
lcme_extent.e_start: 0
lcme_extent.e_end: 1048576
lmm_stripe_count: 0
lmm_stripe_size: 1048576
lmm_pattern: mdt
lmm_layout_gen: 0
lmm_stripe_offset: 0
lmm_pool: flash
lcme_id: 2
lcme_mirror_id: 0
lcme_flags: init
lcme_extent.e_start: 1048576
lcme_extent.e_end: EOF
lmm_stripe_count: 4
lmm_stripe_size: 1048576
lmm_pattern: raid0
lmm_layout_gen: 0
lmm_stripe_offset: 102
lmm_pool: disk
lmm_objects:
- 0: { l_ost_idx: 2, l_fid: [0x78000040e:0x10527b5:0x0] }
- 1: { l_ost_idx: 30, l_fid: [0x68000040e:0x1082064:0x0] }
- 2: { l_ost_idx: 08, l_fid: [0x48000040e:0x1052a13:0x0] }
- 3: { l_ost_idx: 18, l_fid: [0x2c000040e:0x103046f:0x0] }
_______________________________________________
lustre-discuss mailing list
lustre-discuss at lists.lustre.org
https://urldefense.com/v3/__http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org__;!!NpxR!j--0HpxT5p-jCFCcNm80ab8vVmJ9ncpWSbVyNPmO5r9vpfNOaMpd3OYqC07sXjn_Y_kAN9i1n6QHFSHVIPd0mvkZEQAWuWTA$
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-discuss_lists.lustre.org/attachments/20260529/b89ca85c/attachment.html>
More information about the lustre-discuss
mailing list