Reclaim Used Disk Space on FOG Server?
-
I’ve been having some issues deleting images and reclaiming used disk space when attempting to remove unneeded system images. Using the option to remove the image definition and data doesn’t result in the image being removed, but selecting the image from “List All Images”, checking the image in question and selecting it for deletion appears to remove the image definition but not the data. When I review the amount of disk space used, it remains unchanged. Is there a “disk cleanup” option to reclaim disk space that I’m overlooking? Any help would be greatly appreciated.
-
@Ben-Acheff said in Reclaim Used Disk Space on FOG Server?:
Using the option to remove the image definition and data doesn’t result in the image being removed
Deleting definitions directly from the “list all” listing does not delete image data. That’s by design. The developers didn’t want it to be so easy to obliterate every image, and I agree with their choice. However, @Developers there probably should be some sort of message displayed when this method is used saying “hey, the data won’t be deleted if you do it this way.”
The below are simplified instructions for FOG 1.3.x, for the Linux newbie on how to do it right, and how to clean up the mess. Not calling you a noob, but I write for future readers too, not just you.
How to quickly delete definitions but
notdata:
Web Interface -> Image Management -> List All Images -> Click the checkboxes to the left of the image definitions -> Click "Delete All Selected Images?" at bottom of page -> Click "Are you sure you wish to delete these items?" -> Authenticate to confirmHow to delete a single image definition
andit’s data too:
Web Interface -> Image Management -> List All Images -> Click the name of the image you want to delete -> Click "Delete" from the left menu -> Check the box labled "Delete file data" -> Click "Remove" -> Authenticate to confirmIf the above steps don’t actually delete the image data too, you’re FTP credentials are likely incorrect, refer to this article on how to fix that: https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_FTP
How to clean up the stuff you didn’t delete the data for:
On your FOG Server via Terminal or SSH, become root properly with:
sudo -i
Access the database via CLI with:
mysql -D fogor if it’s password protected:mysql -D fog -u root -p
Get a listing of the legitimate image paths (not the same as image names):
select imagePath from images;
Exit mysql once you have the list:
quitThese paths do not have the image path directory with them. The default image path is
/imageson your server. If you inherited the server, it may not be the default. You can check what it is with this query (in the fog database):
select ngmRootPath from nfsGroupMembers;
Or by looking in the web interface here:
Web Interface -> Storage Mangement -> [click node name] -> Image PathNow, once you have the Image Path, you can do something like this:
ls -l /imagesor whatever the image path is.
Compare this list to the output from the database.The
devdirectory or any file named.mntcheckthese are required for FOG to operate.Say you have an image that showed up in the
lsoutput, but not in the database output. Say that image was calledAcerbase. First, all things in Linux are case sensitive - you mistype a case and this doesn’t work, or does something you don’t want to happen.Here’s how to delete that image:
rm -rf /images/AcerbaseAfter getting this done, you might look inside of the
devdirectory to see if there are any partial images from failed uploads.
ls -l /images/dev
Again, do not delete any file named.mntcheckbut it’s safe to delete everything else in here, but just not thedevdirectory itself.Take your time with this, it’s not a race.
#wiki worthy.
-
I agree. Fog should tell you “these images won’t really be deleted, I’m just going to pretend… you’ll need to ssh in and clean up”
I revived this thread, because I’m seeing this issue. I see other threads saying it works, but I am on
FOG 1.5.4 kernel 4.18.3 and have to ssh to actually delete the files.