George Wilson wrote:
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)
even in that file there are three different policies:
OVERWRITE, APPEND, PREPEND. Note also the comment:
# It is important to fully understand that adding other files not
# listed here could cause a system to become unbootable.
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.
What would the output of zfs diffs be ?
I see two possible outputs.
1) the list of files that differ between the snapshot used to create the
clone and now.
2) the "changes" that ZFS needs to do to make them the same.
How would you apply these diffs ?
How do you select which files to apply and which not to ?
For example you want the log files to be "merged" some how but you
certainly don't want the binaries to be merged.
For many applications you can't just blindly copy files around while
they are running - they don't like it and it leads to application layer
data corruption.
I fully support a zfs diffs concept but I don't understand why this is
in any way tide to clone promotion as a zfs command.
A best practice would be to keep the application data and config/logging
data separately. This would avoid the need for this feature.
Agreed completely and with ZFS anything other than that is IMO poor
planning ZFS data sets are cheap!
--
Darren J Moffat
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
