Deleting Images
-
Server
- FOG Version: 1.4.3
- OS: Ubuntu 16.04.2 LTS
Client
- Service Version:
- OS:
Description
After deleting images in Fog, it does not remove the images on the disk or storage nodes. Bug?
Dashboard
Disk
Storage Nodes
-
Permissions looked off, so I set them, but old “already deleted” images are still there. How do I remove them without messing up the database?
root@PDC-FOG:~# ls -l /images/ total 32 drwxrwxrwx 4 fog root 4096 Jun 22 16:18 dev drwx------ 2 root root 16384 Jun 21 08:36 lost+found drwxrwxrwx 2 root root 4096 Jun 22 12:08 MacOS-Test drwxrwxrwx 2 fog root 4096 Jun 21 08:33 postdownloadscripts drwxrwxrwx 2 root root 4096 Jun 22 09:34 Win10-Test root@PDC-FOG:~# chown -R fog:root /images root@PDC-FOG:~# ls -l /images/ total 32 drwxrwxrwx 4 fog root 4096 Jun 22 16:18 dev drwx------ 2 fog root 16384 Jun 21 08:36 lost+found drwxrwxrwx 2 fog root 4096 Jun 22 12:08 MacOS-Test drwxrwxrwx 2 fog root 4096 Jun 21 08:33 postdownloadscripts drwxrwxrwx 2 fog root 4096 Jun 22 09:34 Win10-Test root@PDC-FOG:~# -
Can I just delete the images from the disk?
-
How did you delete the images initially?
If you delete the images individually (clickon on each image->choose delete) it will ask you if you want to delete the data as well.
If you deleted using the “list/search click checkbox press delete” it doesn’t do this option yet. I’m nervous about adding this capability here and the best approach to handle it just because you’re dealing with real data, so I hope you understand the hesitation.
-
@Tom-Elliott Did them both at the same time from the Image Management menu.
-
@Tom-Elliott Can I just delete them from the Ubuntu CLI on the main Fog server and the storage nodes will replicate the delete?
-
I deleted them via the CLI and don’t seem to have any issues thus far; however it did not replicate the delete to the storage nodes… I had to delete them individually.
-
@msnyder It should, but I can’t guarantee anything. In the past it would, certainly because of how replication operated. It was an all or none type of thing.
It would delete everything from the /images folder and make the master’s images folder a “copy” on the nodes. Of course this worked, but it left a lot of “unknowns” in the mix and didn’t allow any granularity. For example, if the d1.fixed_size_partitions for /images/someimage changed, but the d1p1.img and d1p2.img file (not reality but for the example’s sake) didn’t change at all, it would delete the WHOLE image and force replication down. While this has it’s upsides, it can also cause a huge strain on network performance considering the files can be very large sometimes. (Pro’s vs. Con’s can be thought here).
With the restructured layout for replication, each file is checked individually within an image and only the “changed” files are deleted and re replicated. This also allows you to say which images you want to be replicated at an individual level. (Granular control). Of course this makes it so deletions aren’t autonomous. That said, I’m fairly sure I have the layout set to search all nodes/storage groups it’s assigned to and remove them from ALL places, but I haven’t looked at the way deletes happen in a fairly long time. Sorry I should know it, but I’m working a full time job, plus updating the source code in FOG, plus building kernels, and maintaining Inits. I think you might understand why I might forget things from now and then.
-
@Tom-Elliott Dude everyone here gets it and appreciates what you do! Thanks for everything!
