Two reasons that I know about why this might happen: - the application is creating the files in a different directory and then renaming them (for example, MinIO is rename crazy) - one of the OSTs is not available at time of creation, and another one is used instead, since stripe_count is more important than specific OST selection
If you want to constrain files to a specific set of OSTs (eg. flash vs. disk) you should create an OST pool. Might I ask what your specific goal is here? There may be another way to achieve it. Cheers, Andreas On Dec 8, 2025, at 03:28, Santiago Freire - InCo via lustre-discuss <[email protected]> wrote: Hello everyone. I am observing unexpected behavior regarding file striping in a directory that has an explicitly configured layout. I'm launching an application that writes new files on a given directory, which is empty and I previously set its layout using lfs setstripe with a fixed stripe count, stripe size, and a specific set of OSTs (command lfs setstripe -S 4M -c 3 -o 1,2,3 target_directory). Running simple tools such as dd inside that directory produces files with the correct stripe pattern, checked using lfs getstripe. However, when my application creates new files in that same directory, all 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 (open() followed by appends and writes), nothing exotic or MPI-IO-related. Given that the directory layout is correct and tools like dd 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. I'm using Lustre 2.15.7, with RHEL 9.6 for the clients and RHEL 8.10 for the OSSs/MDS/MGS. Thank you very much in advance. Best regards, Santiago _______________________________________________ lustre-discuss mailing list [email protected] http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org
_______________________________________________ lustre-discuss mailing list [email protected] http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org
