[EMAIL PROTECTED] wrote:
I completely disagree. In this scenario (and almost all others), use of
regular snapshots will solve the problem. 'zfs snapshot -r' is
extremely fast, and I'm working on some new features that will make
using snapshots for this even easier and better-performing.
If you disagree, please tell us *why* you think snapshots don't solve
the problem.
think of night when some (maybe 5 %) people still work. Having snapshot
I would still have to create snapshots for 400 filesystems each hour because I
don't know which of them are working. And what about weekend ? Still
400 snaphosts each hour ? And 'zfs list' will list me 400*24*2=19200 lines ?
And how about organizations which has thousends people and keep their
files on one server ? Or ISP/free e-maila account providers who have millions ?
Yes, this is unfortunate. I have some forthcoming changes that will
allow you to take periodic snapshots, but only when changes are
occurring. This will greatly decrease the "snapshot explosion" you
point out.
Matt, I agree with you that having snapshots *solve* the problem with
400 filesystems because in SVM/UFS environemnt I _wouldn't_ have such
solution. But I feel that versioning would be much more convenient here.
Imagine that you are the admin of the server and ZFS has versioning: having a
choice
what would you choose in this case ?
I think that my preference would depends a lot on the details of the
file versioning. Certainly, if there is some implementation of file
versioning which allows me to find the old data I'm looking for more
easily than snapshots, and it does not impose an undue performance
burden[*] on the system, then I would choose that. However, as we're
discovering on this thread, discovering such a scheme is nontrivial :-)
--matt
[*] This includes disk space usage. For example, how would the space
used by file versions be accounted/expressed? How would file versioning
interact with snapshots? Including old file versions in snapshots might
be contrary to the user's expectations, and wasteful of space. But any
other behavior may be prohibitively complicated to implement.
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
