Re: [zfs-discuss] Another user looses his pool (10TB) in this case and 40 days work
Hello, I'm now thinking there is some _real_ bug in the way zfs handles files systems created with the pool itself (ie tank filesystem when zpool is tank, usually mounted as /tank) My own experiens shows that zfs is unable to send/receive recursively (snapshots, child fs) properly when the destination is such a level 0 files system ie othertank, thought everything works as expected when i send to othertank/tank (see my posts) I think you might also see some aspects of this problem Bruno -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs receive : is this expected ?
Sorry if my question was confused. Yes I'm wondering about the catch22 resulting of the two errors : it means we are not able to send/receive a pool's root filesystem without using -F. The zpool list was just meant to say it was a whole pool... Bruno -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs receive : is this expected ?
actually I succeded using : # zfs create ezdata/data # zfs send -RD d...@prededup | zfs recv -duF ezdata/data I still have to check the result, though -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs receive : is this expected ?
I have additional problem, whicxh worries me. I tried different ways of sending/receiving my data pool. I took some snapshots, sent them, then destroyed them, using destroy -r. AFAIK this shoud not have affected the filesystem's _current_ state or am I mislead ? Now I succeeded to send a snapshot and receive it like this : # zfs create ezdata/data # zfs send -RD d...@prededup | zfs recv -duF ezdata/data Im seeing some older versions on the source dataset, newer versions on the snapshot and the copied filesystems. Any idea how this can have happened ? amber ~ # ll -d /data/.zfs/snapshot/prededup/postgres84_64 drwxr-xr-x 2 root root 2 Nov 29 18:20 /data/.zfs/snapshot/prededup/postgres84_64 amber ~ # ll -d /data/postgres84_64 drwx-- 12 postgres postgres 21 Feb 6 22:03 /data/postgres84_64 amber ~ # ll -d /ezdata/data/postgres84_64 drwxr-xr-x 2 root root 2 Nov 29 18:20 /ezdata/data/postgres84_64 -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs send/receive : panic and reboot
On 02/ 8/10 06:38 PM, Lori Alt wrote: Can you please send a complete list of the actions taken: The commands you used to create the send stream, the commands used to receive the stream. Also the output of `zfs list -t all` on both the sending and receiving sides. If you were able to collect a core dump (it should be in /var/crash/hostname), it would be good to upload it. The panic you're seeing is in the code that is specific to receiving a dedup'ed stream. It's possible that you could do the migration if you turned off dedup (i.e. didn't specify -D) when creating the send stream.. However, then we wouldn't be able to diagnose and fix what appears to be a bug. The best way to get us the crash dump is to upload it here: https://supportfiles.sun.com/upload We need either both vmcore.X and unix.X OR you can just send us vmdump.X. Sometimes big uploads have mixed results, so if there is a problem some helpful hints are on http://wikis.sun.com/display/supportfiles/Sun+Support+Files+-+Help+and+Users+Guide, specifically in section 7. It's best to include your name or your initials or something in the name of the file you upload. As you might imagine we get a lot of files uploaded named vmcore.1 You might also create a defect report at http://defect.opensolaris.org/bz/ Lori On 02/08/10 09:41, Bruno Damour wrote: copied from opensolaris-dicuss as this probably belongs here. I kept on trying to migrate my pool with children (see previous threads) and had the (bad) idea to try the -d option on the receive part. The system reboots immediately. Here is the log in /var/adm/messages Feb 8 16:07:09 amber unix: [ID 836849 kern.notice] Feb 8 16:07:09 amber ^Mpanic[cpu1]/thread=ff014ba86e40: Feb 8 16:07:09 amber genunix: [ID 169834 kern.notice] avl_find() succeeded inside avl_add() Feb 8 16:07:09 amber unix: [ID 10 kern.notice] Feb 8 16:07:09 amber genunix: [ID 655072 kern.notice] ff00053c4660 genunix:avl_add+59 () Feb 8 16:07:09 amber genunix: [ID 655072 kern.notice] ff00053c46c0 zfs:find_ds_by_guid+b9 () Feb 8 16:07:09 amber genunix: [ID 655072 kern.notice] ff00053c46f0 zfs:findfunc+23 () Feb 8 16:07:09 amber genunix: [ID 655072 kern.notice] ff00053c47d0 zfs:dmu_objset_find_spa+38c () Feb 8 16:07:09 amber genunix: [ID 655072 kern.notice] ff00053c4810 zfs:dmu_objset_find+40 () Feb 8 16:07:09 amber genunix: [ID 655072 kern.notice] ff00053c4a70 zfs:dmu_recv_stream+448 () Feb 8 16:07:09 amber genunix: [ID 655072 kern.notice] ff00053c4c40 zfs:zfs_ioc_recv+41d () Feb 8 16:07:09 amber genunix: [ID 655072 kern.notice] ff00053c4cc0 zfs:zfsdev_ioctl+175 () Feb 8 16:07:09 amber genunix: [ID 655072 kern.notice] ff00053c4d00 genunix:cdev_ioctl+45 () Feb 8 16:07:09 amber genunix: [ID 655072 kern.notice] ff00053c4d40 specfs:spec_ioctl+5a () Feb 8 16:07:09 amber genunix: [ID 655072 kern.notice] ff00053c4dc0 genunix:fop_ioctl+7b () Feb 8 16:07:09 amber genunix: [ID 655072 kern.notice] ff00053c4ec0 genunix:ioctl+18e () Feb 8 16:07:09 amber genunix: [ID 655072 kern.notice] ff00053c4f10 unix:brand_sys_syscall32+1ca () Feb 8 16:07:09 amber unix: [ID 10 kern.notice] Feb 8 16:07:09 amber genunix: [ID 672855 kern.notice] syncing file systems... Feb 8 16:07:09 amber genunix: [ID 904073 kern.notice] done Feb 8 16:07:10 amber genunix: [ID 111219 kern.notice] dumping to /dev/zvol/dsk/rpool/dump, offset 65536, content: kernel Feb 8 16:07:10 amber ahci: [ID 405573 kern.info] NOTICE: ahci0: ahci_tran_reset_dport port 3 reset port Feb 8 16:07:35 amber genunix: [ID 10 kern.notice] Feb 8 16:07:35 amber genunix: [ID 665016 kern.notice] ^M100% done: 107693 pages dumped, Feb 8 16:07:35 amber genunix: [ID 851671 kern.notice] dump succeeded Hello, I'll try to do my best. Here are the commands : amber ~ # zfs unmount data amber ~ # zfs snapshot -r d...@prededup amber ~ # zpool destroy ezdata amber ~ # zpool create ezdata c6t1d0 amber ~ # zfs set dedup=on ezdata amber ~ # zfs set compress=on ezdata amber ~ # zfs send -RD d...@prededup |zfs receive ezdata/data cannot receive new filesystem stream: destination 'ezdata/data' exists must specify -F to overwrite it amber ~ # zpool destroy ezdata amber ~ # zpool create ezdata c6t1d0 amber ~ # zfs set compression=on ezdata amber ~ # zfs set dedup=on ezdata amber ~ # zfs send -RD d...@prededup |zfs receive -F ezdata/data cannot receive new filesystem stream: destination has snapshots (eg. ezdata/d...@prededup) must destroy them to overwrite it Each time the send/receive command took some hours and transferred 151G data before issuing the message amber ~ # zfs list NAME USED AVAIL REFER MOUNTPOINT data 295G 621G 161G /data data/archive 134G 621G 67.7G /data/archive data/archive/scanrisk 9.45G 621G 8.03G /data/archive/scanrisk
[zfs-discuss] zfs receive : is this expected ?
amber ~ # zpool list data NAME SIZE ALLOC FREECAP DEDUP HEALTH ALTROOT data 930G 295G 635G31% 1.00x ONLINE - amber ~ # zfs send -RD d...@prededup |zfs recv -d ezdata cannot receive new filesystem stream: destination 'ezdata' exists must specify -F to overwrite it amber ~ # zfs send -RD d...@prededup |zfs recv -d ezdata/data cannot receive: specified fs (ezdata/data) does not exist -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] zfs send/receive : panic and reboot
copied from opensolaris-dicuss as this probably belongs here. I kept on trying to migrate my pool with children (see previous threads) and had the (bad) idea to try the -d option on the receive part. The system reboots immediately. Here is the log in /var/adm/messages Feb 8 16:07:09 amber unix: [ID 836849 kern.notice] Feb 8 16:07:09 amber ^Mpanic[cpu1]/thread=ff014ba86e40: Feb 8 16:07:09 amber genunix: [ID 169834 kern.notice] avl_find() succeeded inside avl_add() Feb 8 16:07:09 amber unix: [ID 10 kern.notice] Feb 8 16:07:09 amber genunix: [ID 655072 kern.notice] ff00053c4660 genunix:avl_add+59 () Feb 8 16:07:09 amber genunix: [ID 655072 kern.notice] ff00053c46c0 zfs:find_ds_by_guid+b9 () Feb 8 16:07:09 amber genunix: [ID 655072 kern.notice] ff00053c46f0 zfs:findfunc+23 () Feb 8 16:07:09 amber genunix: [ID 655072 kern.notice] ff00053c47d0 zfs:dmu_objset_find_spa+38c () Feb 8 16:07:09 amber genunix: [ID 655072 kern.notice] ff00053c4810 zfs:dmu_objset_find+40 () Feb 8 16:07:09 amber genunix: [ID 655072 kern.notice] ff00053c4a70 zfs:dmu_recv_stream+448 () Feb 8 16:07:09 amber genunix: [ID 655072 kern.notice] ff00053c4c40 zfs:zfs_ioc_recv+41d () Feb 8 16:07:09 amber genunix: [ID 655072 kern.notice] ff00053c4cc0 zfs:zfsdev_ioctl+175 () Feb 8 16:07:09 amber genunix: [ID 655072 kern.notice] ff00053c4d00 genunix:cdev_ioctl+45 () Feb 8 16:07:09 amber genunix: [ID 655072 kern.notice] ff00053c4d40 specfs:spec_ioctl+5a () Feb 8 16:07:09 amber genunix: [ID 655072 kern.notice] ff00053c4dc0 genunix:fop_ioctl+7b () Feb 8 16:07:09 amber genunix: [ID 655072 kern.notice] ff00053c4ec0 genunix:ioctl+18e () Feb 8 16:07:09 amber genunix: [ID 655072 kern.notice] ff00053c4f10 unix:brand_sys_syscall32+1ca () Feb 8 16:07:09 amber unix: [ID 10 kern.notice] Feb 8 16:07:09 amber genunix: [ID 672855 kern.notice] syncing file systems... Feb 8 16:07:09 amber genunix: [ID 904073 kern.notice] done Feb 8 16:07:10 amber genunix: [ID 111219 kern.notice] dumping to /dev/zvol/dsk/rpool/dump, offset 65536, content: kernel Feb 8 16:07:10 amber ahci: [ID 405573 kern.info] NOTICE: ahci0: ahci_tran_reset_dport port 3 reset port Feb 8 16:07:35 amber genunix: [ID 10 kern.notice] Feb 8 16:07:35 amber genunix: [ID 665016 kern.notice] ^M100% done: 107693 pages dumped, Feb 8 16:07:35 amber genunix: [ID 851671 kern.notice] dump succeeded -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] help with zfs send/receive
Hello, I'm trying to migrate my data pool to get dedup and compression. I tried : # zfs send -RD d...@prededup |zfs receive ezdata/data it fails in the end with : cannot receive new filesystem stream: destination 'ezdata/data' exists must specify -F to overwrite it the ezdata pool has just been (re)created and is completely empty Now even with that message it has anyway created a data fs on the new pool and copied 151G of data, which might well be the whole data filesystem, but none of the other fs that were on the same pool, ie data/archive, data/archive/scanrisk, data/postgres84_64, data/cyrus23, and their snapshots have not been copied. What is the exact signification of this message and what should I do ? Thanks in advance bruno -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] help with zfs send/receive
No success, I tried with -F thought I do not like these tricks, but now it complains about snapshost existing in destination. Destination did not exist before, so what ? -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] help with zfs send/receive
On 02/ 7/10 12:57 PM, Thomas Burgess wrote: I just started using send/receive myself yesterday. This is what i found out I wanted to do the same thing, i had a filesystem called Video in my tank pool, it looked like this: tank/nas/Video (pool was tank, it was a child of nas) and it was mounted at /tank/nas/Video I tried to send it to tank/test/Video so i made a snapshot zfs snapshot tank/nas/vi...@base then i created a new filesystem with compression: zfs create tank/test zfs create tank/test/Video zfs compression=on tank/test/Video then i tried to send it zfs send tank/nas/vi...@base | zfs receive tank/test/Video and i got the same error. what i found out was, i needed to drop the Video part and do it like this: zfs destroy tank/test/Video then turn on compression on the CHILD like this: zfs set compression=on tank/test then send it like this: zfs send tank/nas/vi...@base | zfs receive tank/test/Video This did what i neededi hope this helps On Sun, Feb 7, 2010 at 6:48 AM, Bruno Damour br...@ruomad.net mailto:br...@ruomad.net wrote: Hello, I'm trying to migrate my data pool to get dedup and compression. I tried : # zfs send -RD d...@prededup |zfs receive ezdata/data it fails in the end with : cannot receive new filesystem stream: destination 'ezdata/data' exists must specify -F to overwrite it the ezdata pool has just been (re)created and is completely empty Now even with that message it has anyway created a data fs on the new pool and copied 151G of data, which might well be the whole data filesystem, but none of the other fs that were on the same pool, ie data/archive, data/archive/scanrisk, data/postgres84_64, data/cyrus23, and their snapshots have not been copied. What is the exact signification of this message and what should I do ? Thanks in advance bruno -- This message posted from opensolaris.org http://opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org mailto:zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss Well, your solution was what I tried in the first place, so it won't work for me. I think somehow the problem is linked to child datasets It does copy the parent (data) but stops after that. I thnk the message is unaccurate as it creates the data fs... itself ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
