On Jan 7, 2025, at 13:53, Mohr, Rick <[email protected]> wrote:
Lustre won't automatically spread files across multiple mdts.
Actually, since Lustre 2.15 the clients will distribute new subdirectory
creation across MDTs, either round-robin across MDTs for the top level
directories, and based on free space/inodes on the MDTs if they are imbalanced.
I guess you are running an older Lustre version (e.g. 2.12)? To have the MDT
space balancing you need to have both clients and servers with a new enough
version.
You can use "lfs mkdir -i <mdt_index> <dir>" to create a remote directory on a
specific mdt which will cause all files in that directory to also reside on the
same mdt.
The use of single-stripe remote directories is recommended for balancing MDT
usage. The use of "lfs mkdir -i $(((RANDOM % 2) + 1)) $DIR" could be added to
job launch scripts to put new output directories onto a random non-zero MDT.
A default remote MDT directory layout can be set on existing directories (e.g.
per user directory) to redirect new subdirectory creation to the other MDTs:
lfs setdirstripe -D -c 1 -i 1 /mnt/lustre/user1
lfs setdirstripe -D -c 1 -i 2 /mnt/lustre/user2
:
:
Note that this will *not* affect existing files/directories, only new
*subdirectory* creation in the specified directories. This needs to be run on
all directories where new subdirectories are being created, so priority should
be on top-level user directories and wherever they are running jobs. You don't
strictly need to run the "lfs setdirstripe" on *all* of the subdirectories,
e.g. maybe limited to directories modified in the last month.
You can also stripe a directory across multiple mdts using "lfs mkdir -c
<stripe_count> <dir>".
The use of many-striped directories is *not* recommended, unless there are
single directories with millions of entries. Striped directories should
definitely *not* be used for MDT balancing, since this will cause significant
overhead and consume a large number of MDT inodes.
My guess is that remote directories or striped directories were never created
so all files end up on MDT0 by default. Look for the section titled "Creating
a sub-directory on a specific MDT" in the Lustre manual for more details.
Hopefully that will resolve your issues.
Yes, this was a common problem on Lustre 2.12 and earlier deployments, and that
is why the DNE3 MDT space balancing was implemented and enabled by default in
newer releases.
Cheers, Andreas
--Rick
On 1/7/25, 3:29 AM, "lustre-discuss on behalf of Ihsan Ur Rahman"
<[email protected]
<mailto:[email protected]> on behalf of
[email protected] <mailto:[email protected]>> wrote:
Hello lustre folks,
New to this form and lustre as well.
We have a lustre system and the users are getting an error that no space is
left on the device. after checking, we have realised that the inodes are full
for one of the MDT.
lfs df -ihv /mnt/lustre/
UUID Inodes IUsed IFree IUse% Mounted on
lustre-MDT0000_UUID 894.0M 894.0M 58 100% /mnt/lustre[MDT:0]
lustre-MDT0001_UUID 894.0M 313 894.0M 1% /mnt/lustre[MDT:1]
lustre-MDT0002_UUID 894.0M 313 894.0M 1% /mnt/lustre[MDT:2]
lustre-OST0000_UUID 4.0G 26.2M 4.0G 1% /mnt/lustre[OST:0]
lustre-OST0001_UUID 4.0G 26.1M 4.0G 1% /mnt/lustre[OST:1]
lustre-OST0002_UUID 4.0G 28.1M 4.0G 1% /mnt/lustre[OST:2]
lustre-OST0003_UUID 4.0G 26.6M 4.0G 1% /mnt/lustre[OST:3]
lustre-OST0004_UUID 4.0G 28.2M 4.0G 1% /mnt/lustre[OST:4]
lustre-OST0005_UUID 4.0G 27.3M 4.0G 1% /mnt/lustre[OST:5]
lustre-OST0006_UUID 4.0G 27.5M 4.0G 1% /mnt/lustre[OST:6]
lustre-OST0007_UUID 4.0G 28.0M 4.0G 1% /mnt/lustre[OST:7]
lustre-OST0008_UUID 4.0G 27.5M 4.0G 1% /mnt/lustre[OST:8]
lustre-OST0009_UUID 4.0G 26.4M 4.0G 1% /mnt/lustre[OST:9]
lustre-OST000a_UUID 4.0G 27.9M 4.0G 1% /mnt/lustre[OST:10]
lustre-OST000b_UUID 4.0G 28.4M 4.0G 1% /mnt/lustre[OST:11]
lustre-OST000c_UUID 4.0G 28.3M 4.0G 1% /mnt/lustre[OST:12]
lustre-OST000d_UUID 4.0G 27.8M 4.0G 1% /mnt/lustre[OST:13]
lustre-OST000e_UUID 4.0G 27.6M 4.0G 1% /mnt/lustre[OST:14]
lustre-OST000f_UUID 4.0G 27.1M 4.0G 1% /mnt/lustre[OST:15]
lustre-OST0010_UUID 4.0G 26.5M 4.0G 1% /mnt/lustre[OST:16]
lustre-OST0011_UUID 4.0G 27.3M 4.0G 1% /mnt/lustre[OST:17]
lustre-OST0012_UUID 4.0G 27.1M 4.0G 1% /mnt/lustre[OST:18]
lustre-OST0013_UUID 4.0G 28.8M 4.0G 1% /mnt/lustre[OST:19]
lustre-OST0014_UUID 4.0G 28.2M 4.0G 1% /mnt/lustre[OST:20]
lustre-OST0015_UUID 4.0G 26.1M 4.0G 1% /mnt/lustre[OST:21]
lustre-OST0016_UUID 4.0G 27.2M 4.0G 1% /mnt/lustre[OST:22]
lustre-OST0017_UUID 4.0G 28.7M 4.0G 1% /mnt/lustre[OST:23]
lustre-OST0018_UUID 4.0G 28.5M 4.0G 1% /mnt/lustre[OST:24]
lustre-OST0019_UUID 4.0G 28.3M 4.0G 1% /mnt/lustre[OST:25]
lustre-OST001a_UUID 4.0G 27.3M 4.0G 1% /mnt/lustre[OST:26]
lustre-OST001b_UUID 4.0G 27.0M 4.0G 1% /mnt/lustre[OST:27]
lustre-OST001c_UUID 4.0G 28.8M 4.0G 1% /mnt/lustre[OST:28]
lustre-OST001d_UUID 4.0G 28.5M 4.0G 1% /mnt/lustre[OST:29]
filesystem_summary: 2.6G 894.0M 1.7G 34% /mnt/lustre
After some search on google I have found that there may be some open files on
the compute which can lead to consuming of the inodes.
With the command below I have got the list of the nodes where the files were
open.
lctl get_param mdt.*.exports.*.open_files
I login to each server and with lsof, I figure out the files and kill all those
files, but still it does not work for us.
Our primary goal is to bring the usage of inodes from 100% to below 90%, and
then we can share the load of inodes on the other two MDT nodes.
Need your guidance and support.
regards,
Ihsan
_______________________________________________
lustre-discuss mailing list
[email protected]
http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org
Cheers, Andreas
—
Andreas Dilger
Lustre Principal Architect
Whamcloud/DDN
_______________________________________________
lustre-discuss mailing list
[email protected]
http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org
