free space zfs

I've had this problem before and I think only a reboot solves it. In a nutshell when I delete a file, I don't see the space when I do a df -h. This time, I was creating a jail and doing the buildworld when I noticed I only had less than 900 megs. I deleted an iso that was 1.2 Gigs but it doesn't show. I am using zfs on root. Any, suggestions.

Code:
[14-04-24 11:16]root@/home/larry#uname -a
FreeBSD freebsd.webbrews.com 10.0-RELEASE-p1 FreeBSD 10.0-RELEASE-p1 #0: Tue Apr  8 06:45:06 UTC 2014     root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64
 
Are you using snapshots on the ZFS dataset from which the ISO file was deleted? If so that would explain what you are seeing.
 
Well to be honest I'm not entirely sure what your talking about. One reason I'm creating the jails it to experiment with zfs. I have created snapshots but I thought those were basically backups until you decided to boot into it.


I can tell you I didn't change anything with zfs after deleting the file (didn't even reboot). A reboot usually will do the trick but it would be nice to be able to avoid that.


update: reboot is not freeing the space
 
doc1623 said:
Well to be honest I'm not entirely sure what your talking about. One reason I'm creating the jails it to experiment with zfs. I have created snapshots but I thought those were basically backups until you decided to boot into it.
Let's assume you have a ZFS dataset zroot/var/crash that contains 4 GB of data and you snapshot the dataset. Initially the snapshot is empty. When you delete a 1 GB file from /var/crash, the blocks for that file do not get removed from disk, they get "transferred" to the snapshot. So after the delete, /var/crash has 3 GB of data and the snapshot has 1 GB of data. Since the snapshot is stored in the root of the dataset (i.e., zroot/var/crash/.zfs/), the size of the ZFS dataset will not be reduced as a result of deleting the file.

If the space is more important to you right now than the snapshot, destroy the snapshot to reclaim the space.
 
It looks like it might be coming available slowly.

@trh411 Thanks that's good information. It almost sounds like it acts as a trash/recycle... except without the empty..k maybe I don't have the idea ; ). I'll look into it further.


@oliver@ Thanks but I don't seem to have zfs scrub

Code:
[14-04-24 13:57]root@/home/larry#zfs
allow       create      diff        groupspace  hold        inherit     list        promote     release     rollback    set         snapshot    unmount     upgrade     
clone       destroy     get         help        holds       key         mount       receive     rename      send        share       unallow     unshare     userspace
 
Last edited by a moderator:
Thanks @wblock@

Tried it to no avail but I freed up space by destroying an unused snapshot.
 
Last edited by a moderator:
If you use snapshots you will use more space than the currently visible files/blocks. You will always need as much space as your current state of your ZFS filesystem plus all differing older states of files/blocks.
These must remain there to let you go back in time and restore files from older snapshots, and so can't give you your disk space back.
When the snapshots get destroyed all blocks on disk that are no longer referenced by any other snapshot or the current state will get available. You can see this via zfs list and the differing sizes in the columns "used" and "referenced" (sorry, but I can't give you the exact names as I am not at my machine at the moment). "Used" determines the usage of the current state of the ZFS dataset whereas "Referenced" determines how much space is blocked by the current state and all snapshots on disk.
So, all differences in files/blocks that are visible in any of your snapshots will block the sum of differences from your free space on disk.
The thing with blocked space and snapshots is not ZFS specific. If you deleted a file in the current state directory and your filesystem freed up disk space how would you be able to go back to a snapshot state? As those reserved parts of your disk could have already been overwritten - as designated "deleted".

zpool scrub e.g. helps to detect bit rot and tries to correct that, but see the man pages for more.

Does this make sense so far?
 
Thanks gqgunhed ,


It does and but I'll have review it more. I've now got one jail up and running and plan to clone it so I can play around with it.
 
Last edited:
Back
Top