[zfs-discuss] [RFC] Improved versioned pointer algorithms

Daniel Phillips
Mon, 21 Jul 2008 21:22:40 -0000

On Sunday 20 July 2008 21:38, Akhilesh Mritunjai wrote:
> > On Monday 14 July 2008 08:29, Akhilesh Mritunjai
> > wrote:
> > > Writable snapshots are called "clones" in zfs. So
> > infact, you have
> > > trees of snapshots and clones. Snapshots are
> > read-only, and you can
> > > create any number of "writable" clones from a
> > snapshot, that behave
> > > like a normal filesystem and you can again take
> > snapshots of the
> > > clones.
> >
> > So if I snapshot a filesystem, then clone it, then
> > delete a file
> > from both the clone and the original filesystem, the
> > presence
> > of the snapshot will prevent the file blocks from
> > being recovered,
> > and there is no way I can get rid of those blocks
> > short of deleting
> > both the clone and the snapshot.  Did I get that
> > right?
>
> Right. Snapshots are immutable. Isn''t this the whole point of a
snapshot ?

But that is not my point.  My point is that there is no way to recover
the volume space used by my example file short of deleting both the
clone and the snapshot.  My example file might be very large.  I can
easily imagine a case where this might be an impediment to efficient
use of storage.  For example, where you have multiple virtual machine
instances sharing one root filesystem via clones, and you later want to
get rid some large files from the original root image and all the
clones.  But because you can''t get rid of the snapshot that is required
for the clone, no disk space will be recovered.

Btrfs does not suffer from this problem as far as I can see because it
uses reference counting rather than a ZFS-style dead list.  I was just
wondering if ZFS devs recognize the problem and are working on a
solution.

Regards,

Daniel