Paul Jochum wrote:
Hi Richard:
I just tried your suggestion, unfortunately it doesn't work. Basically:
make a clone of the snapshot - works bine
in the clone, remove the directories - works fine
make a snapshot of the clone - works fine
destroy the clone - fails, because ZFS reports that
But to create a clone you'll need a snapshot so I
think the problem
will still be there...
This might be a way around this problem though. Deleting files from snapshots
sounds like a messy approach in terms of the architecture, but deleting files
from clones would be fine.
So what's needed
I agree, being able to delete the snapshot that a clone is attached to would be
a nice feature. Until we get that, this is what I have done (in case this
helps anyone else):
1) snapshot the filesystem
2) clone the snapshot into a seperate pool
3) only nfs mount the seperate pool with clones
I don't currently have a way to test this, but did you try:
make a clone of the snapshot
in the clone, remove the directories
make a snapshot of the clone
destroy the clone
destroy the old snapshot
In my mind, this should work, given no other dependencies exist.
Then again, a
Hello again,
Some of you may have read my earlier post about wanting to recover partial ZFS
space. It seems as though that isn't possible given the current
implementation... so, I would like to suggest the following enhancement:
A zfs-aware rm command (ie. zfs rm). The idea here is that we
