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 _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
