Hi; After some very hairy testing, I came up with the following procedure for sending a zfs send datastream to a gzip staging file and later "receiving" it back to the same filesystem in the same pool. The above was to enable the filesystem data to be dedup. Here is the procedure and under careful examination there seems to be a bug (my mistake?) at the end.... Firstly, the zfs file system in question has the following children.. oot at sunlight:/root# zfs list -t all -r myplace/Docs NAME USED AVAIL REFER MOUNTPOINT myplace/Docs 3.37G 1.05T 3.33G /export/home/admin/Docs <-- NOTE ORIGINAL MOUNTPOINT (see later bug below) myplace/Docs at scriptsnap2 43.0M - 3.33G - myplace/Docs at scriptsnap3 0 - 3.33G - <-- latest snapshot myplace/Docs at scriptsnap1 0 - 3.33G - As root, i did root at sunlight:/root# zfs send -R myplace/Docs at scriptsnap3 | gzip -9c > /var/tmp/myplace-Docs.snapshot.gz Then I attempted to test a zfs receive by using the "-n" option... admin at sunlight:/var/tmp$ gzip -cd /var/tmp/myplace-Docs.snapshot.gz | zfs receive -dnv myplace cannot receive new filesystem stream: destination ''myplace/Docs'' exists must specify -F to overwrite it Ok...let''s specify -F... admin at sunlight:/var/tmp$ gzip -cd /var/tmp/myplace-Docs.snapshot.gz | zfs receive -dFnv myplace cannot receive new filesystem stream: destination has snapshots (eg. myplace/Docs at scriptsnap1) must destroy them to overwrite it Ok fine...let''s destroy the existing snapshots for myplace/Docs... admin at sunlight:/var/tmp$ zfs list -t snapshot -r myplace/Docs NAME USED AVAIL REFER MOUNTPOINT myplace/Docs at scriptsnap2 43.0M - 3.33G - myplace/Docs at scriptsnap3 0 - 3.33G - myplace/Docs at scriptsnap1 0 - 3.33G - root at sunlight:/root# zfs destroy myplace/Docs at scriptsnap2 root at sunlight:/root# zfs destroy myplace/Docs at scriptsnap1 root at sunlight:/root# zfs destroy myplace/Docs at scriptsnap3 Checking... root at sunlight:/root# zfs list -t all -r myplace/Docs NAME USED AVAIL REFER MOUNTPOINT myplace/Docs 3.33G 1.05T 3.33G /export/home/admin/Docs Ok...no more snapshots, just the parent myplace/Docs and no children... Let''s try the zfs receive command yet again with a "-n" root at sunlight:/root# gzip -cd /var/tmp/myplace-Docs.snapshot.gz | zfs receive -dFnv myplace would receive full stream of myplace/Docs at scriptsnap2 into myplace/Docs at scriptsnap2 would receive incremental stream of myplace/Docs at scriptsnap3 into myplace/Docs at scriptsnap3 Looks great! OK...let''s go for the real thing... root at sunlight:/root# gzip -cd /var/tmp/myplace-Docs.snapshot.gz | zfs receive -dFv myplace receiving full stream of myplace/Docs at scriptsnap2 into myplace/Docs at scriptsnap2 received 3.35GB stream in 207 seconds (16.6MB/sec) receiving incremental stream of myplace/Docs at scriptsnap3 into myplace/Docs at scriptsnap3 received 47.6MB stream in 6 seconds (7.93MB/sec) Yahoooo...looks good! BUT... A zfs list of myplace/Docs I get.. root at sunlight:/root# zfs list -r myplace/Docs NAME USED AVAIL REFER MOUNTPOINT myplace/Docs 3.37G 1.05T 3.33G /export/home/admin/Docs/e/Docs <--- WHAT????? Where in the world did the extra "e/Docs" come from????????? UH????? root at sunlight:/root# zfs set mountpoint=/export/home/admin/Docs myplace/Docs cannot mount ''/export/home/admin/Docs'': directory is not empty property may be set but unable to remount filesystem Ok... I then went to remove the e/Docs directory under /export/home/admin/Docs.... and it is now only /export/home/admin/Docs... Then.. root at sunlight:/root# zfs set mountpoint=/export/home/admin/Docs myplace/Docs And all is well again.. Where did the "e" come from? Did I do something wrong? Warmest Regards Steven Sim