Rudolf Potucek wrote:
once you break the model where a snapshot is a point-in-time picture, all sorts
of bad things can happen. You've changed a fundamental assumption of
snapshots, and this then impacts how we view them from all sorts of angles;
it's a huge loss to trade away for a very small gain.
Hmm ... I can see how the assumption of a snapshot being unalterable could provide some
programming shortcuts and opportunities for optimization of ZFS code. Not sure that I
understand the "huge loss" perspective though. I think at the point where I am
desperately scrabbling to free 30% of my root FS held hostage by an accidental snapshot
while keeping on-line backup strategy in tact, I won't be too worried about performance ;)
I don't think Erik meant the code. IMHO it is more about the assumption
in all technologies around zfs.
For example you want a guarantee that if you boot back into old BE it
will be the *same* as before upgrade.
Then there is replication based on zfs send|recv... what happens if
snapshot is modified on one side only?
Or for example we do use snapshot+clone to clone dev environments - can
I be sure that if I clone again from the same snapshot I will end-up
with the same system?
I'm all for flexibility and leavening a choice to sysadmins and I know
that developers can be very stuborn sometimes about "the right way or
nothing" approach but I don't think this on is the case as you do have
clones. In your case you are concerned with files you would like do
delete to regain disk space and they are still in a snapshot... in most
cases it is relatively easy to plan for it with a dedicated
filesystem(s) for temporary files, etc.
--
Robert Milkowski
http://milek.blogspot.com
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
