Thank you for answering Andreas.
Lustre version is 2.12.8
It is indeed when we delete io500 files when we discovered this, but we also
see it when deleting other files, that the "df" lags 1-2 hours behind.
We see it both on nvme and ssd drives. Haven't checkd hdd drives/osts yet.
This is a new
Hi Steve,
Yes, you have an "rbh-du" command that queries the robinhood's database rather
than the filesystem.
Best regards,
Thomas
De : Steve L [mailto:slc1...@outlook.com]
Envoyé : vendredi 15 avril 2022 19:17
À : LEIBOVICI Thomas 601315
Cc : lustre-discuss@lists.lustre.org
Objet : Re:
Hi Folks,
One of our filesystems seemed to fail over the holiday weekend - we're
running DNE and MDT0001 won't mount. At first it looked like we'd run
out of space (rc = -28) but then we were seeing this
mount.lustre: mount /dev/mapper/MDT0001 at /lustre/astrofs-MDT0001
failed: File exists
Hi Andrew,
kernel: LustreError: 13921:0:(genops.c:478:class_register_device())
astrofs-OST-osc-MDT0001: already exists, won't add
is symptomatic of a llog index issue/mismatch on the MDT vs. MGT. I would check
if the llog backup of MDT0001 (over ldiskfs in CONFIGS) matches the one on the
One thing you can look at is running 'zpool iostat 1' (there are many
options) to monitor that ZFS is still doing I/O during that time gap.
With NVMe though, as Andreas said, I would expect that time gap to last
seconds to minutes, not hours.
On 4/19/22 02:16, Einar Næss Jensen wrote:
Thank
