How much snapshot is really using

[vrspectre]

I'm trying to figure out how much space i'm actually using for snapshots. I think it's 0, but the number on the usage pie chart says otherwise. When i try to browse the snapshots there's nothing there. I have it set to prune at 85% whicih i'm well over. So i suspect i'm not using any. Is that accurate? 

Running 6.10.1

[StephenB · Accepted solution]

---

@vrspectre wrote:

If I got into the .snapshots folder of each share and just delete everything there is that going to break anything? 

---

I think a better path is to create temporary share (tDrew), and then copy the contents from Drew into it (not .snapshots of course). Then delete the Drew share, and rename tDrew to Drew.

After that I suggest running a balance from the volume settings wheel.

[mdgm]

If you download your logs what does your btrfs.log look like?

If you have snapshots they should show in the subvolumes list. With that level of snapshot usage you'd expect there could be a number of snapshots or one very old snapshot on a share that has had a lot of changes.

[vrspectre]

Keeping in mind that I have no idea how to read the logs it would appear that there are indeed snapshots that just aren't showing up in the UI. There are lines like this for other shares as well. Is there a way to prune all the snapshots for the entire share? 

D 60532 gen 4188789 top level 265 path Drew/.snapshots/4449/snapshot

ID 60564 gen 4188789 top level 265 path Drew/.snapshots/4457/snapshot

ID 60568 gen 4188789 top level 265 path Drew/.snapshots/4458/snapshot

ID 60572 gen 4188789 top level 265 path Drew/.snapshots/4459/snapshot

ID 60576 gen 4188789 top level 265 path Drew/.snapshots/4460/snapshot

ID 60580 gen 4188789 top level 265 path Drew/.snapshots/4461/snapshot

ID 60584 gen 4188789 top level 265 path Drew/.snapshots/4462/snapshot

ID 60588 gen 4188789 top level 265 path Drew/.snapshots/4463/snapshot

ID 60592 gen 4188789 top level 265 path Drew/.snapshots/4464/snapshot

ID 61860 gen 4188789 top level 265 path Drew/.snapshots/4773/snapshot

ID 61864 gen 4188789 top level 265 path Drew/.snapshots/4774/snapshot

ID 61868 gen 4188789 top level 265 path Drew/.snapshots/4775/snapshot

ID 61872 gen 4188789 top level 265 path Drew/.snapshots/4776/snapshot

ID 61876 gen 4188789 top level 265 path Drew/.snapshots/4777/snapshot

ID 61880 gen 4188789 top level 265 path Drew/.snapshots/4778/snapshot

ID 134488 gen 4188789 top level 265 path Drew/.snapshots/17721/snapshot

ID 134492 gen 4188789 top level 265 path Drew/.snapshots/17722/snapshot

ID 134496 gen 4188789 top level 265 path Drew/.snapshots/17723/snapshot

[mdgm]

Those are snapshots. If you had no snapshots you'd expect to still see

Drew/.snapshots

but not any of the snapshots e.g.

Drew/.snapshots/4457/snapshot

These snapshots can be pruned using SSH.

It's odd that these snapshots aren't showing in the GUI.

[vrspectre]

If I got into the .snapshots folder of each share and just delete everything there is that going to break anything? 

[StephenB · Accepted solution]

---

@vrspectre wrote:

If I got into the .snapshots folder of each share and just delete everything there is that going to break anything? 

---

I think a better path is to create temporary share (tDrew), and then copy the contents from Drew into it (not .snapshots of course). Then delete the Drew share, and rename tDrew to Drew.

After that I suggest running a balance from the volume settings wheel.

[mdgm]

Going into the .snapshots folder and each share and trying to delete everything isn't going to work.

These snapshots can be pruned using SSH e.g.

# for snap in $(ls -1ad /data/*/.snapshots/*/snapshot);do btrfs subvolume delete $snap;sleep 2;done; 

The for loop is probably a better way to do it than trying to use a single command (see below) if you have a lot of snapshots.

# btrfs subvolume delete /data/Drew/.snapshots/*/snapshot

Note don't copy the #. It's important not to blindly copy shell commands but to try to understand what they do. It may take quite a while to delete the snapshots especially if there is a lot of them.

You can then do

# btrfs subvolume list /data

To see what's left.

This shouldn't break anything. As they aren't showing in the GUI the method I describe above should be fine. If they were in the GUI then they should be deleted a different way.

[vrspectre]

oh that's probably a better idea. However it's going to muck around with other things. I have these shares auto mount on my computers when they login so i'll have to recreate that. Plus I used readynas vault so that's going to double my storage while i clean it up. 

[StephenB]

---

@vrspectre wrote:

oh that's probably a better idea. However it's going to muck around with other things. I have these shares auto mount on my computers when they login so i'll have to recreate that. Plus I used readynas vault so that's going to double my storage while i clean it up. 

---

If you have an external hard drive, you could also copy Drew to that, then delete/recreate the share and then restore.  That's more conservative (as you aren't taking up more free space).

[vrspectre]

Alright so did this with my first share. Data copy compelted just fine. When I try to delete the now empty share it won't it gives me an error. 

I also noticed that in the Shares list it says it's consuming 16777216.0 TB. Which is not possible. I can't afford that much storage!! LOL

[vrspectre]

So since my old Drew share was now empty, i tried the command that @mdgm recomended on the

btrfs subvolume delete /data/Drew/.snapshots/*/snapshot

It worked great. After I ran that, I was able to delete the Drew share and rename my new share into it's place.

it seems this doesn't require me to recreate shares so i'm gonna try that on my other shares.  

[StephenB]

---

@vrspectre wrote:

it seems this doesn't require me to recreate shares so i'm gonna try that on my other shares.  

---

Correct.  The share deletion idea was intended to avoid use of ssh.  Obviously that didn't work.

But first see if there are any snapshots in those shares:

# btrfs subvol list -s /data

And when you are finished, I still recommend running a balance.