[zfs-discuss] lost pool metadata
Gremlins in my machine have deleted most of the pool metadata and I need to know if it is possible to recover. Setup is 8 disks in an external enclosure configured as raidz2 attached to a macpro running openindiana under vmware fusion. This has worked fine for a number of months with the only caveat that whenever the Mac is rebooted you have to rebuild the virtual disk descriptions. If you don't then vmware complains of missing disks and won't start openindiana or zfs complains of corruption. When they are rebuilt and properly named then there are no problems. I updated fusion so I had to reboot and when I did my script failed because vmware had moved their utility so I got the expected corruption message from zfs. However this time it did not go away when the disk descriptions etc were properly done. On the Mac diskutility now reports some disks as unlabeled and unformatted and some with just a GUID label. Before they were all efi zfs. Maybe this is causing zfs to look in the wrong places. Looking at the disks with dd etc some have the labels and metadata basically all nulls some have garbage and some appear to have good info. Is it possible to have that good info copied to other disks into the right places to allow the pool to be recovered ? Any ideas and which part of that system actually deleted the data? ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Interesting question about L2ARC
Interesting, They are in and running and I'm hitting on them pretty good. One thing I did change: I've seen recommendations (one in particular from nexenta) that recommends an 8KB recordsize for virtualization workloads (which is 100% of my workload). I Svmotion'ed all the VMs off the datastore and back (to get new smaller recordsize.) I wonder if that has an effect? -Original Message- From: Sašo Kiselkov [mailto:skiselkov...@gmail.com] Sent: Tuesday, September 11, 2012 10:12 AM To: Dan Swartzendruber Cc: 'James H'; zfs-discuss@opensolaris.org Subject: Re: [zfs-discuss] Interesting question about L2ARC On 09/11/2012 04:06 PM, Dan Swartzendruber wrote: Thanks a lot for clarifying how this works. You're very welcome. Since I'm quite happy having an SSD in my workstation, I will need to purchase another SSD :) I'm wondering if it makes more sense to buy two SSDs of half the size (e.g. 128GB), since the total price is about the same? If you have the space/ports and it costs the same, two SSDs will definitely give you better iops and throughput than a single SSD twice the size. Cheers, -- Saso ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Zvol vs zfs send/zfs receive
I need a bit of a sanity check here. 1) I have a a RAIDZ2 of 8 1TB drives, so 6TB usable, running on an ancient version of OpenSolaris (snv_134 I think). On that zpool (miniraid) I have a zvol (RichRAID) that's using almost the whole FS. It's shared out via COMSTAR Fibre Channel target mode. I'd like to move that zvol to a newer server with a larger zpool. Sounds like a job for ZFS send/receive, right? 2) Since ZFS send/receive is snapshot-based I need to create a snapshot. Unfortunately I did not realize that zvols require disk space sufficient to duplicate the zvol, and my zpool wasn't big enough. After a false start (zpool add is dangerous when low on sleep) I added a 250GB mirror and a pair of 3GB mirrors to miniraid and was able to successfully snapshot the zvol: miniraid/RichRAID@exportable (I ended up booting off an OI 151a5 USB stick to make that work, since I don't believe snv_134 could handle a 3TB disk). 3) Now it's easy, right? I enabled root login via SSH on the new host, which is running a zpool archive1 consisting of a single RAIDZ2 of 3TB drives using ashift=12, and did a ZFS send: ZFS send miniraid/RichRAID@exportable | ssh root@newhost zfs receive archive1/RichRAID It asked for the root password, I gave it that password, and it was off and running. GigE ain't super fast, but I've got time. The problem: so far the send/recv appears to have copied 6.25TB of 5.34TB. That... doesn't look right. (Comparing zfs list -t snapshot and looking at the 5.34 ref for the snapshot vs zfs list on the new system and looking at space used.) Is this a problem? Should I be panicking yet? -- Dave Pooser Manager of Information Services Alford Media http://www.alfordmedia.com ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Zvol vs zfs send/zfs receive
From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- boun...@opensolaris.org] On Behalf Of Dave Pooser Unfortunately I did not realize that zvols require disk space sufficient to duplicate the zvol, and my zpool wasn't big enough. After a false start (zpool add is dangerous when low on sleep) I added a 250GB mirror and a pair of 3GB mirrors to miniraid and was able to successfully snapshot the zvol: miniraid/RichRAID@exportable This doesn't make any sense to me. The snapshot should not take up any (significant) space on the sending side. It's only on the receiving side, trying to receive a snapshot, that you require space. Because it won't clobber the existing zvol on the receiving side until the complete new zvol was received to clobber it with. But simply creating the snapshot on the sending side should be no problem. The problem: so far the send/recv appears to have copied 6.25TB of 5.34TB. That... doesn't look right. I don't know why that happens, but sometimes it happens. So far, I've always waited it out, and so far it's always succeeded for me. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Zvol vs zfs send/zfs receive
On 09/15/12 04:46 PM, Dave Pooser wrote: I need a bit of a sanity check here. 1) I have a a RAIDZ2 of 8 1TB drives, so 6TB usable, running on an ancient version of OpenSolaris (snv_134 I think). On that zpool (miniraid) I have a zvol (RichRAID) that's using almost the whole FS. It's shared out via COMSTAR Fibre Channel target mode. I'd like to move that zvol to a newer server with a larger zpool. Sounds like a job for ZFS send/receive, right? 2) Since ZFS send/receive is snapshot-based I need to create a snapshot. Unfortunately I did not realize that zvols require disk space sufficient to duplicate the zvol, and my zpool wasn't big enough. To do what? A snapshot only starts to consume space when data in the filesystem/volume changes. After a false start (zpool add is dangerous when low on sleep) I added a 250GB mirror and a pair of 3GB mirrors to miniraid and was able to successfully snapshot the zvol: miniraid/RichRAID@exportable (I ended up booting off an OI 151a5 USB stick to make that work, since I don't believe snv_134 could handle a 3TB disk). 3) Now it's easy, right? I enabled root login via SSH on the new host, which is running a zpool archive1 consisting of a single RAIDZ2 of 3TB drives using ashift=12, and did a ZFS send: ZFS send miniraid/RichRAID@exportable | ssh root@newhost zfs receive archive1/RichRAID It asked for the root password, I gave it that password, and it was off and running. GigE ain't super fast, but I've got time. The problem: so far the send/recv appears to have copied 6.25TB of 5.34TB. That... doesn't look right. (Comparing zfs list -t snapshot and looking at the 5.34 ref for the snapshot vs zfs list on the new system and looking at space used.) Is this a problem? Should I be panicking yet? No. Do you have compression on on one side but no the other? Either way, let things run to completion. -- Ian. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
