I'm puzzled by the size reported for incremental zfs send|zfs receive. I'd
expect the stream to be roughly the same size as the "used" blocks reported by
zfs list. Can anyone explain why the stream size reported is so much larger
that the used data in the source snapshots? Thanks.
% zfs list
Thanks for you reply. Sorry I overlooked that bug; my bugster search skills
seem lacking.
--
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
I recently tried to post this as a bug, and received an auto-ack, but can't
tell whether its been accepted. Does this seem like a bug to anyone else?
Default for zfs list is now to show only filesystems. However, a `zfs list` or
`zfs list -t filesystem` shows filesystems AND incomplete snapsho
About a month ago (Jun 2008), I received information indicating that a putback
fixing this problem was in the works and might appear as soon as b92.
Apparently this estimate was overly optimistic; Does anyone know anything about
progress on this issue or have a revised estimate for the putback?
Thanks, Matt. Are you interested in feedback on various questions regarding
how to display results? On list or off? Thanks.
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.o
Do you have sata Native Command Queuing enabled? I've experienced delays of
just under one minute when NCQ is enabled, that do not occur when NCQ is
disabled. If all threads comprising the parallel zfs destroy hang for a
minute, I bet its the hang that causes "no more processes". I have open
Apologies up front for failing to find related posts...
Am I overlooking a way to get 'zfs send -i [EMAIL PROTECTED] [EMAIL PROTECTED]
| zfs receive -n -v ...' to show the contents of the stream? I'm looking for
the equivalent of ufsdump 1f - fs ... | ufsrestore tv - . I'm hoping that this
mig
