Re: [lustre-discuss] Unexpected result with overstriping

2024-05-17 Thread Nathan Dauchy via lustre-discuss
John,

I believe the lfs-setstripe man page is incorrect (or at least misleading) in 
this case. I recall seeing 2000 hardcoded as a maximum, so it appears to be 
picking that.

Using "-C -1" to put a single stripe on each OST wouldn't have any benefit over 
"-c -1".   IMHO, it would probably be more useful to have negative values 
represent number of stripes per OST. 

-Nathan

From: lustre-discuss  on behalf of 
John Bauer 
Sent: Friday, May 17, 2024 8:48 AM
To: lustre-discuss 
Subject: [lustre-discuss] Unexpected result with overstriping

External email: Use caution opening links or attachments


Good morning all,

I am playing around with overstriping a bit and I found a behavior that, to me, 
would seem unexpected.  The documentation for -C -1  indicates that the file 
should be striped over all available OSTs.  The pool, which happens to be the 
default, is ssd-pool which has 32 OSTs.  I got a stripeCount of 2000.  Is this 
as expected?

pfe20.jbauer2 213> rm -f /nobackup/jbauer2/ddd.dat
pfe20.jbauer2 214> lfs setstripe -C -1 /nobackup/jbauer2/ddd.dat
pfe20.jbauer2 215> lfs getstripe /nobackup/jbauer2/ddd.dat
/nobackup/jbauer2/ddd.dat
lmm_stripe_count:  2000
lmm_stripe_size:   1048576
lmm_pattern:   raid0,overstriped
lmm_layout_gen:0
lmm_stripe_offset: 119
lmm_pool:  ssd-pool
obdidx objid objid group
   119  523862870x31f59ef 0
   123  523479470x31ec42b 0
   127  527344870x324aa17 0
   121  528393960x32643e4 0
   131  527427090x324ca35 0
   116  522426590x31d28e3 0
   117  518311250x316e155 0
   124  524252180x31ff202 0
   125  524027220x31f9a22 0
   106  527005810x32425a5 0

edited for brevity

___
lustre-discuss mailing list
lustre-discuss@lists.lustre.org
http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org


[lustre-discuss] FLR Mirroring for read performance

2022-05-11 Thread Nathan Dauchy via lustre-discuss
Greetings!

During the helpful LUG tutorial from Rick Mohr on advanced lustre file layouts, 
it was mentioned that "lfs mirror" could be used to improve read performance.  
And the manual supports this, stating "files that are concurrently read by many 
clients (e.g. input decks, shared libraries, or executables) the aggregate 
parallel read performance of a single file can be improved by creating multiple 
mirrors of the file data".

What method does Lustre use to ensure that multiple clients balance their read 
workloads from the multiple mirrors?  Are there any tuning parameters that 
should be considered, other than making sure the "preferred" flag is NOT set on 
a single mirror, to help even out the read workload among the OSTs?

Has anyone tested this and quantified the performance improvement?

Thanks,
Nathan


___
lustre-discuss mailing list
lustre-discuss@lists.lustre.org
http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org


Re: [lustre-discuss] 2.14 against mofed 5.5.1.0.3.2-rhel7.9

2022-03-07 Thread Nathan Dauchy via lustre-discuss
Michael,

Likely your issue will be resolved in 2.15.  You could try applying the patch 
from here:
https://jira.whamcloud.com/browse/LU-15417
Build lustre on MOFED 5.5

-Nathan

-Original Message-
From: lustre-discuss  On Behalf Of 
Michael DiDomenico via lustre-discuss
Sent: Monday, March 7, 2022 10:16 AM
To: lustre-discuss 
Subject: Re: [lustre-discuss] 2.14 against mofed 5.5.1.0.3.2-rhel7.9

External email: Use caution opening links or attachments


and adding  --with-o2ib=/usr/src/ofa_kernel/x86_64/2.10.0-1160.59.1.el7.x86_64
seems to have at least allowed configure to move forward and the subsequent 
make passed.  that's as far as i can get today, i'll try mounts later

On Mon, Mar 7, 2022 at 12:07 PM Michael DiDomenico  
wrote:
>
> digging into this a little further, it looks like
>
> from lustre-release/lnet/autoconf/lustre-lnet.m4
>
> O2IBPATHS=$(eval $OFED_INFO | egrep -w 
> 'mlnx-ofed-kernel-dkms|mlnx-ofa_kernel-devel|compat-rdma-devel|kernel-ib-devel|ofa_kernel-devel'
> | xargs $LSPKG | grep '\(/openib\|/ofa_kernel/default\|/ofa_kernel\)$'
> | head -n1)
>
> this is the line that's failing for me.  the first egrep returns 
> mlnx-ofa_kernel-devel, which is piped to rpm -ql, but the second grep 
> does not return anything
>
> On Mon, Mar 7, 2022 at 11:07 AM Michael DiDomenico 
>  wrote:
> >
> > has anyone compiled 2.14 against the latest mofed 5.5.1.0.3.2?  i 
> > just tried, but it kicked out with unable to find the ofed sources.
> > previous build was 2.14 against mofed 5.4-1.0.3.0 which worked fine
___
lustre-discuss mailing list
lustre-discuss@lists.lustre.org
https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.lustre.org%2Flistinfo.cgi%2Flustre-discuss-lustre.orgdata=04%7C01%7Cndauchy%40nvidia.com%7Cd508bfc677c74ba7145a08da005e3208%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C637822701811996769%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=kWoGK6RgNn6LAPFY4E5bw1dLLapqeb5fvb2bpX2lqDI%3Dreserved=0
___
lustre-discuss mailing list
lustre-discuss@lists.lustre.org
http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org