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
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.
6370738 zfs diffs filesystems
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
On Thu, May 11, 2006 at 03:38:59PM +0100, Darren J Moffat wrote:
What would the output of zfs diffs be ?
My original conception was:
- dnode # + changed blocks
- + some naming hints so that one could quickly find changed dnodes in
clones
I talked about this with Bill Moore and he came up
On Thu, May 11, 2006 at 11:15:12AM -0400, Bill Sommerfeld wrote:
This situation is analogous to the merge with common ancestor
operations performed on source code by most SCM systems; with a named
snapshot as the clone base, the ancestor is preserved and can easily be
retrieved.
Yes, and in
Promotion [PSARC/2006/303
Timeout:05/12/2006]
FYI folks, I have implemented clone promotion, also known as clone
swap or clone pivot, as described in this bug report:
6276916 support for clone swap
Look for it in an upcoming release...
Here is a copy of PSARC case which is currently under
