ZFS vbox zfs guest compact vdi

A friendly hello :

I've been searching in the FreeBSD forum and on global google and found no answer which makes sense to me ... I have to say that I'm not an expert when it come to ZFS or inodes

I have a couple vbox trueos guests with zfs

As a reference, for now I'm not using snapshots ... as I use the zfs based vbox guest trueos machines I assume that as file write / delete cycles progress there will be more inodes or so which hold deleted files and are not zeroed out ... in windows guests one would use sdelete to zero these deleted file remainders out and in linux one would use dd if=/dev/zero of=bigfile bs 4096 followed by a rm bigfile and all would be zeroed out
now the "VBoxManage modifyhd <name>.vdi --compact" command would do the vdi compact operation.

Since the zfs is a copy-on-write file system would this "dd zero operation" work and or is it necessary ... have found a few conflicting suggestions

What would need to be done to be sure that any deleted files-pace is being reclaimed with the vboxmanage compact operation

Many many thanks in advance

Cheers Klaus
If you're not using snapshots, deleted data is deleted. It isn't directly overwritten or immediately zeroed out, but it doesn't hang around forever.You don't have to think about it.

The reason you can't find information on how to deal with that is because it would be a serious design flaw. ;)
Thanks for the fast reply ;)

I have the following question to "It isn't directly overwritten or immediately zeroed out, but it doesn't hang around forever.You don't have to think about it."

In an environment like a ZFS in a vbox guest VDI file, how would this not "immediately zeroed out" disk portion be treated by a vboxmanager vdi file compact operation, would this portion be compacted out or still remain with the effect of resulting in a still larger vdi file as necessary after compacting.

With other file systems the usual operation is to zero out these non zero deleted file portions and then the compact operation is treating it as empty space and eliminates it from the compacted vdi

Currently I'm trying to zero out (via dd /dev/zero) a 64 GB VDI drive but it's already running for 10 plus hours and it seems to take many more before I can attempt to delete this big zeroed fill file and proceed with the compacting to verify the result. Usually the filling with 0-es doesn't take that long with a Windows of Linux file system based vbox guest.

I haven't found really anything with regards to the proper way of compacting a ZFS based vbox guest VDI file.

Cheers Klaus
Sorry, now that I've actually woken up I see your concern might be how a dynamic virtual disk might eat up space on the host system, rather than how much space you have for the guest system. I thought you were worried about running out of space for TrueOS, while now it looks like you're trying to keep from running out of space for your host system.

Are you trying to zero out the filesystem from inside the virtual machine, or the virtual disk file itself from the host system? I have no idea why it might be taking so long either way, but hopefully someone can help you with that.

As for your VirtualBox question, I don't really know how the lower-level VirtualBox operations might interact with ZFS, as I've never tried ZFS in a virtual environment. And to my knowledge, there's no way to actually zero out all the freed blocks in a ZFS pool, since doing so would be very complicated and there's really no technical reason to do so.

EDIT: I did find this mailing list discussion: [zfs-discuss] zero out block / sectors

The solution mentioned in the second post might be helpful if you have the disk space.
Thanks for all your replies.

It seems that I choose the wrong file system for a guest implementation in a virtual environment (vbox). Since I'm not that far into it, I'll reinstall from scratch with ext2 or so. The vbox was meant as a try out solution.

Thanks again, cheers Klaus.

It would be nice if anyone would have warned about a copy-on-write file system like ZFS in a guest virtualization and a potential VDI container file compacting problems. Actually I have not completely studied this compacting with ZFS, rather throw in the towel and restart with ext2. Thanks again, it seems I'm on the right track now.