Not sure if it was fixed, but there was a bug in Lustre returning the wrong values here. If you create a bunch of files, the number of inodes reported should go up until you get where you expect it to be.
Note that the number of inodes on the OSTs also limits the number of creatable files: each file requires an inodes on at least one OST (number depends on how many OSTs each file is striped across). Kevin Gary Molenkamp wrote: > When creating the MDS filesystem, I used '-i 1024' on a 860GB logical > drive to provide approx 800M inodes in the lustre filesystem. This was > then verified with 'df -i' on the server: > > /dev/sda 860160000 130452 860029548 1% /data/mds > > Later, after completing the OST creation and mounting the full > filesystem on a client, I noticed that 'df -i' on the client mount is > only showing 108M inodes in the lfs: > > 10.18.1...@tcp:10.18.1...@tcp:/gulfwork > 107454606 130452 107324154 1% /gulfwork > > A check with 'lfs df -i' shows the MDT only has 108M inodes: > > gulfwork-MDT0000_UUID 107454606 130452 107324154 0% > /gulfwork[MDT:0] > > Is there a preallocation mechanism in play here, or did I miss something > critical in the initial setup? My concern is that modifications to the > inodes are not reconfigurable, so it must be correct before the > filesystem goes into production. > > FYI, the filesystem was created with: > > MDS/MGS on 880G logical drive: > mkfs.lustre --fsname gulfwork --mdt --mgs --mkfsoptions='-i 1024' > --failnode=10.18.12.1 /dev/sda > > OSSs on 9.1TB logical drives: > /usr/sbin/mkfs.lustre --fsname gulfwork --ost --mgsnode=10.18.1...@tcp > --mgsnode=10.18.1...@tcp /dev/cciss/c0d0 > > Thanks. > > _______________________________________________ Lustre-discuss mailing list Lustre-discuss@lists.lustre.org http://lists.lustre.org/mailman/listinfo/lustre-discuss
