On Wed, Apr 7, 2010 at 10:47 AM, 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:
Is compression set on the dataset, or is it being inherited from a
parent dataset?
On 08 April, 2010 - Cindy Swearingen sent me these 2,6K bytes:
> Hi Daniel,
>
> D'oh...
>
> I found a related bug when I looked at this yesterday but I didn't think
> it was your problem because you didn't get a busy message.
>
> See this RFE:
>
> http://bugs.opensolaris.org/bugdatabase/view_bug.d
Hi Daniel,
D'oh...
I found a related bug when I looked at this yesterday but I didn't think
it was your problem because you didn't get a busy message.
See this RFE:
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6700597
Cindy
On 04/07/10 17:59, Daniel Bakken wrote:
We have found
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...@
Daniel Bakken wrote:
The receive side is running build 111b (2009.06), so I'm not sure if
your advice actually applies to my situation.
The advice regarding received vs local properties definitely does not
apply. You could still confirm the presence of the compression property
in the send s
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,
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 the local properties are
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...@daily.1
nvlist version
The receive side is running build 111b (2009.06), so I'm not sure if your
advice actually applies to my situation.
Daniel Bakken
On Tue, Apr 6, 2010 at 10:57 PM, Tom Erickson wrote:
> After build 128, locally set properties override received properties, and
> this would be the expected behavio
I worked around the problem by first creating a filesystem of the same name
with compression=gzip on the target server. Like this:
zfs create sas/archive
zfs set compression=gzip sas/archive
Then I used zfs receive with the -F option:
zfs send -vR promise1/arch...@daily.1 | zfs send zfs receive
Hi Daniel,
I tried to reproduce this by sending from a b130 system to a s10u9
system, which vary in pool versions, but this shouldn't matter. I've
been sending/receiving streams between latest build systems and
older s10 systems for a long time. The zfs send -R option to send a
recursive snapsh
Cindy,
The source server is OpenSolaris build 129 (zpool version 22) and the
destination is stock OpenSolaris 2009.06 (zpool version 14). Both
filesystems are zfs version 3.
Mystified,
Daniel Bakken
On Wed, Apr 7, 2010 at 10:57 AM, Cindy Swearingen <
cindy.swearin...@oracle.com> wrote:
> Danie
Daniel,
Which Solaris release is this?
I can't reproduce this on my lab system that runs the Solaris 10 10/09
release.
See the output below.
Thanks,
Cindy
# zfs destroy -r tank/test
# zfs create -o compression=gzip tank/test
# zfs snapshot tank/t...@now
# zfs send -R tank/t...@now | zfs re
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, all properties,
snapshot
15 matches
Mail list logo