Re: [zfs-discuss] Performance drop during scrub?
Hi Bob, It is necessary to look at all the factors which might result in data loss before deciding what the most effective steps are to minimize the probability of loss. Bob I am under the impression that exactly those were the considerations for both the ZFS designers to implement a scrub function to ZFS and the author of Best Practises to recommend performing this function frequently. I am hearing you are coming to a different conclusion and I would be interested in learning what could possibly be so highly interpretable in this. Regards, Tonmaus -- 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] Reverse lookup: inode to name lookup
You can do in the kernel by calling vnodetopath(). I don't know if it is exposed to user space. Yes, in /proc/*/path (kinda). But that could be slow if you have large directories so you have to think about where you would use it. The kernel caches file names; however, it cannot be use for files that aren't in use. It is certainly possible to create a .zfs/snapshot_byinode but it is not clear when it helps but it can be used for finding the earlier copy of a directory (netapp/.snapshot) Casper ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zpool mirror (dumb question)
On May 2, 2010, at 8:47 AM, Steve Staples wrote: Hi there! I am new to the list, and to OpenSolaris, as well as ZPS. I am creating a zpool/zfs to use on my NAS server, and basically I want some redundancy for my files/media. What I am looking to do, is get a bunch of 2TB drives, and mount them mirrored, and in a zpool so that I don't have to worry about running out of room. (I know, pretty typical I guess). My problem is, is that not all 2TB hard drives are the same size (even though they should be 2 trillion bytes, there is still sometimes a +/- (I've only noticed this 2x so far) ) and if I create them mirrored, and one fails, and then I replace the drive, and for some reason, it is 1byte smaller, it will not work. How would I go about fixing this problem? This problem is already fixed for you in ZFS. For disk sizes in 2TB it may tolerate difference in size up to approximately a little bit less than half a metaslab size which is currently likely to be 16GB, thus it may tolerate difference in size of up to, say, 7.5GB. I think that in most cases difference in sizes is below that figure. You can see it for yourself: bash-4.0# mkfile -n 2 d0 bash-4.0# zpool create pool `pwd`/d0 bash-4.0# mkfile -n 1992869543936 d1 bash-4.0# zpool attach pool `pwd`/d0 `pwd`/d1 bash-4.0# zpool status pool pool: pool state: ONLINE scrub: resilver completed after 0h0m with 0 errors on Sun May 2 15:25:24 2010 config: NAME STATE READ WRITE CKSUM pool ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 /var/tmp/d0 ONLINE 0 0 0 /var/tmp/d1 ONLINE 0 0 0 83.5K resilvered errors: No known data errors bash-4.0# zpool detach pool `pwd`/d1 So you can see that even though difference in size between d0 and d1 is 7130456064 (~6.6GB), it can still be attached just fine. Let's now detach d1 and make it 1 byte smaller: bash-4.0# mkfile -n 1992869543935 d1 bash-4.0# zpool attach pool `pwd`/d0 `pwd`/d1 cannot attach /var/tmp/d1 to /var/tmp/d0: device is too small bash-4.0# This time is is no longer possible to attach it, because size is not enough to fit the same number (116) of 16G metaslabs; THIS is just a thought, I am looking for thoughts and opinions on doing this... it prolly would be a bad idea, but hey, does it hurt to ask? I have been thinking, and would it be a good idea, to have on the 2TB drives, say 1TB or 500GB files and then mount them as mirrored? So basically, have a 2TB hard drive, set up like: (where drive1 and drive2 are the paths to the mount points) Mkfile 465gb /drive1/drive1part1 Mkfile 465gb /drive1/drive1part2 Mkfile 465gb /drive1/drive1part3 Mkfile 465gb /drive1/drive1part4 Mkfile 465gb /drive2/drive2part1 Mkfile 465gb /drive2/drive2part2 Mkfile 465gb /drive2/drive2part3 Mkfile 465gb /drive2/drive2part4 (I use 465gb, as 2TB = 2trillion bytes, / 4 = 465.66 gb) And then add them to the zpool Zpool add medianas mirror /drive1/drive1part1 /drive2/drive2/part1 Zpool add medianas mirror /drive1/drive1part2 /drive2/drive2/part2 Zpool add medianas mirror /drive1/drive1part3 /drive2/drive2/part3 Zpool add medianas mirror /drive1/drive1part4 /drive2/drive2/part4 This is not a good idea regards victor And then, if a drive goes and I only have a 500gb and a 1.5tb drives, they could be replaced that way? I am sure there are performance issues in doing this, but would the performance outweigh the possibility of hard drive failure and replacing drives? Sorry for posting a novel, but I am just concerned about failure on bigger drives, and putting my media/files into basically what consists of a JBOD type array (on steroids). Steve ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] rpool gone after zpool detach
I am using a mirrored system pool on 2 80G drives - however I was only using 40G since I thought I might use the rest for something else. ZFS Time Slider was complaining the pool was filled for 90% and I decided to increase pool size. What I did was a zpool detach of one of the mirrored hdds and increased the partition size to 100% with fdisk. When I wanted to reattach the hdd, system complained about an IO error and it hang. Now the rpool is gone on both drives (I also tried to find it via zpool import booting from USB - without success). Is there any chance I can recover the lost rpool? And what did I do wrong (except for not having a backup first)? ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] rpool gone after zpool detach
- Jan Riechers jan.riech...@googlemail.com skrev: I am using a mirrored system pool on 2 80G drives - however I was only using 40G since I thought I might use the rest for something else. ZFS Time Slider was complaining the pool was filled for 90% and I decided to increase pool size. What I did was a zpool detach of one of the mirrored hdds and increased the partition size to 100% with fdisk. When I wanted to reattach the hdd, system complained about an IO error and it hang. Now the rpool is gone on both drives (I also tried to find it via zpool import booting from USB - without success). Is there any chance I can recover the lost rpool? And what did I do wrong (except for not having a backup first)? ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss What error messages do you get? Please give more info roy ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] First Setup
Hi! We're building our first dedicated ZFS-based NAS/SAN (probably using Nexenta) and I'd like to run the specs by you all to see if you have any recommendations. All of it is already bought, but it's not too late to add to it. Dell PowerEdge R9102x Intel X7550 2GHz, 8 cores each plus HyperThreading256GB RAM2x 4GB DDRDrive X1 (PCIe) in mirror for the ZIL8x 100GB Samsung SS805 SSDs for the L2ARC (on an onboard PERC H700 controller)2x PERC H800 and 2x PERC6 controllers for the JBODs below11x Dell MD1000 JBODs with: 45x 750GB SATA HDDs 30x 1000GB SATA HDDs 60X 300GB SAS 15K HDDs 30x 600GB SAS 15K HDDs2x 10GbE ports We plan to connect about 30 servers to it. About 8 will be currently I/O-bound MySQL databases with a 60/40 read bias, the rest will have much lighter usage. Most connections will be through iSCSI. Is there anything that seems out of proportion? Where do you think the bottleneck will be? If I'm going to use the SAS 15K drives for databases and the SATA drives for NFS/backups, how should I setup the pools? Thank you for any advice! ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] zpool rename?
One can rename a zpool on import zpool import -f pool_or_id newname Is there any way to rename it (back again, perhaps) on export? (I had to rename rpool in an old disk image to access some stuff in it, and I'd like to put it back the way it was so it's properly usable if I ever want to boot off of it.) But I suppose there must be other scenarios where that would be useful too... -- 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] zpool rename?
- Richard L. Hamilton rlha...@smart.net skrev: One can rename a zpool on import zpool import -f pool_or_id newname Is there any way to rename it (back again, perhaps) on export? (I had to rename rpool in an old disk image to access some stuff in it, and I'd like to put it back the way it was so it's properly usable if I ever want to boot off of it.) But I suppose there must be other scenarios where that would be useful too... just export it and reimportit with the old name roy ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Reverse lookup: inode to name lookup
From: cas...@holland.sun.com [mailto:cas...@holland.sun.com] On Behalf Of casper@sun.com It is certainly possible to create a .zfs/snapshot_byinode but it is not clear when it helps but it can be used for finding the earlier copy of a directory (netapp/.snapshot) Do you happen to have any idea how easy/difficult it would be, to create something like .zfs/snapshot_by_inode? And although I hypothetically described the behavior of such a thing once before, I don't recall seeing any response to that. So I don't know if there's any agreement on the proposed behavior. That suggestion, again, was: Inside the .zfs directory, there is presently only one subdirectory, snapshot. Let there be more: .zfs/snapshot .zfs/name_from_inode .zfs/inode_from_name Inside the .zfs/snapshot directory, there's a list of snapshots. The same is true for the name_from_inode, and inode_from_name directories too. However, inside the .zfs/snapshot/snapname directory, there is an actual snapshot of all the files and directories of the filesystem. The other two directories behave as follows: -- #1 -- .zfs/name_from_inode: The .zfs/name_from_inode directory provides a mechanism to perform reverse inode--name lookup. If a user does ls .zfs/name_from_inode/snapname then they will see nothing. (The system will not generate a complete list of all the inodes in the filesystem; that would be crazy). But if they explicitly cat .zfs/name_from_inode/snapname/12345 then the system does an inode--name reverse lookup, and if the result is accessible with the user's permission level, then the result is just a text output of the pathname of the object. (Presumably a directory, because there is currently no facility to reverse lookup a file. Directories do have a reference to their parent, via '..' entries, but files have no such thing.) Thus, if a user wants to find all the old snapshots of a directory in the present filesystem, even if the name or location of that directory may have changed, they could do this: ls -di /tank/path/to/some/dirname (result inode number 12345) cat /tank/.zfs/name_from_inode/snapname/12345 (result path/to/previous/old-dirname ls /tank/.zfs/snapshot/snapname/path/to/previous/old-dirname And I am slowly working on scripts now, to simplify all the above into a single command: zhist ls /tank/path/to/some/dirname would display all the former snapnames for that object. It is possible for the OS, in between two snapshots, to recycle an inode number. So it is possible to mistakenly identify some completely unrelated object as a former snapshot of a present object. As far as I know, this is unavoidable, but also unlikely. -- #2 -- .zfs/inode_from_name: The .zfs/inode_from_name directory provides a mechanism to find the inode number of an object, when ls -di is not possible, because CIFS doesn't support inodes. So a CIFS client would do this: cat /tank/.zfs/inode_from_name/path/to/some/dirname (result inode number 12345) The rest of the process would be the same as above. cat /tank/.zfs/name_from_inode/snapname/12345 (result path/to/previous/old-dirname ls /tank/.zfs/snapshot/snapname/path/to/previous/old-dirname ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zpool mirror (dumb question)
From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- boun...@opensolaris.org] On Behalf Of Steve Staples My problem is, is that not all 2TB hard drives are the same size (even though they should be 2 trillion bytes, there is still sometimes a +/- (I've only noticed this 2x so far) ) and if I create them mirrored, and one fails, and then I replace the drive, and for some reason, it is 1byte smaller, it will not work. If you use the latest developer release from genunix.org, it's already fixed. This is what I recommend, in general. http://genunix.org/dist/indiana/ It looks like the latest one is osol-dev-134 If you use the latest opensolaris release (2009.06) I'm not sure if it's already fixed. If you use Solaris 10, even fully updated, you are wise to ask this question. Because the fix is not present. If you don't already have the fix, the recommendation would be to partition the disks first. Throw away something like 1% of the disk intentionally. Yes this is extra work and a little wasteful, but it's preventive work for a real problem. http://docs.sun.com/app/docs/doc/806-4073/6jd67r9hu (Quoting Richard Elling) CR 6844090, zfs should be able to mirror to a smaller disk http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6844090 b117, June 2009 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zpool mirror (dumb question)
On May 2, 2010, at 8:47 AM, Steve Staples wrote: Hi there! I am new to the list, and to OpenSolaris, as well as ZPS. I am creating a zpool/zfs to use on my NAS server, and basically I want some redundancy for my files/media. What I am looking to do, is get a bunch of 2TB drives, and mount them mirrored, and in a zpool so that I don't have to worry about running out of room. (I know, pretty typical I guess). My problem is, is that not all 2TB hard drives are the same size (even though they should be 2 trillion bytes, there is still sometimes a +/- (I've only noticed this 2x so far) ) and if I create them mirrored, and one fails, and then I replace the drive, and for some reason, it is 1byte smaller, it will not work. How would I go about fixing this problem? This problem is already fixed for you in ZFS. For disk sizes in 2TB it may tolerate difference in size up to approximately a little bit less than half a metaslab size which is currently likely to be 16GB, thus it may tolerate difference in size of up to, say, 7.5GB. I think that in most cases difference in sizes is below that figure. You can see it for yourself: bash-4.0# mkfile -n 2 d0 bash-4.0# zpool create pool `pwd`/d0 bash-4.0# mkfile -n 1992869543936 d1 bash-4.0# zpool attach pool `pwd`/d0 `pwd`/d1 bash-4.0# zpool status pool pool: pool state: ONLINE scrub: resilver completed after 0h0m with 0 errors on Sun May 2 15:25:24 2010 config: NAME STATE READ WRITE CKSUM pool ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 /var/tmp/d0 ONLINE 0 0 0 /var/tmp/d1 ONLINE 0 0 0 83.5K resilvered errors: No known data errors bash-4.0# zpool detach pool `pwd`/d1 So you can see that even though difference in size between d0 and d1 is 7130456064 (~6.6GB), it can still be attached just fine. Let's now detach d1 and make it 1 byte smaller: I've done this in testing already, and mirrored a 10gb drive, with an 80gb drive, and yes, the mirror assumes the 10gb size. But, if I remove the 10gb drive, and replace it with another 80gb, if the other 80gb drive is smaller by even 1 byte, you cannot attach it. bash-4.0# mkfile -n 1992869543935 d1 bash-4.0# zpool attach pool `pwd`/d0 `pwd`/d1 cannot attach /var/tmp/d1 to /var/tmp/d0: device is too small bash-4.0# This time is is no longer possible to attach it, because size is not enough to fit the same number (116) of 16G metaslabs; And yes, I've gotten the exact same results when using file based disks (mkfile -n 1992869543935 d1) of 1byte less. Replacing with a bigger drive, is no problem, replacing with the same drive, that is 1byte smaller... cannot do. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zpool mirror (dumb question)
From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- boun...@opensolaris.org] On Behalf Of Steve Staples My problem is, is that not all 2TB hard drives are the same size (even though they should be 2 trillion bytes, there is still sometimes a +/- (I've only noticed this 2x so far) ) and if I create them mirrored, and one fails, and then I replace the drive, and for some reason, it is 1byte smaller, it will not work. If you use the latest developer release from genunix.org, it's already fixed. This is what I recommend, in general. http://genunix.org/dist/indiana/ It looks like the latest one is osol-dev-134 If you use the latest opensolaris release (2009.06) I'm not sure if it's already fixed. I am currently using OpenSolaris 2009.06 If I was to upgrade to the current developer version, forgive my ignorance (since I am new to *solaris), but how would I do this? Also, are there docs for this yet on what has changed? I am looking in the directory there, and I don't see any notes. Any gentle nudge in the right direction would be appreciated :) If you use Solaris 10, even fully updated, you are wise to ask this question. Because the fix is not present. If you don't already have the fix, the recommendation would be to partition the disks first. Throw away something like 1% of the disk intentionally. Yes this is extra work and a little wasteful, but it's preventive work for a real problem. http://docs.sun.com/app/docs/doc/806-4073/6jd67r9hu If I was to take this route, I was under the impression that ZFS takes the drive as a whole, regardless of partitions, and wipes the data? Apparently I am wrong? I don't have any problems with losing a few gig if needed, to save future problems. If I have to partition a drive of 2tb to 1.8tb (2 trillion bytes = 1.862g), then oh well. (Quoting Richard Elling) CR 6844090, zfs should be able to mirror to a smaller disk http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6844090 b117, June 2009 Steve ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] zfs testing / problems
Hi all Testing variable size 'disks' in mirror, I followed Victor Latushkin's example bash-4.0# mkfile -n 2 d0 bash-4.0# zpool create pool $PWD/d0 bash-4.0# mkfile -n 1992869543936 d1 bash-4.0# zpool attach pool $PWD/d0 $PWD/d1 and so on - this works well. Now, to try to mess with ZFS a litt (or a lot), I tried corrupting parts of both sides of the mirror to see what ZFS would do about it r...@mime:/testpool/testdisks# dd if=/dev/urandom of=d1 bs=100k count=1 skip=30 1+0 records in 1+0 records out 102400 bytes (102 kB) copied, 0.00208301 s, 49.2 MB/s r...@mime:/testpool/testdisks# dd if=/dev/urandom of=d0 bs=100k count=1 skip=50 1+0 records in 1+0 records out 102400 bytes (102 kB) copied, 0.00205321 s, 49.9 MB/s This resulted in a panic - see below for the info from the kernel log. I'd forgotten to turn on dumps after last reinstall, but it should be easy to reproduce it. I think I read somewhere that it was normal for zfs/zpool to panic if it lost contact with a pool - is this what happened here? if so, is it possible to change this behaviour? If osol looses contact with a pool, I'd rather try to debug it and reboot myself if I want to, rather than having the system automatically panic. May 2 17:42:09 mime unix: [ID 836849 kern.notice] May 2 17:42:09 mime ^Mpanic[cpu1]/thread=ff00044d0c60: May 2 17:42:09 mime genunix: [ID 603766 kern.notice] assertion failed: 0 == zap_increment_int(os, (-1ULL), user, delta, tx) (0x0 == 0x32), file: ../. ./common/fs/zfs/dmu_objset.c, line: 1086 May 2 17:42:09 mime unix: [ID 10 kern.notice] May 2 17:42:09 mime genunix: [ID 655072 kern.notice] ff00044d09c0 genunix:assfail3+c1 () May 2 17:42:09 mime genunix: [ID 655072 kern.notice] ff00044d0a20 zfs:do_userquota_callback+11f () May 2 17:42:09 mime genunix: [ID 655072 kern.notice] ff00044d0a70 zfs:dmu_objset_do_userquota_callbacks+a9 () May 2 17:42:09 mime genunix: [ID 655072 kern.notice] ff00044d0ae0 zfs:dsl_pool_sync+f0 () May 2 17:42:09 mime genunix: [ID 655072 kern.notice] ff00044d0ba0 zfs:spa_sync+3a9 () May 2 17:42:09 mime genunix: [ID 655072 kern.notice] ff00044d0c40 zfs:txg_sync_thread+24a () May 2 17:42:09 mime genunix: [ID 655072 kern.notice] ff00044d0c50 unix:thread_start+8 () 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] zpool mirror (dumb question)
I am currently using OpenSolaris 2009.06 If I was to upgrade to the current developer version, forgive my ignorance (since I am new to *solaris), but how would I do this? # pkg set-publisher -O http://pkg.opensolaris.org/dev opensolaris.org # pkg image-update That'll take you to snv_134 or whatever the latest is roy ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] First Setup
- Ian D rewar...@hotmail.com skrev: Hi! We're building our first dedicated ZFS-based NAS/SAN (probably using Nexenta) and I'd like to run the specs by you all to see if you have any recommendations. All of it is already bought, but it's not too late to add to it. Dell PowerEdge R910 2x Intel X7550 2GHz, 8 cores each plus HyperThreading 256GB RAM 2x 4GB DDRDrive X1 (PCIe) in mirror for the ZIL 8x 100GB Samsung SS805 SSDs for the L2ARC (on an onboard PERC H700 controller) 2x PERC H800 and 2x PERC6 controllers for the JBODs below 11x Dell MD1000 JBODs with: 45x 750GB SATA HDDs 30x 1000GB SATA HDDs 60X 300GB SAS 15K HDDs 30x 600GB SAS 15K HDDs 2x 10GbE ports We plan to connect about 30 servers to it. About 8 will be currently I/O-bound MySQL databases with a 60/40 read bias, the rest will have much lighter usage. Most connections will be through iSCSI. Is there anything that seems out of proportion? Where do you think the bottleneck will be? If I'm going to use the SAS 15K drives for databases and the SATA drives for NFS/backups, how should I setup the pools? For the DB pools, I'd say use RAID10. For the backup areas, RAIDz2 groups with something like 8-10 drives in each should be ok. For high write, 4GB ZIL might be a little low, and you have probably way too much CPU for just NAS/SAN. Remember to leave a few disks for spares (1-2 of each size?). Apart from that, it looks like you may save some rack space by getting new (consumer) 2TB drives, but that's your choice :) 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] Performance drop during scrub?
On Sun, 2 May 2010, Tonmaus wrote: I am under the impression that exactly those were the considerations for both the ZFS designers to implement a scrub function to ZFS and the author of Best Practises to recommend performing this function frequently. I am hearing you are coming to a different conclusion and I would be interested in learning what could possibly be so highly interpretable in this. The value of periodic scrub is subject to opinion. There are some highly respected folks on this list who put less faith in scrub because they believe more in MTTDL statistical models and less in the value of early detection (scrub == early detection). With a single level of redundancy, early detection is more useful since there is just one opportunity to correct the error and correcting the error early decreases the chance of a later uncorrectable error. Scrub will help repair the results of transient wrong hardware operation, or partial media failures, but will not keep a whole disk from failing. Once the computed MTTDL for the storage configuration is sufficiently high, then other factors such as the reliability of ECC memory, kernel bugs, and hardware design flaws, become dominant. The human factor is often the most dominant factor when it comes to data loss since most data loss is still due to human error. Most data loss problems we see reported here are due to human error or hardware design flaws. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Spare in use althought disk is healthy ?
Hello, thanks for the feedback and sorry for the delay in answering. I checked the log and the fmadm. It seems the log does not show changes, however fmadm shows: Apr 23 2010 18:32:26.363495457 ereport.io.scsi.cmd.disk.dev.rqs.derr Apr 23 2010 18:32:26.363482031 ereport.io.scsi.cmd.disk.recovered Same thing for the other disk: Apr 21 2010 15:02:24.117303285 ereport.io.scsi.cmd.disk.dev.rqs.derr Apr 21 2010 15:02:24.117300448 ereport.io.scsi.cmd.disk.recovered It seems there is a VERY short temp error. I will try to detach this. Is this a Bug ? Robert -- 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] rpool gone after zpool detach
On Sun, May 2, 2010 at 3:51 PM, Jan Riechers jan.riech...@googlemail.comwrote: On Sun, May 2, 2010 at 6:06 AM, Roy Sigurd Karlsbakk r...@karlsbakk.netwrote: - Jan Riechers jan.riech...@googlemail.com skrev: I am using a mirrored system pool on 2 80G drives - however I was only using 40G since I thought I might use the rest for something else. ZFS Time Slider was complaining the pool was filled for 90% and I decided to increase pool size. What I did was a zpool detach of one of the mirrored hdds and increased the partition size to 100% with fdisk. When I wanted to reattach the hdd, system complained about an IO error and it hang. Now the rpool is gone on both drives (I also tried to find it via zpool import booting from USB - without success). Is there any chance I can recover the lost rpool? And what did I do wrong (except for not having a backup first)? ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss What error messages do you get? Please give more info Hi roy I'm not sure what the error message said in detail - however I cannot boot anymore since grub won't find the pool. However looking with zdb -l It finds at least on of the hdds 2 labels (the other which I didn't touch shows no label): pfexec zdb -l /dev/dsk/c6t5d0s2 Is there a chance to fix this pool? I managed to put back the old partition table/slice setup - since zdb showed some outdated pool on s2 - when I got back the correct slice setup - I could simply use c6t5d0s0 as rpool root. The mirrored disk was never really bootable and the mirror somehow broken. Is there an official howto for setting up a mirror for the rpool? -- Jan ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] rpool gone after zpool detach
On May 2, 2010, at 10:27 AM, Jan Riechers wrote: On Sun, May 2, 2010 at 3:51 PM, Jan Riechers jan.riech...@googlemail.com wrote: On Sun, May 2, 2010 at 6:06 AM, Roy Sigurd Karlsbakk r...@karlsbakk.net wrote: - Jan Riechers jan.riech...@googlemail.com skrev: I am using a mirrored system pool on 2 80G drives - however I was only using 40G since I thought I might use the rest for something else. ZFS Time Slider was complaining the pool was filled for 90% and I decided to increase pool size. What I did was a zpool detach of one of the mirrored hdds and increased the partition size to 100% with fdisk. When I wanted to reattach the hdd, system complained about an IO error and it hang. Now the rpool is gone on both drives (I also tried to find it via zpool import booting from USB - without success). Is there any chance I can recover the lost rpool? And what did I do wrong (except for not having a backup first)? ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss What error messages do you get? Please give more info Hi roy I'm not sure what the error message said in detail - however I cannot boot anymore since grub won't find the pool. However looking with zdb -l It finds at least on of the hdds 2 labels (the other which I didn't touch shows no label): pfexec zdb -l /dev/dsk/c6t5d0s2 Is there a chance to fix this pool? I managed to put back the old partition table/slice setup - since zdb showed some outdated pool on s2 - when I got back the correct slice setup - I could simply use c6t5d0s0 as rpool root. The mirrored disk was never really bootable and the mirror somehow broken. Is there an official howto for setting up a mirror for the rpool? ZFS Administration Guide. http://hub.opensolaris.org/bin/view/Community+Group+zfs/docs -- richard ZFS storage and performance consulting at http://www.RichardElling.com ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Performance drop during scrub?
On May 1, 2010, at 1:56 PM, Bob Friesenhahn wrote: On Fri, 30 Apr 2010, Freddie Cash wrote: Without a periodic scrub that touches every single bit of data in the pool, how can you be sure that 10-year files that haven't been opened in 5 years are still intact? You don't. But it seems that having two or three extra copies of the data on different disks should instill considerable confidence. With sufficient redundancy, chances are that the computer will explode before it loses data due to media corruption. The calculated time before data loss becomes longer than even the pyramids in Egypt could withstand. These calculations are based on fixed MTBF. But disk MTBF decreases with age. Most disks are only rated at 3-5 years of expected lifetime. Hence, archivists use solutions with longer lifetimes (high quality tape = 30 years) and plans for migrating the data to newer media before the expected media lifetime is reached. In short, if you don't expect to read your 5-year lifetime rated disk for another 5 years, then your solution is uhmm... shall we say... in need of improvement. The situation becomes similar to having a house with a heavy front door with three deadbolt locks, and many glass windows. The front door with its three locks is no longer a concern when you are evaluating your home for its security against burglary or home invasion because the glass windows are so fragile and easily broken. It is necessary to look at all the factors which might result in data loss before deciding what the most effective steps are to minimize the probability of loss. Yep... and manage the data over time. There is a good reason why library scientists will never worry about the future of their profession :-) http://en.wikipedia.org/wiki/Library_science -- richard ZFS storage and performance consulting at http://www.RichardElling.com ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Performance drop during scrub?
- Roy Sigurd Karlsbakk r...@karlsbakk.net skrev: Hi all I have a test system with snv134 and 8x2TB drives in RAIDz2 and currently no Zil or L2ARC. I noticed the I/O speed to NFS shares on the testpool drops to something hardly usable while scrubbing the pool. How can I address this? Will adding Zil or L2ARC help? Is it possible to tune down scrub's priority somehow? Further testing shows NFS speeds are acceptable after adding Zil and L2ARC (my test system has two SSDs for the root, so I detached on of them and split it into a 4GB slice for Zil and the rest for L2ARC). 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
[zfs-discuss] Default 'zpool' I want to move it to my new raidz pool 'gpool' how?
Hi guys I am new to Opensolaris and ZFS world, I have 6x2TB SATA hdds on my system, I picked a single 2TB disk and installed opensolaris (therefore zpool was created by the installer) I went ahead and created a new pool gpool with raidz (the kind of redundancy I want. Here's the output: @server:/# zfs list NAME USED AVAIL REFER MOUNTPOINT gpool119K 7.13T 30.4K /gpool rpool 7.78G 1.78T78K /rpool rpool/ROOT 3.30G 1.78T19K legacy rpool/ROOT/opensolaris 3.30G 1.78T 3.15G / rpool/dump 2.00G 1.78T 2.00G - rpool/export 491M 1.78T21K /export rpool/export/home491M 1.78T21K /export/home rpool/export/home/G 491M 1.78T 491M /export/home/G rpool/swap 2.00G 1.78T 101M - @server:/# @server:/# zpool status pool: gpool state: ONLINE scrub: none requested config: NAMESTATE READ WRITE CKSUM gpool ONLINE 0 0 0 raidz1ONLINE 0 0 0 c8t1d0 ONLINE 0 0 0 c8t2d0 ONLINE 0 0 0 c8t3d0 ONLINE 0 0 0 c8t4d0 ONLINE 0 0 0 c8t5d0 ONLINE 0 0 0 errors: No known data errors pool: rpool state: ONLINE scrub: none requested config: NAMESTATE READ WRITE CKSUM rpool ONLINE 0 0 0 c8t0d0s0 ONLINE 0 0 0 errors: No known data errors @server:/# Now, I want to get rid of rpool in its entirely, I want to migrate all settings, boot records, files from that rpool to gpool and then add the member of rpool c8t0d0s0 to my existing gpool so that I have a RAIDZ of 6x drives. Any guidance on how to do it? I tried to do zfs snapshot # zfs snapshot rp...@move But I don't see the snapshow anywhere on rpool/.zfs (there is no .zfs folder) 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] Default 'zpool' I want to move it to my new raidz pool 'gpool' how?
You can't get rid of rpool. That's the pool you're booting from. Root pools can only be single disks or n-way mirrors. As to your other question, you can view the snapshots by using the command zfs list -t all, or turn on the listsnaps property for the pool. See http://docs.sun.com/app/docs/doc/817-2271/ghbxt?a=view for more info. Regards, Mark On 2 May 2010, at 15:58, Giovanni g...@csu.fullerton.edu wrote: Hi guys I am new to Opensolaris and ZFS world, I have 6x2TB SATA hdds on my system, I picked a single 2TB disk and installed opensolaris (therefore zpool was created by the installer) I went ahead and created a new pool gpool with raidz (the kind of redundancy I want. Here's the output: @server:/# zfs list NAME USED AVAIL REFER MOUNTPOINT gpool119K 7.13T 30.4K /gpool rpool 7.78G 1.78T78K /rpool rpool/ROOT 3.30G 1.78T19K legacy rpool/ROOT/opensolaris 3.30G 1.78T 3.15G / rpool/dump 2.00G 1.78T 2.00G - rpool/export 491M 1.78T21K /export rpool/export/home491M 1.78T21K /export/home rpool/export/home/G 491M 1.78T 491M /export/home/G rpool/swap 2.00G 1.78T 101M - @server:/# @server:/# zpool status pool: gpool state: ONLINE scrub: none requested config: NAMESTATE READ WRITE CKSUM gpool ONLINE 0 0 0 raidz1ONLINE 0 0 0 c8t1d0 ONLINE 0 0 0 c8t2d0 ONLINE 0 0 0 c8t3d0 ONLINE 0 0 0 c8t4d0 ONLINE 0 0 0 c8t5d0 ONLINE 0 0 0 errors: No known data errors pool: rpool state: ONLINE scrub: none requested config: NAMESTATE READ WRITE CKSUM rpool ONLINE 0 0 0 c8t0d0s0 ONLINE 0 0 0 errors: No known data errors @server:/# Now, I want to get rid of rpool in its entirely, I want to migrate all settings, boot records, files from that rpool to gpool and then add the member of rpool c8t0d0s0 to my existing gpool so that I have a RAIDZ of 6x drives. Any guidance on how to do it? I tried to do zfs snapshot # zfs snapshot rp...@move But I don't see the snapshow anywhere on rpool/.zfs (there is no .zfs folder) Thanks -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Default 'zpool' I want to move it to my new raidz pool 'gpool' how?
- Giovanni g...@csu.fullerton.edu skrev: Hi guys I am new to Opensolaris and ZFS world, I have 6x2TB SATA hdds on my system, I picked a single 2TB disk and installed opensolaris (therefore zpool was created by the installer) I went ahead and created a new pool gpool with raidz (the kind of redundancy I want. Here's the output: Now, I want to get rid of rpool in its entirely, I want to migrate all settings, boot records, files from that rpool to gpool and then add the member of rpool c8t0d0s0 to my existing gpool so that I have a RAIDZ of 6x drives. Any guidance on how to do it? I tried to do zfs snapshot You can't boot off raidz. That's for data only. Get a couple of cheap drives or SSDs for the root and use the large drives for data Vennlige hilsener 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] Performance drop during scrub?
On Sun, 2 May 2010, Richard Elling wrote: These calculations are based on fixed MTBF. But disk MTBF decreases with age. Most disks are only rated at 3-5 years of expected lifetime. Hence, archivists use solutions with longer lifetimes (high quality tape = 30 years) and plans for migrating the data to newer media before the expected media lifetime is reached. In short, if you don't expect to read your 5-year lifetime rated disk for another 5 years, then your solution is uhmm... shall we say... in need of improvement. Yes, the hardware does not last forever. It only needs to last while it is still being used and should only be used during its expected service life. Your point is a good one. On the flip-side, using 'zfs scrub' puts more stress on the system which may make it more likely to fail. It increases load on the power supplies, CPUs, interfaces, and disks. A system which might work fine under normal load may be stressed and misbehave under scrub. Using scrub on a weak system could actually increase the chance of data loss. ZFS storage and performance consulting at http://www.RichardElling.com Please send $$$ to the above address in return for wisdom. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Performance drop during scrub?
On 5/2/10 3:12 PM, Bob Friesenhahn bfrie...@simple.dallas.tx.us wrote: On the flip-side, using 'zfs scrub' puts more stress on the system which may make it more likely to fail. It increases load on the power supplies, CPUs, interfaces, and disks. A system which might work fine under normal load may be stressed and misbehave under scrub. Using scrub on a weak system could actually increase the chance of data loss. If my system is going to fail under the stress of a scrub, it's going to fail under the stress of a resilver. From my perspective, I'm not as scared of data corruption as I am of data corruption *that I don't know about.* I only keep backups for a finite amount of time. If I scrub every week, and my zpool dies during a scrub, then I know it's time to pull out last week's backup, where I know (thanks to scrubbing) the data was not corrupt. I've lived the experience where a user comes to me because he tried to open a seven-year-old file and it was corrupt. Not a blankety-blank thing I could do, because we only retain backup tapes for four years and the four-year-old tape had a backup of the file post-corruption. Data loss may be unavoidable, but that's why we keep backups. It's the invisible data loss that makes life suboptimal. -- Dave Pooser, ACSA 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] Default 'zpool' I want to move it to my new raidz pool 'gpool' how?
On Sun, 2 May 2010, Roy Sigurd Karlsbakk wrote: Any guidance on how to do it? I tried to do zfs snapshot You can't boot off raidz. That's for data only. Unless you use FreeBSD ... Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Default 'zpool' I want to move it to my new raidz pool 'gpool' how?
Thank you. I was not aware that root pools could not be moved. But here's the kicker, what if I have a single drive for root pool, and its failing... I connect a new HDD to replace the boot drive thats dying, ZFS has no way of migrating to a new drive? 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] Performance drop during scrub?
On Sun, 2 May 2010, Dave Pooser wrote: If my system is going to fail under the stress of a scrub, it's going to fail under the stress of a resilver. From my perspective, I'm not as scared I don't disagree with any of the opinions you stated except to point out that resilver will usually hit the (old) hardware less severely than scrub. Resilver does not have to access any of the redundant copies of data or metadata, unless they are the only remaining good copy. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Default 'zpool' I want to move it to my new raidz pool 'gpool' how?
On Sun, 2 May 2010, Giovanni wrote: Thank you. I was not aware that root pools could not be moved. But here's the kicker, what if I have a single drive for root pool, and its failing... I connect a new HDD to replace the boot drive thats dying, ZFS has no way of migrating to a new drive? There is a way. The way would be to add a drive as a mirror of the old one. The new drive should be in a position where the BIOS is able to boot from it. The new drive would have its contents resilved based on the existing drive. However, if the old one is already failing, that could be somewhat problematic. Once the new drive is functional, you can detatch the failing one. Make sure that GRUB will boot from the new drive. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Virtual to physical migration
You do know that OpenSolaris + VirtualBox can trash your ZFS raid? You can loose your data. There is a post about write cache and ZFS and VirtualbBox, I think you need to disable it? -- 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] Default 'zpool' I want to move it to my new raidz pool 'gpool' how?
On Sun, May 2, 2010 at 1:55 PM, Giovanni g...@csu.fullerton.edu wrote: But here's the kicker, what if I have a single drive for root pool, and its failing... I connect a new HDD to replace the boot drive thats dying, ZFS has no way of migrating to a new drive? You can move root pools, I did it yesterday from a single 160GB drive to mirrored 120GB drives. You can't move them to anything other than a single disk or N-way mirror. No raidz, no striped sets. If a disk is failing, you can connect a new disk to the system and do a zpool replace, which will resilver the new drive with the data. Or you can attach a new drive to the pool to make a mirror. -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] Performance drop during scrub?
On May 2, 2010, at 12:05 PM, Roy Sigurd Karlsbakk wrote: - Roy Sigurd Karlsbakk r...@karlsbakk.net skrev: Hi all I have a test system with snv134 and 8x2TB drives in RAIDz2 and currently no Zil or L2ARC. I noticed the I/O speed to NFS shares on the testpool drops to something hardly usable while scrubbing the pool. How can I address this? Will adding Zil or L2ARC help? Is it possible to tune down scrub's priority somehow? Further testing shows NFS speeds are acceptable after adding Zil and L2ARC (my test system has two SSDs for the root, so I detached on of them and split it into a 4GB slice for Zil and the rest for L2ARC). Ok, this makes sense. If you are using a pool configuration which is not so good for high IOPS workloads (raidz*) and you give it a latency-sensitive, synchronous IOPS workload (NFS) along with another high IOPS workload (scrub), then the latency-sensitive workload will notice. Adding the SSD as a separate log is a good idea. -- richard ZFS storage and performance consulting at http://www.RichardElling.com ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Single-disk pool corrupted after controller failure
On 2010-May-02 04:06:41 +0800, Diogo Franco diogomfra...@gmail.com wrote: regular data corruption and then the box locked up. I had also converted the pool to v14 a few days before, so the freebsd v13 tools couldn't do anything to help. Note that ZFS v14 was imported to FreeBSD 8-stable in mid-January. I can't comment whether it would be able to recover your data. On 2010-May-02 05:07:17 +0800, Bill Sommerfeld bill.sommerf...@oracle.com wrote: 2) the labels are not at the start of what solaris sees as p1, and thus are somewhere else on the disk. I'd look more closely at how freebsd computes the start of the partition or slice '/dev/ad6s1d' that contains the pool. I think #2 is somewhat more likely. This is almost certainly the problem. ad6s1 may be the same as c5d0p1 but OpenSolaris isn't going to understand the FreeBSD partition label on that slice. All I can suggest is to (temporarily) change the disk slicing so that there is a fdisk slice that matches ad6s1d. -- Peter Jeremy pgpuiR7yDRv37.pgp Description: PGP signature ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zfs testing / problems
From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- boun...@opensolaris.org] On Behalf Of Roy Sigurd Karlsbakk bash-4.0# mkfile -n 2 d0 bash-4.0# zpool create pool $PWD/d0 bash-4.0# mkfile -n 1992869543936 d1 bash-4.0# zpool attach pool $PWD/d0 $PWD/d1 As long as you're just doing this for testing, great. I wouldn't suggest a configuration like that for any sort of permanent configuration. Filesystems inside of files ... In general, not a great idea. With only rare exceptions. Also, you know you can do it all on one line, right? zpool create mypool mirror $PWD/d0 $PWD/d1 Do a zpool status next. I think the supposed resilver will be basically instantaneous, because the pool is empty. But you should just check, and make sure the pool is healthy and not resilvering before you start your abuse. r...@mime:/testpool/testdisks# dd if=/dev/urandom of=d1 bs=100k count=1 skip=30 1+0 records in 1+0 records out 102400 bytes (102 kB) copied, 0.00208301 s, 49.2 MB/s r...@mime:/testpool/testdisks# dd if=/dev/urandom of=d0 bs=100k count=1 skip=50 1+0 records in 1+0 records out 102400 bytes (102 kB) copied, 0.00205321 s, 49.9 MB/s This resulted in a panic - see below for the info from the kernel log. That looks perfect to me, except one thing. You should zpool export before doing those dd's. While ZFS will correctly identify the faulty blocks (and in your case, correct them because you have a mirror) ... If you're doing that to the device while it's mounted, I think that's worse than unknown randomness happening on disks that aren't reporting the randomness. I think what you're doing (writing to the file, thus perhaps eliminating the ZFS open file handle to the device) is causing the devices to be swept out from under ZFS's feet. I think this technique is more like a simulation of unplugging disks, and less like a simulation of random undetected errors happening on disks. Also, if you're writing the randomness to blocks that happen to be unoccupied by anything, the system, I believe, won't even notice, because it'll never read the empty space that you've intentionally corrupted. To ensure a good result, I would recommend: Create the filesystem as you've done. Fill up the filesystem. Thus, when you later do a scrub it will have to inspect all blocks. zpool export. Perform the dd's from urandom as you've done. zpool import. Check: zpool status (it will probably say no errors) Then zpool scrub. After some time, zpool status will probably show that it found and corrected errors. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zpool mirror (dumb question)
From: Roy Sigurd Karlsbakk [mailto:r...@karlsbakk.net] Sent: Sunday, May 02, 2010 11:55 AM I am currently using OpenSolaris 2009.06 If I was to upgrade to the current developer version, forgive my ignorance (since I am new to *solaris), but how would I do this? # pkg set-publisher -O http://pkg.opensolaris.org/dev opensolaris.org # pkg image-update That'll take you to snv_134 or whatever the latest is This may be perfectly correct, but my personal experience is to say that installing from scratch with the later ISO is much more reliable than applying this upgrade path. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] zpool mirror (dumb question)
From: Steve Staples [mailto:thestapler...@gmail.com] I am currently using OpenSolaris 2009.06 If I was to upgrade to the current developer version, forgive my ignorance (since I am new to *solaris), but how would I do this? If you go to genunix.org (using the URL in my previous email) you can simply download the 134 iso file there. And install the OS from it. If you ever need to remember this, there's a ridiculously simple way to figure it out each time. Go to http://opensolaris.org (not to be confused with opensolaris.com) Go to the download page, and start reading. Before too long, you'll see some info about downloading and installing, or upgrading to developer releases. Including a reference to genunix. Zpool using partitions instead of whole devices If I was to take this route, I was under the impression that ZFS takes the drive as a whole, regardless of partitions, and wipes the data? This is true, if you specify the whole device. For example, if you format partition c0t0d0, and then you zpool create tank c0t0d0, then you're going to obliterate your format and partitions. However, if you zpool create tank c0t0d0p1 or zpool create tank c0t0d0s1 then it will use the slice (partition) instead of the whole device. ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
