This would be comparable to what live upgrade does with its sync option.
With lu, certain files get synced to the newly activated BE just prior
to booting it up. (see /etc/lu/synclist)
Let's take a filesystem which contains both static application data as
well as constantly changing files such as logs, data or configuration
files. And let's assume that such a filesystem is cloned with the
intention of upgrading the application version. This new application
version could undergo several weeks of testing meaning that certain
files may have diverged from the real production data. So just prior to
promoting it into production you may want to sync up any certain files
which have been updated in the original parent. Here's where the need
for the 'zfs diffs' comes in. You could also use other tools like rsync
but it would be nice to provide something similar to what is live
upgrade does so that it happens as part of the promotion.
A best practice would be to keep the application data and config/logging
data separately. This would avoid the need for this feature.
Thanks,
George
Darren J Moffat wrote:
George Wilson wrote:
Matt,
This is really cool! One thing that I can think of that would be nice
to have is the ability to 'promote' and 'sync'. In other words, just
prior to promoting the clone, bring any files that are newer on the
original parent up-to-date on the clone. I suspect you could utilize
zfs diffs (CR# 6370738) to provide this functionality and apply the
diffs.
I'm really confused why would you want to do that ?
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
