I am getting loads of problem in using solaris test framework as there is less information on it. I've got stuck in stf_configure. Can anyone please send me the info of how to configure stf & run the test cases in it? And also how can i make it runnable on any linux distro?
Thanks in advance. On Thu, Feb 18, 2010 at 9:50 AM, <zfs-discuss-requ...@opensolaris.org>wrote: > Send zfs-discuss mailing list submissions to > zfs-discuss@opensolaris.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss > or, via email, send a message with subject or body 'help' to > zfs-discuss-requ...@opensolaris.org > > You can reach the person managing the list at > zfs-discuss-ow...@opensolaris.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of zfs-discuss digest..." > > > Today's Topics: > > 1. Re: Help with corrupted pool (Daniel Carosone) > 2. Re: Proposed idea for enhancement - damage control (David Magda) > 3. Re: Proposed idea for enhancement - damage control > (casper....@sun.com) > 4. Re: Proposed idea for enhancement - damage control > (casper....@sun.com) > 5. Re: Proposed idea for enhancement - damage control > (Daniel Carosone) > 6. Re: Help with corrupted pool (Ethan) > 7. Re: zpool status output confusing (Moshe Vainer) > 8. Re: zpool status output confusing (David Dyer-Bennet) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 18 Feb 2010 10:24:55 +1100 > From: Daniel Carosone <d...@geek.com.au> > To: Ethan <notet...@gmail.com> > Cc: zfs-discuss@opensolaris.org > Subject: Re: [zfs-discuss] Help with corrupted pool > Message-ID: <20100217232455.gs27...@bcd.geek.com.au> > Content-Type: text/plain; charset="us-ascii" > > On Wed, Feb 17, 2010 at 06:15:25PM -0500, Ethan wrote: > > Success! > > Awesome. Let that scrub finish before celebrating completely, but > this looks like a good place to stop and consider what you want for an > end state. > > -- > Dan. > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 194 bytes > Desc: not available > URL: < > http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100218/c258313a/attachment-0001.bin > > > > ------------------------------ > > Message: 2 > Date: Wed, 17 Feb 2010 18:53:29 -0500 > From: David Magda <dma...@ee.ryerson.ca> > To: Richard Elling <richard.ell...@gmail.com> > Cc: ZFS discuss <zfs-discuss@opensolaris.org> > Subject: Re: [zfs-discuss] Proposed idea for enhancement - damage > control > Message-ID: <5e7fc452-b888-4037-9ea4-6597e52eb...@ee.ryerson.ca> > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > On Feb 17, 2010, at 12:34, Richard Elling wrote: > > > I'm not sure how to connect those into the system (USB 3?), but when > > you build it, let us > > know how it works out. > > FireWire 3200 preferably. Anyone know if USB 3 sucks as much CPU as > previous versions? > > If I'm burning CPU on I/O I'd rather having going to checksums than > polling cheap-ass USB controllers that need to be baby sat. > > > > ------------------------------ > > Message: 3 > Date: Thu, 18 Feb 2010 01:17:07 +0100 > From: casper....@sun.com > To: Miles Nordin <car...@ivy.net> > Cc: zfs-discuss@opensolaris.org > Subject: Re: [zfs-discuss] Proposed idea for enhancement - damage > control > Message-ID: <201002180017.o1i0h7aa012...@dm-holland-02.uk.sun.com> > Content-Type: text/plain; charset=us-ascii > > > > >If there were a real-world device that tended to randomly flip bits, > >or randomly replace swaths of LBA's with zeroes, but otherwise behave > >normally (not return any errors, not slow down retrying reads, not > >fail to attach), then copies=2 would be really valuable, but so far it > >seems no such device exists. If you actually explore the errors that > >really happen I venture there are few to no cases copies=2 would save > >you. > > I had a device which had 256 bytes of the 32MB broken (some were "1", some > were always "0"). But I never put it online because it was so broken. > > Casper > > > > ------------------------------ > > Message: 4 > Date: Thu, 18 Feb 2010 01:26:29 +0100 > From: casper....@sun.com > To: Miles Nordin <car...@ivy.net>, zfs-discuss@opensolaris.org > Subject: Re: [zfs-discuss] Proposed idea for enhancement - damage > control > Message-ID: <201002180026.o1i0qtoo014...@dm-holland-02.uk.sun.com> > Content-Type: text/plain; charset=us-ascii > > > > > > > >>If there were a real-world device that tended to randomly flip bits, > >>or randomly replace swaths of LBA's with zeroes, but otherwise behave > >>normally (not return any errors, not slow down retrying reads, not > >>fail to attach), then copies=2 would be really valuable, but so far it > >>seems no such device exists. If you actually explore the errors that > >>really happen I venture there are few to no cases copies=2 would save > >>you. > > > >I had a device which had 256 bytes of the 32MB broken (some were "1", some > >were always "0"). But I never put it online because it was so broken. > > Of the 32MB cache, sorry. > > Casper > > > > ------------------------------ > > Message: 5 > Date: Thu, 18 Feb 2010 11:55:07 +1100 > From: Daniel Carosone <d...@geek.com.au> > To: Miles Nordin <car...@ivy.net> > Cc: zfs-discuss@opensolaris.org > Subject: Re: [zfs-discuss] Proposed idea for enhancement - damage > control > Message-ID: <20100218005507.gt27...@bcd.geek.com.au> > Content-Type: text/plain; charset="us-ascii" > > On Wed, Feb 17, 2010 at 02:38:04PM -0500, Miles Nordin wrote: > > copies=2 has proven to be mostly useless in practice. > > I disagree. Perhaps my cases fit under the weasel-word "mostly", but > single-disk laptops are a pretty common use-case. > > > If there were a real-world device that tended to randomly flip bits, > > or randomly replace swaths of LBA's with zeroes > > As an aside, there can be non-device causes of this, especially when > sharing disks with other operating systems, booting livecd's and etc. > > > * drives do not immediately turn red and start brrk-brrking when they > > go bad. In the real world, they develop latent sector errors, > > which you will not discover and mark the drive bad until you scrub > > or coincidentally happen to read the file that accumulated the > > error. > > Yes, exactly - at this point, with copies=1, you get a signal that > your drive is about to go bad, and that data has been lost. With > copies=2, you get a signal that your drive is about to go bad, but > less disruption and data loss to go with it. Note that pool metadata > is inherently using ditto blocks for precisely this reason. > > I dunno about BER spec, but I have seen sectors go unreadable many > times. Sometimes, as you note, in combination with other problems or > further deterioriation, sometimes not. Regardless of what you do in > response, and how soon you replace the drive, copies >1 can cover that > interval. > > I agree fully, copies=2 is not a substitute for backup replication of > whatever flavour you prefer. It is a useful supplement. > Misunderstanding this is dangerous. > > -- > Dan. > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 194 bytes > Desc: not available > URL: < > http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100218/8cf99e80/attachment-0001.bin > > > > ------------------------------ > > Message: 6 > Date: Wed, 17 Feb 2010 22:11:56 -0500 > From: Ethan <notet...@gmail.com> > To: Ethan <notet...@gmail.com>, zfs-discuss@opensolaris.org > Subject: Re: [zfs-discuss] Help with corrupted pool > Message-ID: > <f58506c41002171911y75f7d069pf5360cf640021...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > On Wed, Feb 17, 2010 at 18:24, Daniel Carosone <d...@geek.com.au> wrote: > > > On Wed, Feb 17, 2010 at 06:15:25PM -0500, Ethan wrote: > > > Success! > > > > Awesome. Let that scrub finish before celebrating completely, but > > this looks like a good place to stop and consider what you want for an > > end state. > > > > -- > > Dan. > > > > True. Thinking about where to end up - I will be staying on opensolaris > despite having no truecrypt. My paranoia likes having encryption, but it's > not really necessary for me, and it looks like encryption will be coming to > zfs itself soon enough. So, no need to consider getting things working on > zfs-fuse again. > > I should have a partition table, for one thing, I suppose. The partition > table is EFI GUID Partition Table, looking at the relevant documentation. > So, I'll need to somehow shift my zfs data down by 17408 bytes (34 512-byte > LBA's, the size of the GPT's stuff at the beginning of the disk) - perhaps > just by copying from the truecrypt volumes as I did before, but with offset > of 17408 bytes. Then I should be able to use format to make the correct > partition information, and use the s0 partition for each drive as seems to > be the standard way of doing things. Or maybe I can format (write the GPT) > first, then get linux to recognize the GPT, and copy from truecrypt into > the > partition. > > Does that sound correct / sensible? Am I missing or mistaking anything? > > Thanks, > -Ethan > > PS: scrub in progress for 4h4m, 65.43% done, 2h9m to go - no errors yet. > Looking good. > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100217/de30929b/attachment-0001.html > > > > ------------------------------ > > Message: 7 > Date: Wed, 17 Feb 2010 19:59:28 PST > From: Moshe Vainer <mvai...@doyenz.com> > To: zfs-discuss@opensolaris.org > Subject: Re: [zfs-discuss] zpool status output confusing > Message-ID: <1978297242.741266465598480.javamail.tweb...@sf-app1> > Content-Type: text/plain; charset=UTF-8 > > I have another very weird one, looks like a reoccurance of the same issue > but with the new firmware. > > We have the following disks: > > AVAILABLE DISK SELECTIONS: > 0. c7t1d0 <DEFAULT cyl 60797 alt 2 hd 255 sec 126> > /p...@0,0/pci8086,3...@3/pci17d3,1...@0/d...@1,0 > 1. c7t1d1 <DEFAULT cyl 60797 alt 2 hd 255 sec 126> > /p...@0,0/pci8086,3...@3/pci17d3,1...@0/d...@1,1 > 2. c7t1d2 <DEFAULT cyl 60797 alt 2 hd 255 sec 126> > /p...@0,0/pci8086,3...@3/pci17d3,1...@0/d...@1,2 > 3. c7t1d3 <DEFAULT cyl 60797 alt 2 hd 255 sec 126> > /p...@0,0/pci8086,3...@3/pci17d3,1...@0/d...@1,3 > 4. c7t1d4 <DEFAULT cyl 60797 alt 2 hd 255 sec 126> > /p...@0,0/pci8086,3...@3/pci17d3,1...@0/d...@1,4 > 5. c7t1d5 <DEFAULT cyl 60797 alt 2 hd 255 sec 126> > /p...@0,0/pci8086,3...@3/pci17d3,1...@0/d...@1,5 > 6. c7t1d6 <DEFAULT cyl 60797 alt 2 hd 255 sec 126> > /p...@0,0/pci8086,3...@3/pci17d3,1...@0/d...@1,6 > 7. c7t1d7 <DEFAULT cyl 60797 alt 2 hd 255 sec 126> > /p...@0,0/pci8086,3...@3/pci17d3,1...@0/d...@1,7 > > rpool uses c7d1d7 > > # zpool status > pool: rpool > state: ONLINE > scrub: none requested > config: > > NAME STATE READ WRITE CKSUM > rpool ONLINE 0 0 0 > c7t1d7s0 ONLINE 0 0 0 > > errors: No known data errors > > > I tried to create the following tank: > > zpool create -f tank \ > raidz2 \ > c7t1d0 \ > c7t1d1 \ > c7t1d2 \ > c7t1d3 \ > c7t1d4 \ > c7t1d5 \ > spare \ > c7t1d6 > > # ./mktank.sh > invalid vdev specification > the following errors must be manually repaired: > /dev/dsk/c7t1d7s0 is part of active ZFS pool rpool. Please see zpool(1M). > > So clearly, it confuses one of the other drives with c7t1d7 > > What's even weirder - this is after a clean reinstall of solaris (it's a > test box). > Any ideas on how to clean the state? > James, if you read this, is this the same issue? > > Thanks in advance, > Moshe > -- > This message posted from opensolaris.org > > > ------------------------------ > > Message: 8 > Date: Wed, 17 Feb 2010 22:20:19 -0600 > From: David Dyer-Bennet <d...@dd-b.net> > To: zfs-discuss@opensolaris.org > Subject: Re: [zfs-discuss] zpool status output confusing > Message-ID: <4b7cc003.3020...@dd-b.net> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 2/17/2010 9:59 PM, Moshe Vainer wrote: > > I have another very weird one, looks like a reoccurance of the same issue > but with the new firmware. > > > > We have the following disks: > > > > AVAILABLE DISK SELECTIONS: > > 0. c7t1d0<DEFAULT cyl 60797 alt 2 hd 255 sec 126> > > /p...@0,0/pci8086,3...@3/pci17d3,1...@0/d...@1,0 > > 1. c7t1d1<DEFAULT cyl 60797 alt 2 hd 255 sec 126> > > /p...@0,0/pci8086,3...@3/pci17d3,1...@0/d...@1,1 > > 2. c7t1d2<DEFAULT cyl 60797 alt 2 hd 255 sec 126> > > /p...@0,0/pci8086,3...@3/pci17d3,1...@0/d...@1,2 > > 3. c7t1d3<DEFAULT cyl 60797 alt 2 hd 255 sec 126> > > /p...@0,0/pci8086,3...@3/pci17d3,1...@0/d...@1,3 > > 4. c7t1d4<DEFAULT cyl 60797 alt 2 hd 255 sec 126> > > /p...@0,0/pci8086,3...@3/pci17d3,1...@0/d...@1,4 > > 5. c7t1d5<DEFAULT cyl 60797 alt 2 hd 255 sec 126> > > /p...@0,0/pci8086,3...@3/pci17d3,1...@0/d...@1,5 > > 6. c7t1d6<DEFAULT cyl 60797 alt 2 hd 255 sec 126> > > /p...@0,0/pci8086,3...@3/pci17d3,1...@0/d...@1,6 > > 7. c7t1d7<DEFAULT cyl 60797 alt 2 hd 255 sec 126> > > /p...@0,0/pci8086,3...@3/pci17d3,1...@0/d...@1,7 > > > > rpool uses c7d1d7 > > > > # zpool status > > pool: rpool > > state: ONLINE > > scrub: none requested > > config: > > > > NAME STATE READ WRITE CKSUM > > rpool ONLINE 0 0 0 > > c7t1d7s0 ONLINE 0 0 0 > > > > errors: No known data errors > > > > > > I tried to create the following tank: > > > > zpool create -f tank \ > > raidz2 \ > > c7t1d0 \ > > c7t1d1 \ > > c7t1d2 \ > > c7t1d3 \ > > c7t1d4 \ > > c7t1d5 \ > > spare \ > > c7t1d6 > > > > # ./mktank.sh > > invalid vdev specification > > the following errors must be manually repaired: > > /dev/dsk/c7t1d7s0 is part of active ZFS pool rpool. Please see zpool(1M). > > > > So clearly, it confuses one of the other drives with c7t1d7 > > > > What's even weirder - this is after a clean reinstall of solaris (it's a > test box). > > Any ideas on how to clean the state? > > James, if you read this, is this the same issue? > > > > Well, I'd certainly chase through the symbolic links to find if the > device files were pointing the wrong places in the end, or if the > problem is lower in the stack than that. Since it's a clean install > it's a Solaris bug at some level either way, sounds like. > > -- > David Dyer-Bennet, d...@dd-b.net; http://dd-b.net/ > Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/ > Photos: http://dd-b.net/photography/gallery/ > Dragaera: http://dragaera.info > > > > ------------------------------ > > _______________________________________________ > zfs-discuss mailing list > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss > > > End of zfs-discuss Digest, Vol 52, Issue 108 > ******************************************** > -- Regards Amit G KQ Infotech Mob. No : +91 9823615534
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
