<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

</head>

<body dir="auto">

Two reasons that I know about why this might happen:

<div>- the application is creating the files in a different directory and then renaming them</div>

<div>  (for example, MinIO is rename crazy)</div>

<div>- one of the OSTs is not available at time of creation, and another one is used instead,</div>

<div>  since stripe_count is more important than specific OST selection</div>

<div><br>

</div>

<div>If you want to constrain files to a specific set of OSTs (eg. flash vs. disk) you should create an OST pool.</div>

<div><br>

</div>

<div>Might I ask what your specific goal is here? There may be another way to achieve it. </div>

<div><br id="lineBreakAtBeginningOfSignature">

<div dir="ltr">Cheers, Andreas</div>

<div dir="ltr"><br>

</div>

<div dir="ltr">On Dec 8, 2025, at 03:28, Santiago Freire - InCo via lustre-discuss <lustre-discuss@lists.lustre.org> wrote:<br>

</div>

<blockquote type="cite">

<div dir="ltr">

<p data-start="197" data-end="212">Hello everyone.</p>

<p data-start="214" data-end="630">I am observing unexpected behavior regarding file striping in a directory that has an explicitly configured layout. I'm launching an application that writes

<b>new </b>files on a given directory, which is empty and I previously set its layout using

<code data-start="420" data-end="435">lfs setstripe</code> with a fixed stripe count, stripe size, and a specific set of OSTs (command

<font face="monospace">lfs setstripe -S 4M -c 3 -o 1,2,3 target_directory</font>). Running simple tools such as

<code data-start="533" data-end="537">dd</code> inside that directory produces files with the correct stripe pattern, checked using

<font face="monospace">lfs getstripe</font>.</p>

<p>However, when my application creates new files in that same directory, <b>all</b> of those files end up with a different layout: some are created with a stripe count of 1 and almost always put in the OST with index 1, others are placed n OSTs that are not

 part of the directory’s configured offset/OST set (for example, striped across OSTs 0, 1 and 2). This happens even though the files did not exist beforehand and the directory was empty with the correct striping applied. The application creates files with standard

 POSIX I/O (<code data-start="1032" data-end="1040">open()</code> followed by appends and writes), nothing exotic or MPI-IO-related.</p>

<p>Given that the directory layout is correct and tools like <code data-start="1167" data-end="1171">

dd</code> follow it reliably, I am trying to understand under what circumstances Lustre would ignore the directory’s default layout when creating new regular files. I would appreciate any insight or guidance on what might explain this behaviour, and how could

 I fix it.</p>

<p>I'm using Lustre 2.15.7, with RHEL 9.6 for the clients and RHEL 8.10 for the OSSs/MDS/MGS.</p>

<p data-start="1948" data-end="1979">Thank you very much in advance.</p>

<p data-start="1981" data-end="2005">Best regards,<br data-start="1994" data-end="1997">

Santiago</p>

<p><br>

</p>

<span>_______________________________________________</span><br>

<span>lustre-discuss mailing list</span><br>

<span>lustre-discuss@lists.lustre.org</span><br>

<span>http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org</span><br>

</div>

</blockquote>

</div>

</body>

</html>