|
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. However, after the final ZFS received, i noticed that the same ZFS filesystem mountpoint had changed by itself and added an extra "e" subdirectory..... Here is the procedure.... Firstly, the zfs file system in question has the following children.. o...@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/d...@scriptsnap2 43.0M - 3.33G - myplace/d...@scriptsnap3 0 - 3.33G - <-- latest snapshot myplace/d...@scriptsnap1 0 - 3.33G - As root, i did r...@sunlight:/root# zfs send -R myplace/d...@scriptsnap3 | gzip -9c > /var/tmp/myplace-Docs.snapshot.gz Then I attempted to test a zfs receive by using the "-n" option... ad...@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... ad...@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/d...@scriptsnap1) must destroy them to overwrite it Ok fine...let's destroy the existing snapshots for myplace/Docs... ad...@sunlight:/var/tmp$ zfs list -t snapshot -r myplace/Docs NAME USED AVAIL REFER MOUNTPOINT myplace/d...@scriptsnap2 43.0M - 3.33G - myplace/d...@scriptsnap3 0 - 3.33G - myplace/d...@scriptsnap1 0 - 3.33G - r...@sunlight:/root# zfs destroy myplace/d...@scriptsnap2 r...@sunlight:/root# zfs destroy myplace/d...@scriptsnap1 r...@sunlight:/root# zfs destroy myplace/d...@scriptsnap3 Checking... r...@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" r...@sunlight:/root# gzip -cd /var/tmp/myplace-Docs.snapshot.gz | zfs receive -dFnv myplace would receive full stream of myplace/d...@scriptsnap2 into myplace/d...@scriptsnap2 would receive incremental stream of myplace/d...@scriptsnap3 into myplace/d...@scriptsnap3 Looks great! OK...let's go for the real thing... r...@sunlight:/root# gzip -cd /var/tmp/myplace-Docs.snapshot.gz | zfs receive -dFv myplace receiving full stream of myplace/d...@scriptsnap2 into myplace/d...@scriptsnap2 received 3.35GB stream in 207 seconds (16.6MB/sec) receiving incremental stream of myplace/d...@scriptsnap3 into myplace/d...@scriptsnap3 received 47.6MB stream in 6 seconds (7.93MB/sec) Yahoooo...looks good! BUT... A zfs list of myplace/Docs I get.. r...@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 <--- *** Here is the extra "e/Docs".. r...@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.. r...@sunlight:/root# zfs set mountpoint=/export/home/admin/Docs myplace/Docs And all is well again.. Where did the "e/Docs" come from? Did I do something wrong? Warmest Regards Steven Sim |
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
