Thanks, James, for reporting this, and thanks, Matt, for the analysis. I filed
7002362 to track this.
Tom
On 11/23/10 10:43 AM, Matthew Ahrens wrote:
I verified that this bug exists in OpenSolaris as well. The problem is that we
can't destroy the old filesystem "a" (which has been renamed to
Jakob Tewes wrote:
Hey folks,
i´m trying my luck with scriptbased zfs replication and got no more ideas left
so here comes my layout.
Got a small machine with two zfs pools, one protected via raidz2 and one
including just 1 disk. Now i wanted
> to use zfs´s nice snapshot/replication options t
Brandon High wrote:
I'm seeing some weird behavior on b133 with 'zfs inherit' that seems
to conflict with what the docs say. According to the man page it
"clears the specified property, causing it to be inherited from an
ancestor" but that's not the behavior I'm seeing.
For example:
basestar:~$
Daniel Bakken wrote:
We have found the problem. The mountpoint property on the sender was at
one time changed from the default, then later changed back to defaults
using zfs set instead of zfs inherit. Therefore, zfs send included these
local "non-default" properties in the stream, even though
Daniel Bakken wrote:
Here is the info from zstreamdump -v on the sending side:
BEGIN record
hdrtype = 2
features = 0
magic = 2f5bacbac
creation_time = 0
type = 0
flags = 0x0
toguid = 0
fromguid = 0
toname = promise1/arch...@
ect 'zdb -vvv poolname' to a file and search it for
"compression" to check the value in the ZAP.
I assume you have permission to set the compression property on the
receive side, but I'd check anyway.
Tom
On Tue, Apr 6, 2010 at 10:57 PM, Tom Erickson
mailto:thomas.
Daniel Bakken wrote:
When I send a filesystem with compression=gzip to another server with
compression=on, compression=gzip is not set on the received filesystem.
I am using:
zfs send -R promise1/arch...@daily.1 | zfs receive -vd sas
The zfs manpage says regarding the -R flag: "When received,
