Re: [zfs-discuss] compression property not received

[Brandon High]

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?

I think only locally set properties are preserved.

-B

-- 
Brandon High : bh...@freaks.com
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] compression property not received

[Tomas Ögren]

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.do?bug_id=6700597

Solaris 10 'man zfs', under 'receive':

 -uFile system that is associated with  the  received
   stream is not mounted.

/Tomas
-- 
Tomas Ögren, st...@acc.umu.se, http://www.acc.umu.se/~stric/
|- Student at Computing Science, University of Umeå
`- Sysadmin at {cs,acc}.umu.se
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] compression property not received

[Cindy Swearingen]

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 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 effectively set at defaults. This caused the receiver to 
stop processing subsequent properties in the stream because the 
mountpoint isn't valid on the receiver.


I tested this theory with a spare zpool. First I used "zfs inherit 
mountpoint promise1/archive" to remove the "local" setting (which was 
exactly the same value as the default). This time the compression=gzip 
property was correctly received.


It seems like a bug to me that one failed property in a stream prevents 
the rest from being applied. I should have used zfs inherit, but it 
would be best if zfs receive handled failures more gracefully, and 
attempted to set as many properties as possible.


Thanks to Cindy and Tom for their help.

Daniel

On Wed, Apr 7, 2010 at 2:31 AM, Tom Erickson > wrote:



Now I remember that 'zfs receive' used to give up after the first
property it failed to set. If I'm remembering correctly, then, in
this case, if the mountpoint was invalid on the receive side, 'zfs
receive' would not even try to set the remaining properties.

I'd try the following in the source dataset:

zfs inherit mountpoint promise1/archive

to clear the explicit mountpoint and prevent it from being included
in the send stream. Later set it back the way it was. (Soon there
will be an option to take care of that; see CR 6883722 want 'zfs
recv -o prop=value' to set initial property values of received
dataset.) Then see if you receive the compression property successfully.




___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] compression property not received

[Tom Erickson]

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 the local 
properties are effectively set at defaults. This caused the receiver to 
stop processing subsequent properties in the stream because the 
mountpoint isn't valid on the receiver.


I tested this theory with a spare zpool. First I used "zfs inherit 
mountpoint promise1/archive" to remove the "local" setting (which was 
exactly the same value as the default). This time the compression=gzip 
property was correctly received.


It seems like a bug to me that one failed property in a stream prevents 
the rest from being applied. I should have used zfs inherit, but it 
would be best if zfs receive handled failures more gracefully, and 
attempted to set as many properties as possible.


Yes, that was fixed in build 128.


Thanks to Cindy and Tom for their help.


Glad to hear we identified the problem. Sorry for the trouble.

Tom
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] compression property not received

[Tom Erickson]

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...@daily.1

nvlist version: 0
tosnap = daily.1
fss = (embedded nvlist)
nvlist version: 0
0xcfde021e56c8fc = (embedded nvlist)
nvlist version: 0
name = promise1/archive
parentfromsnap = 0x0
props = (embedded nvlist)
nvlist version: 0
mountpoint = /promise1/archive
compression = 0xa
dedup = 0x2
(end props)

I assume that compression = 0xa means gzip.


Yep, that's ZIO_COMPRESS_GZIP_6, the default gzip.

I wonder if the dedup 
property is causing the receiver (build 111b)  to disregard all other 
properties, since the receiver doesn't support dedup. Dedup was enabled 
in the past on the sending filesystem, but is now disabled for reasons 
of sanity.




Now I remember that 'zfs receive' used to give up after the first 
property it failed to set. If I'm remembering correctly, then, in this 
case, if the mountpoint was invalid on the receive side, 'zfs receive' 
would not even try to set the remaining properties.


You could try 'zfs get mountpoint' (or 'zdb -vvv poolname > file' and 
search the file for 'mountpoint') to see if that was set.


I'd like to try the dtrace debugging, but it would destroy the progress 
I've made so far transferring the filesystem.




Maybe you could try receiving into a new pool that you can later throw away.

zpool create bogustestpool c0t0d0
zfs send -R promise1/arch...@daily.1 | zfs receive -vd bogustestpool

I'd try the following in the source dataset:

zfs inherit mountpoint promise1/archive

to clear the explicit mountpoint and prevent it from being included in 
the send stream. Later set it back the way it was. (Soon there will be 
an option to take care of that; see CR 6883722 want 'zfs recv -o 
prop=value' to set initial property values of received dataset.) Then 
see if you receive the compression property successfully.


Tom
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] compression property not received

[Tom Erickson]

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 stream with zstreamdump, since the send side is running 
build 129. To debug the receive side I might dtrace the zap_update() 
function with the fbt provider, something like


zfs send -R promise1/arch...@daily.1 | dtrace -c 'zfs receive -vd sas' \ 
-n 'fbt::zap_update:entry / stringof(args[2]) == "compression" ||  \

stringof(args[2]) == "compression$recvd" / { self->trace = 1; }'  \
-n 'fbt::zap_update:return / self->trace / { trace(args[1]); \
self->trace = 0; }'

and look for non-zero return values.

I'd also redirect '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.erick...@oracle.com>> wrote:
 


After build 128, locally set properties override received
properties, and this would be the expected behavior. In that case,
the value was received and you can see it like this:

% zfs get -o all compression tank
NAME  PROPERTY VALUE RECEIVED  SOURCE
tank  compression  ongzip  local
%

You could make the received value the effective value (clearing the
local value) like this:

% zfs inherit -S compression tank
% zfs get -o all compression tank
NAME  PROPERTY VALUE RECEIVED  SOURCE
tank  compression  gzip  gzip  received
%

If the receive side is below the version that supports received
properties, then I would expect the receive to set compression=gzip.

After build 128 'zfs receive' prints an error message for every
property it fails to set. Before that version, 'zfs receive' is
silent when it fails to set a property so long as everything else is
successful. I might check whether I have permission to set
compression with 'zfs allow'. You could pipe the send stream to
zstreamdump to verify that compression=gzip is in the send stream,
but I think before build 125 you will not have zstreamdump.

Tom





___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss


___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] compression property not received

[Tom Erickson]

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, all 
properties, snapshots, descendent file systems, and clones are 
preserved." Snapshots are preserved, but the compression property is 
not. Any ideas why this doesn't work as advertised?




After build 128, locally set properties override received properties, 
and this would be the expected behavior. In that case, the value was 
received and you can see it like this:


% zfs get -o all compression tank
NAME  PROPERTY VALUE RECEIVED  SOURCE
tank  compression  ongzip  local
%

You could make the received value the effective value (clearing the 
local value) like this:


% zfs inherit -S compression tank
% zfs get -o all compression tank
NAME  PROPERTY VALUE RECEIVED  SOURCE
tank  compression  gzip  gzip  received
%

If the receive side is below the version that supports received 
properties, then I would expect the receive to set compression=gzip.


After build 128 'zfs receive' prints an error message for every property 
it fails to set. Before that version, 'zfs receive' is silent when it 
fails to set a property so long as everything else is successful. I 
might check whether I have permission to set compression with 'zfs 
allow'. You could pipe the send stream to zstreamdump to verify that 
compression=gzip is in the send stream, but I think before build 125 you 
will not have zstreamdump.


Tom

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] compression property not received

[Daniel Bakken]

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
effectively set at defaults. This caused the receiver to stop processing
subsequent properties in the stream because the mountpoint isn't valid on
the receiver.

I tested this theory with a spare zpool. First I used "zfs inherit
mountpoint promise1/archive" to remove the "local" setting (which was
exactly the same value as the default). This time the compression=gzip
property was correctly received.

It seems like a bug to me that one failed property in a stream prevents the
rest from being applied. I should have used zfs inherit, but it would be
best if zfs receive handled failures more gracefully, and attempted to set
as many properties as possible.

Thanks to Cindy and Tom for their help.

Daniel

On Wed, Apr 7, 2010 at 2:31 AM, Tom Erickson wrote:

>
> Now I remember that 'zfs receive' used to give up after the first property
> it failed to set. If I'm remembering correctly, then, in this case, if the
> mountpoint was invalid on the receive side, 'zfs receive' would not even try
> to set the remaining properties.
>
> I'd try the following in the source dataset:
>
> zfs inherit mountpoint promise1/archive
>
> to clear the explicit mountpoint and prevent it from being included in the
> send stream. Later set it back the way it was. (Soon there will be an option
> to take care of that; see CR 6883722 want 'zfs recv -o prop=value' to set
> initial property values of received dataset.) Then see if you receive the
> compression property successfully.
>
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] compression property not received

[Daniel Bakken]

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: 0
tosnap = daily.1
fss = (embedded nvlist)
nvlist version: 0
0xcfde021e56c8fc = (embedded nvlist)
nvlist version: 0
name = promise1/archive
parentfromsnap = 0x0
props = (embedded nvlist)
nvlist version: 0
mountpoint = /promise1/archive
compression = 0xa
dedup = 0x2
(end props)

I assume that compression = 0xa means gzip. I wonder if the dedup property
is causing the receiver (build 111b)  to disregard all other properties,
since the receiver doesn't support dedup. Dedup was enabled in the past on
the sending filesystem, but is now disabled for reasons of sanity.

I'd like to try the dtrace debugging, but it would destroy the progress I've
made so far transferring the filesystem.

Thanks,

Daniel

On Wed, Apr 7, 2010 at 12:52 AM, Tom Erickson wrote:

>
> The advice regarding received vs local properties definitely does not
> apply. You could still confirm the presence of the compression property in
> the send stream with zstreamdump, since the send side is running build 129.
> To debug the receive side I might dtrace the zap_update() function with the
> fbt provider, something like
>
> zfs send -R promise1/arch...@daily.1 | dtrace -c 'zfs receive -vd sas' \
> -n 'fbt::zap_update:entry / stringof(args[2]) == "compression" ||  \
> stringof(args[2]) == "compression$recvd" / { self->trace = 1; }'  \
> -n 'fbt::zap_update:return / self->trace / { trace(args[1]); \
> self->trace = 0; }'
>
> and look for non-zero return values.
>
> I'd also redirect '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
>
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] compression property not received

[Daniel Bakken]

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 behavior. In that case, the value was received
> and you can see it like this:
>
> % zfs get -o all compression tank
> NAME  PROPERTY VALUE RECEIVED  SOURCE
> tank  compression  ongzip  local
> %
>
> You could make the received value the effective value (clearing the local
> value) like this:
>
> % zfs inherit -S compression tank
> % zfs get -o all compression tank
> NAME  PROPERTY VALUE RECEIVED  SOURCE
> tank  compression  gzip  gzip  received
> %
>
> If the receive side is below the version that supports received properties,
> then I would expect the receive to set compression=gzip.
>
> After build 128 'zfs receive' prints an error message for every property it
> fails to set. Before that version, 'zfs receive' is silent when it fails to
> set a property so long as everything else is successful. I might check
> whether I have permission to set compression with 'zfs allow'. You could
> pipe the send stream to zstreamdump to verify that compression=gzip is in
> the send stream, but I think before build 125 you will not have zstreamdump.
>
> Tom
>
>
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] compression property not received

[Daniel Bakken]

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 -vFd sas

And now I have gzip compression enabled locally:

zfs get compression sas/archive
NAME PROPERTY VALUE SOURCE
sas/archive  compression  gzip  local

Not pretty, but it works.

Daniel Bakken


On Wed, Apr 7, 2010 at 12:51 PM, Cindy Swearingen <
cindy.swearin...@oracle.com> wrote:

> 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 snapshot and all properties integrated into b77 so that
> isn't your problem either.
>
> The above works as expected. See below.
>
> I also couldn't find any recent bugs related to this, but bug searching is
> not an exact science.
>
> Mystified as well...
>
> Cindy
>
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] compression property not received

[Cindy Swearingen]

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 snapshot and all properties integrated into b77 so that
isn't your problem either.

The above works as expected. See below.

I also couldn't find any recent bugs related to this, but bug searching 
is not an exact science.


Mystified as well...

Cindy

v440-brm-02# zfs create -o compression=gzip rpool/test
v440-brm-02# zfs snapshot rpool/t...@now
v440-brm-02# zfs send -Rv rpool/t...@now | ssh t2k-brm-03 zfs receive 
-dv tank

sending from @ to rpool/t...@now
.
.
.
Password:
receiving full stream of rpool/t...@now into tank/t...@now
received 8KB stream in 1 seconds (8KB/sec)
t2k-brm-03# zfs get compression tank/test
NAME   PROPERTY VALUE SOURCE
tank/test  compression  gzip  local


On 04/07/10 12:05, Daniel Bakken wrote:

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 
mailto:cindy.swearin...@oracle.com>> wrote:


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 receive -vd rpool
receiving full stream of tank/t...@now into rpool/t...@now
received 249KB stream in 2 seconds (125KB/sec)
# zfs list -r rpool
NAMEUSED  AVAIL  REFER  MOUNTPOINT
rpool  39.4G  27.5G  47.1M  /rpool
rpool/ROOT 4.89G  27.5G21K  legacy
rpool/ROOT/s10s_u8wos_08a  4.89G  27.5G  4.89G  /
rpool/dump 1.50G  27.5G  1.50G  -
rpool/export 44K  27.5G23K  /export
rpool/export/home21K  27.5G21K  /export/home
rpool/snaps31.0G  27.5G  31.0G  /rpool/snaps
rpool/swap2G  29.5G16K  -
rpool/test   21K  27.5G21K  /rpool/test
rpool/t...@now 0  -21K  -
# zfs get compression rpool/test
NAMEPROPERTY VALUE SOURCE
rpool/test  compression  gzip  local


___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] compression property not received

[Daniel Bakken]

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:

> 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 receive -vd rpool
> receiving full stream of tank/t...@now into rpool/t...@now
> received 249KB stream in 2 seconds (125KB/sec)
> # zfs list -r rpool
> NAMEUSED  AVAIL  REFER  MOUNTPOINT
> rpool  39.4G  27.5G  47.1M  /rpool
> rpool/ROOT 4.89G  27.5G21K  legacy
> rpool/ROOT/s10s_u8wos_08a  4.89G  27.5G  4.89G  /
> rpool/dump 1.50G  27.5G  1.50G  -
> rpool/export 44K  27.5G23K  /export
> rpool/export/home21K  27.5G21K  /export/home
> rpool/snaps31.0G  27.5G  31.0G  /rpool/snaps
> rpool/swap2G  29.5G16K  -
> rpool/test   21K  27.5G21K  /rpool/test
> rpool/t...@now 0  -21K  -
> # zfs get compression rpool/test
> NAMEPROPERTY VALUE SOURCE
> rpool/test  compression  gzip  local
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] compression property not received

[Cindy Swearingen]

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 receive -vd rpool
receiving full stream of tank/t...@now into rpool/t...@now
received 249KB stream in 2 seconds (125KB/sec)
# zfs list -r rpool
NAMEUSED  AVAIL  REFER  MOUNTPOINT
rpool  39.4G  27.5G  47.1M  /rpool
rpool/ROOT 4.89G  27.5G21K  legacy
rpool/ROOT/s10s_u8wos_08a  4.89G  27.5G  4.89G  /
rpool/dump 1.50G  27.5G  1.50G  -
rpool/export 44K  27.5G23K  /export
rpool/export/home21K  27.5G21K  /export/home
rpool/snaps31.0G  27.5G  31.0G  /rpool/snaps
rpool/swap2G  29.5G16K  -
rpool/test   21K  27.5G21K  /rpool/test
rpool/t...@now 0  -21K  -
# zfs get compression rpool/test
NAMEPROPERTY VALUE SOURCE
rpool/test  compression  gzip  local

On 04/07/10 11:47, 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, all 
properties, snapshots, descendent file systems, and clones are 
preserved." Snapshots are preserved, but the compression property is 
not. Any ideas why this doesn't work as advertised?


Thanks,

Daniel Bakken




___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

[zfs-discuss] compression property not received

[Daniel Bakken]

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,
snapshots, descendent file systems, and clones are preserved." Snapshots are
preserved, but the compression property is not. Any ideas why this doesn't
work as advertised?

Thanks,

Daniel Bakken
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss