https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-4295 Lustre <p>One OST is deactivated on the MDS via "lctl --device 56 deactivate".</p> <p>Now when I try to drain the OST, I can remove (rm) files without an error message, but no space gets freed up on that OST as shown in "lfs df" output.</p> <p>I assume it only removed the inode/object on the MDS, but doesn't touch the deactivated OST, leaving all the migrated files behind as orphaned objects on the OST, which is pretty bad.</p> <p>If I do the same migration with the OST active, space as shown in "lfs df" does get freed up correctly.</p> Lustre 2.4.1 RHEL6 2.6.32-358.18.1.el6_lustre.x86_64 LU-4295

removing files on deactivated OST doesn't free up space

Bug Major Resolved Not a Bug WC Triage Wolfgang Baudler server Fri, 22 Nov 2013 14:00:56 +0000 Fri, 1 Dec 2017 02:17:38 +0000 Wed, 27 Nov 2013 19:43:54 +0000 Lustre 2.4.1 0 4 <p>The MDS keeps a log of the objects deleted on the deactivated OST (this can happen if the OST is offline for any reason), and they should be deleted if the OST is activated again.</p> <p>Well, in practice this did not work. I have reactivated the OST and then drained it with a script using</p> <p>lfs getstripe -v -r --obd $OST_PARAM $DIR</p> <p>to find all the files on the OST</p> <p>(since lfs_migrate is currently broken for 2.4.1)</p> <p>Now, after this draining is done lfs gestripe doesn't list any files any more on this OST, but lfs df still shows over 200GB of used disk space. So there must be some orphaned objects on there, presumably left over when I tried to drain the OST in a deactivated state as initially described.</p> Duplicate LU-7012 Related LU-4825 LU-7668 Development Epic metadata server Rank 1|hzw9xj: Rank (Obsolete) 11779 Severity