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/archive at 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 on gzip 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
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/archive at 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 > <thomas.erickson at oracle.com <mailto:thomas.erickson at 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 on gzip 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 at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
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/archive at 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/archive at 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
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
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/archive at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100407/96703043/attachment.html>
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/test at now # zfs send -R tank/test at now | zfs receive -vd rpool receiving full stream of tank/test at now into rpool/test at now received 249KB stream in 2 seconds (125KB/sec) # zfs list -r rpool NAME USED AVAIL REFER MOUNTPOINT rpool 39.4G 27.5G 47.1M /rpool rpool/ROOT 4.89G 27.5G 21K legacy rpool/ROOT/s10s_u8wos_08a 4.89G 27.5G 4.89G / rpool/dump 1.50G 27.5G 1.50G - rpool/export 44K 27.5G 23K /export rpool/export/home 21K 27.5G 21K /export/home rpool/snaps 31.0G 27.5G 31.0G /rpool/snaps rpool/swap 2G 29.5G 16K - rpool/test 21K 27.5G 21K /rpool/test rpool/test at now 0 - 21K - # zfs get compression rpool/test NAME PROPERTY 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/archive at 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 at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
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.swearingen at 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/test at now > # zfs send -R tank/test at now | zfs receive -vd rpool > receiving full stream of tank/test at now into rpool/test at now > received 249KB stream in 2 seconds (125KB/sec) > # zfs list -r rpool > NAME USED AVAIL REFER MOUNTPOINT > rpool 39.4G 27.5G 47.1M /rpool > rpool/ROOT 4.89G 27.5G 21K legacy > rpool/ROOT/s10s_u8wos_08a 4.89G 27.5G 4.89G / > rpool/dump 1.50G 27.5G 1.50G - > rpool/export 44K 27.5G 23K /export > rpool/export/home 21K 27.5G 21K /export/home > rpool/snaps 31.0G 27.5G 31.0G /rpool/snaps > rpool/swap 2G 29.5G 16K - > rpool/test 21K 27.5G 21K /rpool/test > rpool/test at now 0 - 21K - > # zfs get compression rpool/test > NAME PROPERTY VALUE SOURCE > rpool/test compression gzip local-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100407/6d07eb56/attachment.html>
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/test at now v440-brm-02# zfs send -Rv rpool/test at now | ssh t2k-brm-03 zfs receive -dv tank sending from @ to rpool/test at now . . . Password: receiving full stream of rpool/test at now into tank/test at 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 > <cindy.swearingen at oracle.com <mailto:cindy.swearingen at 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/test at now > # zfs send -R tank/test at now | zfs receive -vd rpool > receiving full stream of tank/test at now into rpool/test at now > received 249KB stream in 2 seconds (125KB/sec) > # zfs list -r rpool > NAME USED AVAIL REFER MOUNTPOINT > rpool 39.4G 27.5G 47.1M /rpool > rpool/ROOT 4.89G 27.5G 21K legacy > rpool/ROOT/s10s_u8wos_08a 4.89G 27.5G 4.89G / > rpool/dump 1.50G 27.5G 1.50G - > rpool/export 44K 27.5G 23K /export > rpool/export/home 21K 27.5G 21K /export/home > rpool/snaps 31.0G 27.5G 31.0G /rpool/snaps > rpool/swap 2G 29.5G 16K - > rpool/test 21K 27.5G 21K /rpool/test > rpool/test at now 0 - 21K - > # zfs get compression rpool/test > NAME PROPERTY VALUE SOURCE > rpool/test compression gzip local >
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/archive at 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.swearingen at 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 >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100407/d5193483/attachment.html>
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 <thomas.erickson at 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 on gzip 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 > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100407/e4bf1034/attachment.html>
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/archive at 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 <thomas.erickson at
oracle.com>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/archive at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100407/29844532/attachment.html>
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 <thomas.erickson at oracle.com>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. >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100407/515a3add/attachment.html>
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 <thomas.erickson at oracle.com > <mailto:thomas.erickson at oracle.com>> 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 at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
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=6700597Solaris 10 ''man zfs'', under ''receive'': -u File system that is associated with the received stream is not mounted. /Tomas -- Tomas ?gren, stric at acc.umu.se, http://www.acc.umu.se/~stric/ |- Student at Computing Science, University of Ume? `- Sysadmin at {cs,acc}.umu.se
On Wed, Apr 7, 2010 at 10:47 AM, Daniel Bakken <daniel at economicmodeling.com> 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 : bhigh at freaks.com