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
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 m
is it possible to delete files in the snapshot? (.zfs directory?)
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Hi All:
Actually, I am running into the same case (need to remove certain files from a
snapshot), let me give you a good example of why we need to do it.
In our case, we use zfs snapshots to store online backups of home file systems
(that is, readily accessable to employees if they need to reco
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 the "filesystem has
child
2007/11/13, Paul Jochum <[EMAIL PROTECTED]>:
> (the only option I can think of, is to use clones instead of snapshots in the
> future, just so that I can delete files in the clones in case I ever need to)
But to create a clone you'll need a snapshot so I think the problem
will still be there...
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 report
> 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 need
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
Th
