No combination of lfsck runs has helped with this.
Again, robinhood shows 1796104 files for the group, an 'lfs find -G gid' found
1796104 files as well.
So why is the quota command showing over 3 million inodes used?
There must be a way to force it to recount or clear all stale quota data and
Hi Dan,
I think it gets corrected when you umount and fsck the OST's themselves
(not lfsck). At least I recall seeing such messages when fsck'ing on 2.12.
Best,
Mark
On Wed, 4 Oct 2023, Daniel Szkola via lustre-discuss wrote:
[EXTERNAL EMAIL]
No combination of lfsck runs has helped with t
Hi Mark,
All nodes are using ZFS. OSTs, MDT, and MGT are all ZFS-based, so there's
really no way to fsck them. I could do a scrub, but that's not the same
thing. Is there a Lustre/ZFS equivalent of 'tune2fs -O [^]quota' for ZFS?
I'm guessing that at some point, a large number of files was removed
Hi,
I've just successfully built the lustre 2.15.3 client on Debian 11 and need to
do the same on Debian 12; however, configure fails with:
checking if Linux kernel was built with CONFIG_FHANDLE in or as module... no
configure: error:
Lustre fid handling requires that CONFIG_FHANDLE is enabled
Hi Dan,
Ah, I see. Sorry, no idea - it's been a few years since I last used ZFS,
and I've never used the Lustre ZFS backend.
Regards,
Mark
On Wed, 4 Oct 2023, Daniel Szkola wrote:
[EXTERNAL EMAIL]
Hi Mark,
All nodes are using ZFS. OSTs, MDT, and MGT are all ZFS-based, so there's
really n
Also, quotas on the OSTS don’t add up to near 3 million files either:
[root@lustreclient scratch]# ssh ossnode0 lfs quota -g somegroup -I 0 /lustre1
Disk quotas for grp somegroup (gid 9544):
Filesystem kbytes quota limit grace files quota limit grace
1394853459
On Oct 4, 2023, at 16:26, Jan Andersen mailto:j...@comind.io>>
wrote:
Hi,
I've just successfully built the lustre 2.15.3 client on Debian 11 and need to
do the same on Debian 12; however, configure fails with:
checking if Linux kernel was built with CONFIG_FHANDLE in or as module... no
configu
On Oct 3, 2023, at 16:22, Thomas Roth via lustre-discuss
wrote:
>
> Hi all,
>
> in our Lustre 2.12.5 system, we have "OST went back in time" after OST
> hardware replacement:
> - hardware had reached EOL
> - we set `max_create_count=0` for these OSTs, searched for and migrated off
> the files
Hi Andreas,
On 10/5/23 02:30, Andreas Dilger wrote:
On Oct 3, 2023, at 16:22, Thomas Roth via lustre-discuss
wrote:
Hi all,
in our Lustre 2.12.5 system, we have "OST went back in time" after OST hardware
replacement:
- hardware had reached EOL
- we set `max_create_count=0` for these OSTs,
