Chad hit the nail on the head. I thought about the fact that it was still
deactivated yesterday but was afraid to reactivate it until I verified the
space was free.
FWIW, the URL about handling full OSTs does not include the fact that the space
will not be free until you reactivate the OST.
> On Jan 17, 2019, at 2:38 PM, Jason Williams wrote:
>
> - I just looked for lfsck but I don't seem to have it. We are running 2.10.4
> so I don't know what version that appeared in.
lfsck is handled as a subcommand for lctl.
http://doc.lustre.org/lustre_manual.xhtml#dbdoclet.lfsckadmin
--
Hi Jason,
I do not know if this will help you or not, but I had a situation in 2.8.0
where an OST filled up and I marked it as disabled on the MDS:
lctl dl | grep osc
...Grab the *device_id* of the full OST and then deactivate it...
lctl --device *device_id* deactivate
IIRC, this allowed the dat
Hello Alexander,
Thank you for your reply.
- We are not using zfs, it's an LDISKFS backing store, so no snapshots.
- I have re-run lfs getstripe to make sure the file is indeed moving
- I just looked for lfsck but I don't seem to have it. We are running 2.10.4
so I don't know what version th
- you can re-run command to find files residing on ost to see if files are new
or old.
- zfs may have snapshots if you ever did snapshots; it takes space.
- removing data or snapshots has some lag to release the blocks (tens of
minutes) but I guess that is completed by now.
- there are can be
On Wed, Jan 16, 2019 at 04:25:25PM +, Jason Williams wrote:
>I am trying to migrate files I know are not in use off of the full OST that I
>have using lfs migrate. I have verified up and down that the files I am
>moving are on that OST and that after the migrate lfs getstripe indeed shows
>
