Re: [zfs-discuss] Solaris 10u9 with zpool version 22, but no DEDUP (version 21 reserved)
If not, will any possible problems be avoided if I remove (transfer data away from) any filesystems with dedup=on ? I would think re-copying data from a deduped dataset to a non-deduped dataset will fix it, yes. But then, who knows, perhaps Oracle will fix dedup and make it usable one day... Vennlige hilsener / Best regards roy -- Roy Sigurd Karlsbakk (+47) 97542685 r...@karlsbakk.net http://blogg.karlsbakk.net/ -- I all pedagogikk er det essensielt at pensum presenteres intelligibelt. Det er et elementært imperativ for alle pedagoger å unngå eksessiv anvendelse av idiomer med fremmed opprinnelse. I de fleste tilfeller eksisterer adekvate og relevante synonymer på norsk. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Solaris 10u9 with zpool version 22, but no DEDUP (version 21 reserved)
On Sep 12, 2010, at 3:47 AM, Roy Sigurd Karlsbakk r...@karlsbakk.net wrote: If not, will any possible problems be avoided if I remove (transfer data away from) any filesystems with dedup=on ? I would think re-copying data from a deduped dataset to a non-deduped dataset will fix it, yes. But then, who knows, perhaps Oracle will fix dedup and make it usable one day... Dedup changes large I/Os into small I/Os. If you expect dedup to change large I/Os into no I/Os, then you will be unhappy. Thus, the best solution for dedup is one which can handle large amounts of small I/Os. -- richard ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Failed zfs send invalid backup stream.............
I'm trying to replicate a 300 GB pool with this command zfs send al...@3 | zfs receive -F omega about 2 hours in to the process it fails with this error cannot receive new filesystem stream: invalid backup stream I have tried setting the target read only (zfs set readonly=on omega) also disable Timeslider thinking it might have something to do with it. What could be causing the error ? if the target is a new hard drive can I use this zfs send al...@3 /dev/c10t0d0 ? Thanks -- 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] Failed zfs send invalid backup stream.............
Humberto Ramirez wrote: I'm trying to replicate a 300 GB pool with this command zfs send al...@3 | zfs receive -F omega about 2 hours in to the process it fails with this error cannot receive new filesystem stream: invalid backup stream I have tried setting the target read only (zfs set readonly=on omega) also disable Timeslider thinking it might have something to do with it. What could be causing the error ? Could be zfs filesystem version too old on the sending side (I have one such case). What are their versions, and what release/build of the OS are you using? if the target is a new hard drive can I use this zfs send al...@3 /dev/c10t0d0 ? That command doesn't make much sense for the purpose of doing anything useful. -- Andrew Gabriel ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Failed zfs send invalid backup stream.............
Thanks for the reply Andrew, there both 22 (I checked on that prior to post) Thanks. -- 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] How to migrate to 4KB sector drives?
No replies. Does this mean that you should avoid large drives with 4KB sectors, that is, new drives? ZFS does not handle new drives? -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Hang on zpool import (dedup related)
Another hang on zpool import thread, I'm afraid, because I don't seem to have observed any great successes in the others and I hope there's a way of saving my data ... In March, using OpenSolaris build 134, I created a zpool, some zfs filesystems, enabled dedup on them, moved content into them and promptly discovered how slow it was because I only have 4GB RAM. Even with 30GB L2ARC, the performance was unacceptable. The trouble started when the machine hung one day. Ever since, I've been unable to import my pool without it hanging again. At the time I saw posts from others who had run into similar problems, so I thought it best that I wait until a later build, on the assumption that some ZFS dedup bug would be fixed and I could see my data again. I've been waiting ever since, and only just had a chance to try build 147, thanks to illumos and a schillix live CD. However, the pool still won't import, so I'd much appreciate any troubleshooting hints and tips to help me on my way. schillix b147i My process is: 1. boot the live CD. 2. on the console session, run vmstat 1 3. from another machine, SSH in with multiple sessions and: vmstat 60 vmstat 1 zpool import -f zp zpool iostat zp 1 zpool iostat zp -v 5 4. wait until it all stops What I observe is that the zpool import command never finishes, there will be a lengthy period of read activity made up of very small reads which then stops before an even longer period of what looks like no disk activity. zp 512G 1.31T 0 0 0 0 The box will be responsive for quite some time, seemingly doing not a great deal: kthr memorypagedisk faults cpu r b w swap free re mf pi po fr de sr cd cd rm s0 in sy cs us sy id 0 0 0 2749064 3122988 0 7 0 0 0 0 0 0 1 0 0 365 218 714 0 1 99 Then after a matter of hours it'll hang. SSH sessions are no longer responsive. On the console I can press return which creates a new line, but vmstat will have stopped updating. Interestingly, what I observed in b134 was the same thing, however the free memory would slowly decrease over the course of hours, before a sudden nose-dive right before the lock up. Now it appears to hang without that same effect. While the import appears to be working, I can cd to /zp and look at content of the filesystems of 5 of the 9 esx* directories. Coincidence or not, it's the last four which appear to be empty - esx_prod onward. # zfs list NAME USED AVAIL REFER MOUNTPOINT zp 905G 1.28T23K /zp zp/nfs 889G 1.28T32K /zp/nfs zp/nfs/esx_dev 264G 1.28T 264G /zp/nfs/esx_dev zp/nfs/esx_hedgehog 25.8G 1.28T 25.8G /zp/nfs/esx_hedgehog zp/nfs/esx_meerkat 223G 1.28T 223G /zp/nfs/esx_meerkat zp/nfs/esx_meerkat_dedup 938M 1.28T 938M /zp/nfs/esx_meerkat_dedup zp/nfs/esx_page 8.90G 1.28T 8.90G /zp/nfs/esx_page zp/nfs/esx_prod306G 1.28T 306G /zp/nfs/esx_prod zp/nfs/esx_skunk21K 1.28T21K /zp/nfs/esx_skunk zp/nfs/esx_temp 45.5G 1.28T 45.5G /zp/nfs/esx_temp zp/nfs/esx_template 15.2G 1.28T 15.2G /zp/nfs/esx_template Any help would be appreciated. What could be going wrong here? Is it getting progressively closer to becoming imported each time I try this, or will it be starting from scratch? Feels to me like there's an action in the /zp/nfs/esx_prod filesystem it's trying to replay and never getting to the end of, for some reason. In case it was getting in a muddle with the l2arc, I removed the cache device a matter of minutes into this run. It hasn't hung yet, vmstat is still updating, but I tried a 'zpool import' in one of the windows to see if I could even see a pool on another disk, and that hasn't returned me back to the prompt yet. Also tried to SSH in with another session, and that hasn't produced the login prompt. Thanks in advance, Chris -- 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] How to migrate to 4KB sector drives?
On Sun, Sep 12, 2010 at 10:07 AM, Orvar Korvar knatte_fnatte_tja...@yahoo.com wrote: No replies. Does this mean that you should avoid large drives with 4KB sectors, that is, new drives? ZFS does not handle new drives? Solaris 10u9 handles 4k sectors, so it might be in a post-b134 release of osol. -B -- Brandon High : bh...@freaks.com ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Hang on zpool import (dedup related)
Chris Murray wrote: Another hang on zpool import thread, I'm afraid, because I don't seem to have observed any great successes in the others and I hope there's a way of saving my data ... In March, using OpenSolaris build 134, I created a zpool, some zfs filesystems, enabled dedup on them, moved content into them and promptly discovered how slow it was because I only have 4GB RAM. Even with 30GB L2ARC, the performance was unacceptable. The trouble started when the machine hung one day. Ever since, I've been unable to import my pool without it hanging again. At the time I saw posts from others who had run into similar problems, so I thought it best that I wait until a later build, on the assumption that some ZFS dedup bug would be fixed and I could see my data again. I've been waiting ever since, and only just had a chance to try build 147, thanks to illumos and a schillix live CD. However, the pool still won't import, so I'd much appreciate any troubleshooting hints and tips to help me on my way. schillix b147i My process is: 1. boot the live CD. 2. on the console session, run vmstat 1 3. from another machine, SSH in with multiple sessions and: vmstat 60 vmstat 1 zpool import -f zp zpool iostat zp 1 zpool iostat zp -v 5 4. wait until it all stops What I observe is that the zpool import command never finishes, there will be a lengthy period of read activity made up of very small reads which then stops before an even longer period of what looks like no disk activity. zp 512G 1.31T 0 0 0 0 The box will be responsive for quite some time, seemingly doing not a great deal: kthr memorypagedisk faults cpu r b w swap free re mf pi po fr de sr cd cd rm s0 in sy cs us sy id 0 0 0 2749064 3122988 0 7 0 0 0 0 0 0 1 0 0 365 218 714 0 1 99 Then after a matter of hours it'll hang. SSH sessions are no longer responsive. On the console I can press return which creates a new line, but vmstat will have stopped updating. Interestingly, what I observed in b134 was the same thing, however the free memory would slowly decrease over the course of hours, before a sudden nose-dive right before the lock up. Now it appears to hang without that same effect. While the import appears to be working, I can cd to /zp and look at content of the filesystems of 5 of the 9 esx* directories. Coincidence or not, it's the last four which appear to be empty - esx_prod onward. # zfs list NAME USED AVAIL REFER MOUNTPOINT zp 905G 1.28T23K /zp zp/nfs 889G 1.28T32K /zp/nfs zp/nfs/esx_dev 264G 1.28T 264G /zp/nfs/esx_dev zp/nfs/esx_hedgehog 25.8G 1.28T 25.8G /zp/nfs/esx_hedgehog zp/nfs/esx_meerkat 223G 1.28T 223G /zp/nfs/esx_meerkat zp/nfs/esx_meerkat_dedup 938M 1.28T 938M /zp/nfs/esx_meerkat_dedup zp/nfs/esx_page 8.90G 1.28T 8.90G /zp/nfs/esx_page zp/nfs/esx_prod306G 1.28T 306G /zp/nfs/esx_prod zp/nfs/esx_skunk21K 1.28T21K /zp/nfs/esx_skunk zp/nfs/esx_temp 45.5G 1.28T 45.5G /zp/nfs/esx_temp zp/nfs/esx_template 15.2G 1.28T 15.2G /zp/nfs/esx_template Any help would be appreciated. What could be going wrong here? Is it getting progressively closer to becoming imported each time I try this, or will it be starting from scratch? Feels to me like there's an action in the /zp/nfs/esx_prod filesystem it's trying to replay and never getting to the end of, for some reason. In case it was getting in a muddle with the l2arc, I removed the cache device a matter of minutes into this run. It hasn't hung yet, vmstat is still updating, but I tried a 'zpool import' in one of the windows to see if I could even see a pool on another disk, and that hasn't returned me back to the prompt yet. Also tried to SSH in with another session, and that hasn't produced the login prompt. Thanks in advance, Chris It looks like you may be past the import phase and into the mounting phase. What I would recommend is that you 'zpool import -N zp' so that none of the datasets get mounted and only the import happens. Then one by one you can mount the datasets in order (starting with 'zp') so you can find out which one maybe hanging. - George ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Has anyone seen zpool corruption with VirtualBox shared folders?
I posted the following to the VirtualBox forum. I would be interested in finding out if anyone else has ever seen zpool corruption with VirtualBox as a host on OpenSolaris: - I am running OpenSolaris b134 as a VirtualBox host, with a Linux guest. I have experienced 6-7 instances of my zpool getting corrupted. I am wondering if anyone else has ever seen this before. This is on a mirrored zpool - using drives from two different manufacturers (i.e. it is very unlikely both drives would fail at the same time, with the same blocks going bad). I initially thought I might have a memory problem - which could explain the simultaneous disk failures. After running memory diagnostics for 24 hours with no errors reported, I am beginning to suspect it might be something else. I am using shared folders from the guest - mounted at guest boot up time. Is it possible that the Solaris vboxsf shared folder kernel driver is causing corruption? Being in the kernel, would it allow bypassing of the normal zfs integrity mechanisms? Or is it possible there is some locking issue or race condition that triggers the corruption? Anecdotally, when I see the corruption the sequence of events seems to be: - dmesg reports various vbox drivers being loaded (normal - just loading the drivers) - Guest boots - gets just pass grub boot screen to the initial redhat boot screen. - The Guest hangs and never boots. - zpool status -v reports corrupted files. The files are on the zpool containing the shared folders and the VirtualBox images Thoughts? -- 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] Hang on zpool import (dedup related)
Absolutely spot on George. The import with -N took seconds. Working on the assumption that esx_prod is the one with the problem, I bumped that to the bottom of the list. Each mount was done in a second: # zfs mount zp # zfs mount zp/nfs # zfs mount zp/nfs/esx_dev # zfs mount zp/nfs/esx_hedgehog # zfs mount zp/nfs/esx_meerkat # zfs mount zp/nfs/esx_meerkat_dedup # zfs mount zp/nfs/esx_page # zfs mount zp/nfs/esx_skunk # zfs mount zp/nfs/esx_temp # zfs mount zp/nfs/esx_template And those directories have the content in them that I'd expect. Good! So now I try to mount esx_prod, and the influx of reads has started in zpool iostat zp 1 This is the filesystem with the issue, but what can I do now? Thanks again. -- 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] Has anyone seen zpool corruption with VirtualBox shared folders?
Hi Warren, This may not help much, except perhaps as a way to eliminate possible causes, but I ran b134 with VirtualBox and guests on ZFS for quite a long time without any such symptoms. My pool is a simple, unmirrored one, so the difference may be there. I used shared folders without incident. Guests include Linux (several distros, including RH), Windows, Solaris, BSD. --Jeff On 09/12/10 11:05 AM, Warren Strange wrote: I posted the following to the VirtualBox forum. I would be interested in finding out if anyone else has ever seen zpool corruption with VirtualBox as a host on OpenSolaris: - I am running OpenSolaris b134 as a VirtualBox host, with a Linux guest. I have experienced 6-7 instances of my zpool getting corrupted. I am wondering if anyone else has ever seen this before. This is on a mirrored zpool - using drives from two different manufacturers (i.e. it is very unlikely both drives would fail at the same time, with the same blocks going bad). I initially thought I might have a memory problem - which could explain the simultaneous disk failures. After running memory diagnostics for 24 hours with no errors reported, I am beginning to suspect it might be something else. I am using shared folders from the guest - mounted at guest boot up time. Is it possible that the Solaris vboxsf shared folder kernel driver is causing corruption? Being in the kernel, would it allow bypassing of the normal zfs integrity mechanisms? Or is it possible there is some locking issue or race condition that triggers the corruption? Anecdotally, when I see the corruption the sequence of events seems to be: - dmesg reports various vbox drivers being loaded (normal - just loading the drivers) - Guest boots - gets just pass grub boot screen to the initial redhat boot screen. - The Guest hangs and never boots. - zpool status -v reports corrupted files. The files are on the zpool containing the shared folders and the VirtualBox images Thoughts? -- Jeff Savit | Principal Sales Consultant Phone: 602.824.6275 Email: jeff.sa...@oracle.com | Blog: http://blogs.sun.com/jsavit Oracle North America Commercial Hardware Operating Environments Infrastructure S/W Pillar 2355 E Camelback Rd | Phoenix, AZ 85016 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Failed zfs send invalid backup stream.............
On Sep 12, 2010, at 8:24 AM, Humberto Ramirez wrote: I'm trying to replicate a 300 GB pool with this command zfs send al...@3 | zfs receive -F omega about 2 hours in to the process it fails with this error cannot receive new filesystem stream: invalid backup stream I have tried setting the target read only (zfs set readonly=on omega) also disable Timeslider thinking it might have something to do with it. What could be causing the error ? if the target is a new hard drive can I use this zfs send al...@3 /dev/c10t0d0 ? Network problems will cause this. Try sending through ssh to take advantage of extra data stream protection. -- richard -- OpenStorage Summit, October 25-27, Palo Alto, CA http://nexenta-summit2010.eventbrite.com Richard Elling rich...@nexenta.com +1-760-896-4422 Enterprise class storage for everyone www.nexenta.com ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Has anyone seen zpool corruption with VirtualBox shared folders?
On Sep 12, 2010, at 11:05 AM, Warren Strange wrote: I posted the following to the VirtualBox forum. I would be interested in finding out if anyone else has ever seen zpool corruption with VirtualBox as a host on OpenSolaris: - I am running OpenSolaris b134 as a VirtualBox host, with a Linux guest. I have experienced 6-7 instances of my zpool getting corrupted. I am wondering if anyone else has ever seen this before. This is on a mirrored zpool - using drives from two different manufacturers (i.e. it is very unlikely both drives would fail at the same time, with the same blocks going bad). I initially thought I might have a memory problem - which could explain the simultaneous disk failures. After running memory diagnostics for 24 hours with no errors reported, I am beginning to suspect it might be something else. So we are clear, you are running VirtualBox on ZFS, rather than ZFS on VirtualBox? I am using shared folders from the guest - mounted at guest boot up time. Is it possible that the Solaris vboxsf shared folder kernel driver is causing corruption? Being in the kernel, would it allow bypassing of the normal zfs integrity mechanisms? Or is it possible there is some locking issue or race condition that triggers the corruption? Anecdotally, when I see the corruption the sequence of events seems to be: - dmesg reports various vbox drivers being loaded (normal - just loading the drivers) - Guest boots - gets just pass grub boot screen to the initial redhat boot screen. - The Guest hangs and never boots. - zpool status -v reports corrupted files. The files are on the zpool containing the shared folders and the VirtualBox images Thoughts? Bad power supply, HBA, cables, or other common cause. To help you determine the sort of corruption, for mirrored pools FMA will record the nature of the discrepancies. fmdump -eV will show a checksum error and the associated bitmap comparisons. -- richard -- OpenStorage Summit, October 25-27, Palo Alto, CA http://nexenta-summit2010.eventbrite.com ZFS and performance consulting http://www.RichardElling.com ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Has anyone seen zpool corruption with VirtualBox shared folders?
So we are clear, you are running VirtualBox on ZFS, rather than ZFS on VirtualBox? Correct Bad power supply, HBA, cables, or other common cause. To help you determine the sort of corruption, for mirrored pools FMA will record the nature of the discrepancies. fmdump -eV will show a checksum error and the associated bitmap comparisons. Below are the errors reported from the two disks. Not sure if anything looks suspicious (other than the obvious checksum error) Sep 10 2010 12:49:42.315641690 ereport.fs.zfs.checksum nvlist version: 0 class = ereport.fs.zfs.checksum ena = 0x95816e82e2900401 detector = (embedded nvlist) nvlist version: 0 version = 0x0 scheme = zfs pool = 0xf3cb5e110f2c88ec vdev = 0x961d9b28c1440020 (end detector) pool = tank pool_guid = 0xf3cb5e110f2c88ec pool_context = 0 pool_failmode = wait vdev_guid = 0x961d9b28c1440020 vdev_type = disk vdev_path = /dev/dsk/c8t5d0s0 vdev_devid = id1,s...@sata_wdc_wd15eads-00p_wd-wcavu0351361/a parent_guid = 0xdae51838a62627b9 parent_type = mirror zio_err = 50 zio_offset = 0x1ef6813a00 zio_size = 0x2 zio_objset = 0x10 zio_object = 0x1402f zio_level = 0 zio_blkid = 0x76f cksum_expected = 0x405288851d24 0x100655c808fa2072 0xa89d11a403482052 0xf1041fd6f838c6eb cksum_actual = 0x40528884fd24 0x100655c803286072 0xa89d111c8af30052 0xf0fbe93b4f02c6eb cksum_algorithm = fletcher4 __ttl = 0x1 __tod = 0x4c8a7dc6 0x12d04f5a Sep 10 2010 12:49:42.315641636 ereport.fs.zfs.checksum nvlist version: 0 class = ereport.fs.zfs.checksum ena = 0x95816e82e2900401 detector = (embedded nvlist) nvlist version: 0 version = 0x0 scheme = zfs pool = 0xf3cb5e110f2c88ec vdev = 0x969570b704d5bff1 (end detector) pool = tank pool_guid = 0xf3cb5e110f2c88ec pool_context = 0 pool_failmode = wait vdev_guid = 0x969570b704d5bff1 vdev_type = disk vdev_path = /dev/dsk/c8t4d0s0 vdev_devid = id1,s...@sata_st31500341as9vs3b4cp/a parent_guid = 0xdae51838a62627b9 parent_type = mirror zio_err = 50 zio_offset = 0x1ef6813a00 zio_size = 0x2 zio_objset = 0x10 zio_object = 0x1402f zio_level = 0 zio_blkid = 0x76f cksum_expected = 0x405288851d24 0x100655c808fa2072 0xa89d11a403482052 0xf1041fd6f838c6eb cksum_actual = 0x40528884fd24 0x100655c803286072 0xa89d111c8af30052 0xf0fbe93b4f02c6eb cksum_algorithm = fletcher4 __ttl = 0x1 __tod = 0x4c8a7dc6 0x12d04f24 Message was edited by: wstrange -- 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] Has anyone seen zpool corruption with VirtualBox shared folders?
Comments below... On Sep 12, 2010, at 2:56 PM, Warren Strange wrote: So we are clear, you are running VirtualBox on ZFS, rather than ZFS on VirtualBox? Correct Bad power supply, HBA, cables, or other common cause. To help you determine the sort of corruption, for mirrored pools FMA will record the nature of the discrepancies. fmdump -eV will show a checksum error and the associated bitmap comparisons. Below are the errors reported from the two disks. Not sure if anything looks suspicious (other than the obvious checksum error) Sep 10 2010 12:49:42.315641690 ereport.fs.zfs.checksum nvlist version: 0 class = ereport.fs.zfs.checksum ena = 0x95816e82e2900401 detector = (embedded nvlist) nvlist version: 0 version = 0x0 scheme = zfs pool = 0xf3cb5e110f2c88ec vdev = 0x961d9b28c1440020 (end detector) pool = tank pool_guid = 0xf3cb5e110f2c88ec pool_context = 0 pool_failmode = wait vdev_guid = 0x961d9b28c1440020 vdev_type = disk vdev_path = /dev/dsk/c8t5d0s0 vdev_devid = id1,s...@sata_wdc_wd15eads-00p_wd-wcavu0351361/a parent_guid = 0xdae51838a62627b9 parent_type = mirror zio_err = 50 zio_offset = 0x1ef6813a00 zio_size = 0x2 zio_objset = 0x10 zio_object = 0x1402f zio_level = 0 zio_blkid = 0x76f cksum_expected = 0x405288851d24 0x100655c808fa2072 0xa89d11a403482052 0xf1041fd6f838c6eb cksum_actual = 0x40528884fd24 0x100655c803286072 0xa89d111c8af30052 0xf0fbe93b4f02c6eb cksum_algorithm = fletcher4 __ttl = 0x1 __tod = 0x4c8a7dc6 0x12d04f5a Sep 10 2010 12:49:42.315641636 ereport.fs.zfs.checksum nvlist version: 0 class = ereport.fs.zfs.checksum ena = 0x95816e82e2900401 detector = (embedded nvlist) nvlist version: 0 version = 0x0 scheme = zfs pool = 0xf3cb5e110f2c88ec vdev = 0x969570b704d5bff1 (end detector) pool = tank pool_guid = 0xf3cb5e110f2c88ec pool_context = 0 pool_failmode = wait vdev_guid = 0x969570b704d5bff1 vdev_type = disk vdev_path = /dev/dsk/c8t4d0s0 vdev_devid = id1,s...@sata_st31500341as9vs3b4cp/a parent_guid = 0xdae51838a62627b9 parent_type = mirror zio_err = 50 zio_offset = 0x1ef6813a00 zio_size = 0x2 zio_objset = 0x10 zio_object = 0x1402f zio_level = 0 zio_blkid = 0x76f cksum_expected = 0x405288851d24 0x100655c808fa2072 0xa89d11a403482052 0xf1041fd6f838c6eb cksum_actual = 0x40528884fd24 0x100655c803286072 0xa89d111c8af30052 0xf0fbe93b4f02c6eb cksum_algorithm = fletcher4 __ttl = 0x1 __tod = 0x4c8a7dc6 0x12d04f24 In the case where one side of the mirror is corrupted and the other is correct, then you will be shown the difference between the two, in the form of an abbreviated bitmap. In this case, the data on each side of the mirror is the same, with a large degree of confidence. So the source of the corruption is likely to be the same -- some common component: CPU, RAM, HBA, I/O path, etc. You can rule out the disks as suspects. With some additional experiments you can determine if the corruption occurred during the write or the read. -- richard -- OpenStorage Summit, October 25-27, Palo Alto, CA http://nexenta-summit2010.eventbrite.com Richard Elling rich...@nexenta.com +1-760-896-4422 Enterprise class storage for everyone www.nexenta.com ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] How to migrate to 4KB sector drives?
On Sep 12, 2010, at 10:11 AM, Brandon High wrote: On Sun, Sep 12, 2010 at 10:07 AM, Orvar Korvar knatte_fnatte_tja...@yahoo.com wrote: No replies. Does this mean that you should avoid large drives with 4KB sectors, that is, new drives? ZFS does not handle new drives? Solaris 10u9 handles 4k sectors, so it might be in a post-b134 release of osol. OSol source yes, binaries no :-( You will need another distro besides OpenSolaris. The needed support in sd was added around the b137 timeframe. -- richard -- OpenStorage Summit, October 25-27, Palo Alto, CA http://nexenta-summit2010.eventbrite.com Richard Elling rich...@nexenta.com +1-760-896-4422 Enterprise class storage for everyone www.nexenta.com ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] How to migrate to 4KB sector drives?
On Sun, Sep 12, 2010 at 5:42 PM, Richard Elling rich...@nexenta.com wrote: On Sep 12, 2010, at 10:11 AM, Brandon High wrote: On Sun, Sep 12, 2010 at 10:07 AM, Orvar Korvar knatte_fnatte_tja...@yahoo.com wrote: No replies. Does this mean that you should avoid large drives with 4KB sectors, that is, new drives? ZFS does not handle new drives? Solaris 10u9 handles 4k sectors, so it might be in a post-b134 release of osol. OSol source yes, binaries no :-( You will need another distro besides OpenSolaris. The needed support in sd was added around the b137 timeframe. OpenIndiana, to be released on Tuesday, is based on b146 or later. -- Mike Gerdts http://mgerdts.blogspot.com/ ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] How to migrate to 4KB sector drives?
On Sun, Sep 12, 2010 at 3:42 PM, Richard Elling rich...@nexenta.com wrote: OSol source yes, binaries no :-( You will need another distro besides OpenSolaris. The needed support in sd was added around the b137 timeframe. Do you know if it's been backported to Nexenta Core? There doesn't seem to be a list of backported changes available on nexenta.org. -B -- Brandon High : bh...@freaks.com ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] OCZ Vertex 2 Pro performance numbers
(I am aware I am replying to an old post...) Arne Jansen sensille at gmx.net writes: Now the test for the Vertex 2 Pro. This was fun. For more explanation please see the thread Crucial RealSSD C300 and cache flush? This time I made sure the device is attached via 3GBit SATA. This is also only a short test. I'll retest after some weeks of usage. cache enabled, 32 buffers, 64k blocks linear write, random data: 96 MB/s linear read, random data: 206 MB/s linear write, zero data: 234 MB/s linear read, zero data: 255 MB/s This discrepancy between tests with random data and zero data is puzzling to me. Does this suggest that the SSD does transparent compression between its Sandforce SF-1500 controller and the NAND flash chips? cache enabled, 32 buffers, 4k blocks random write, random data: 41 MB/s (10300 ops/s) random read, random data: 76 MB/s (19000 ops/s) random write, zero data: 54 MB/s (13800 ops/s) random read, zero data: 91 MB/s (22800 ops/s) These IOPS numbers are significantly below the 5 IOPS announced by OCZ. But I supposed this is due to your benchmark tool not aligning the ops to 4K boundaries, correct? -mrb ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] file recovery on lost RAIDZ array
I recently lost all of the data on my single parity raid z array. Each of the drives was encrypted with the zfs array built within the encrypted volumes. I am not exactly sure what happened. The files were there and accessible and then they were all gone. The server apparently crashed and rebooted and everything was lost. After the crash I remounted the encrypted drives and the zpool was still reporting that roughly 3TB of the 7TB array were used, but I could not see any of the files through the array's mount point. I unmounted the zpool and then remounted it and suddenly zpool was reporting 0TB were used. I did not remap the virtual device. The only thing of note that I saw was that the name of storage pool had changed. Originally it was Movies and then it became Movita. I am guessing that the file system became corrupted some how. (zpool status did not report any errors) So, my questions are these... Is there anyway to undelete data from a lost raidz array? If I build a new virtual device on top of the old one and the drive topology remains the same, can we scan the drives for files from old arrays? Also, is there any way to repair a corrupted storage pool? Is it possible to backup the file table or whatever partition index zfs maintains? I imagine that you all are going to suggest that I scrub the array, but that is not an option at this point. I had a backup of all of the data lost as I am moving between file servers so at a certain point I gave up and decided to start fresh. This doesn't give me a warm fuzzy feeling about zfs, though. Thanks, -Mike -- 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] resilver = defrag?
From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- boun...@opensolaris.org] On Behalf Of Orvar Korvar I am not really worried about fragmentation. I was just wondering if I attach new drives and zfs send recieve to a new zpool, would count as defrag. But apparently, not. Apparently not in all situations would be more appropriate. The understanding I had was: If you send a single zfs send | receive, then it does effectively get defragmented, because the receiving filesystem is going to re-layout the received filesystem, and there is nothing pre-existing to make the receiving filesystem dance around... But if you're sending some initial, plus incrementals, then you're actually repeating the same operations that probably caused the original filesystem to become fragmented in the first place. And in fact, it seems unavoidable... Suppose you have a large file, which is all sequential on disk. You make a snapshot of it. Which means all the individual blocks must not be overwritten. And then you overwrite a few bytes scattered randomly in the middle of the file. The nature of copy on write is such that of course, the latest version of the filesystem is impossible to remain contiguous. Your only choices are: To read write copies of the whole file, including multiple copies of what didn't change, or you leave the existing data in place where it is on disk, and you instead write your new random bytes to other non-contiguous locations on disk. Hence fragmentation. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] resilver = defrag?
On Sep 12, 2010, at 8:27 PM, Edward Ned Harvey wrote: From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- boun...@opensolaris.org] On Behalf Of Orvar Korvar I am not really worried about fragmentation. I was just wondering if I attach new drives and zfs send recieve to a new zpool, would count as defrag. But apparently, not. Apparently not in all situations would be more appropriate. The understanding I had was: If you send a single zfs send | receive, then it does effectively get defragmented, because the receiving filesystem is going to re-layout the received filesystem, and there is nothing pre-existing to make the receiving filesystem dance around... But if you're sending some initial, plus incrementals, then you're actually repeating the same operations that probably caused the original filesystem to become fragmented in the first place. And in fact, it seems unavoidable... Suppose you have a large file, which is all sequential on disk. You make a snapshot of it. Which means all the individual blocks must not be overwritten. And then you overwrite a few bytes scattered randomly in the middle of the file. The nature of copy on write is such that of course, the latest version of the filesystem is impossible to remain contiguous. Your only choices are: To read write copies of the whole file, including multiple copies of what didn't change, or you leave the existing data in place where it is on disk, and you instead write your new random bytes to other non-contiguous locations on disk. Hence fragmentation. This operational definition of fragmentation comes from the single-user, single-tasking world (PeeCees). In that world, only one thread writes files from one application at one time. In those cases, there is a reasonable expectation that a single file's blocks might be contiguous on a single disk. That isn't the world we live in, where have RAID, multi-user, or multi-threaded environments. -- richard -- OpenStorage Summit, October 25-27, Palo Alto, CA http://nexenta-summit2010.eventbrite.com Richard Elling rich...@nexenta.com +1-760-896-4422 Enterprise class storage for everyone www.nexenta.com ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] How to migrate to 4KB sector drives?
Orvar Korvar wrote: ZFS does not handle 4K sector drives well, you need to create a new zpool with 4K property (ashift) set. http://www.solarismen.de/archives/5-Solaris-and-the-new-4K-Sector-Disks-e.g.-WDxxEARS-Part-2.html Are there plans to allow resilver to handle 4K sector drives? Not sure about resilvering to 4K but as manual for Solaris under link you provided is describing, it can make new zpools aligned to 4K. Untill OpenIndiana.org come to life, maybe in meantime you can try to build Illumos OS/Net testing part, have it in separate BE on top of 134b Opensolaris from genunix.org and try to _for testing_ 4K sector drives rpool instructions you found, on it. http://www.illumos.org/projects/illumos-gate/wiki/How_To_Build_illumos ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] OCZ Vertex 2 Pro performance numbers
Marc Bevand m.bevand at gmail.com writes: This discrepancy between tests with random data and zero data is puzzling to me. Does this suggest that the SSD does transparent compression between its Sandforce SF-1500 controller and the NAND flash chips? Replying to myself: yes, SF-1500 does transparent deduplication and compression to reduce write-amplification. Wow. http://www.semiaccurate.com/2010/05/03/sandforce-ssds-break-tpc-c-records/ -mrb ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
