On Apr 16, 2019, at 13:53, Fernando Pérez wrote:
>
>> You can try...
>> unmount the filesystem and the run a force e2fsck on all OSTs and MDT.
>>
>> e2fsck -f -p /dev/ost...
>>
>> Regargs.
>
> Thank you Mahmoud.
>
> The problem is that e2fsck in the MDT runs very very slowly…10 inodes per
>
> On Apr 17, 2019, at 4:32 AM, Fernando Perez wrote:
>
> I tried to run the e2fsck in the mdt three years ago and the logs shows a lot
> of this kind of messages:
>
>> Unattached inode 26977505
>> Connect to /lost+found? yes
>> Inode 26977505 ref count is 2, should be 1. Fix? yes
>
> In fact
For ldiskfs based backend, the e2fsck will link ldiskfs orphan inodes into
backend /lost+found directory that is invisible to Lustre namespace. After
that, you can run namespace LFSCK that will move the orphan inodes (with valid
FID) from the backend /lost+found to Lustre lost+found directory th
Dear Fernando,
I'm not sure if those files contribute to the quota, but I would assume
that the ones on the OSTs consume disk quota and the ones on the MDT
consume inode quota.
As long as they are in the lost+found directory they are not visible to
the users, but they may contain data which belong
Dear Martin.
I tried to run the e2fsck in the mdt three years ago and the logs shows
a lot of this kind of messages:
Unattached inode 26977505
Connect to /lost+found? yes
Inode 26977505 ref count is 2, should be 1. Fix? yes
In fact I think that the e2fsc ran so slow due that all the mdt ino