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-request at
opensolaris.org>wrote:
> Send zfs-discuss mailing list submissions to
> zfs-discuss at 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-request at opensolaris.org
>
> You can reach the person managing the list at
> zfs-discuss-owner at 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.Dik at Sun.COM)
> 4. Re: Proposed idea for enhancement - damage control
> (Casper.Dik at 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 <dan at geek.com.au>
> To: Ethan <notethan at gmail.com>
> Cc: zfs-discuss at opensolaris.org
> Subject: Re: [zfs-discuss] Help with corrupted pool
> Message-ID: <20100217232455.GS27182 at 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 <dmagda at ee.ryerson.ca>
> To: Richard Elling <richard.elling at gmail.com>
> Cc: ZFS discuss <zfs-discuss at opensolaris.org>
> Subject: Re: [zfs-discuss] Proposed idea for enhancement - damage
> control
> Message-ID: <5E7FC452-B888-4037-9EA4-6597E52EB623 at 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.Dik at Sun.COM
> To: Miles Nordin <carton at Ivy.NET>
> Cc: zfs-discuss at opensolaris.org
> Subject: Re: [zfs-discuss] Proposed idea for enhancement - damage
> control
> Message-ID: <201002180017.o1I0H7aA012522 at 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.Dik at Sun.COM
> To: Miles Nordin <carton at Ivy.NET>, zfs-discuss at opensolaris.org
> Subject: Re: [zfs-discuss] Proposed idea for enhancement - damage
> control
> Message-ID: <201002180026.o1I0QToo014231 at 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 <dan at geek.com.au>
> To: Miles Nordin <carton at Ivy.NET>
> Cc: zfs-discuss at opensolaris.org
> Subject: Re: [zfs-discuss] Proposed idea for enhancement - damage
> control
> Message-ID: <20100218005507.GT27182 at 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 <notethan at gmail.com>
> To: Ethan <notethan at gmail.com>, zfs-discuss at opensolaris.org
> Subject: Re: [zfs-discuss] Help with corrupted pool
> Message-ID:
> <f58506c41002171911y75f7d069pf5360cf6400217f2 at
mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Wed, Feb 17, 2010 at 18:24, Daniel Carosone <dan at 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 <mvainer at doyenz.com>
> To: zfs-discuss at opensolaris.org
> Subject: Re: [zfs-discuss] zpool status output confusing
> Message-ID: <1978297242.741266465598480.JavaMail.Twebapp at 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>
> /pci at 0,0/pci8086,340a at 3/pci17d3,1680 at 0/disk at 1,0
> 1. c7t1d1 <DEFAULT cyl 60797 alt 2 hd 255 sec 126>
> /pci at 0,0/pci8086,340a at 3/pci17d3,1680 at 0/disk at 1,1
> 2. c7t1d2 <DEFAULT cyl 60797 alt 2 hd 255 sec 126>
> /pci at 0,0/pci8086,340a at 3/pci17d3,1680 at 0/disk at 1,2
> 3. c7t1d3 <DEFAULT cyl 60797 alt 2 hd 255 sec 126>
> /pci at 0,0/pci8086,340a at 3/pci17d3,1680 at 0/disk at 1,3
> 4. c7t1d4 <DEFAULT cyl 60797 alt 2 hd 255 sec 126>
> /pci at 0,0/pci8086,340a at 3/pci17d3,1680 at 0/disk at 1,4
> 5. c7t1d5 <DEFAULT cyl 60797 alt 2 hd 255 sec 126>
> /pci at 0,0/pci8086,340a at 3/pci17d3,1680 at 0/disk at 1,5
> 6. c7t1d6 <DEFAULT cyl 60797 alt 2 hd 255 sec 126>
> /pci at 0,0/pci8086,340a at 3/pci17d3,1680 at 0/disk at 1,6
> 7. c7t1d7 <DEFAULT cyl 60797 alt 2 hd 255 sec 126>
> /pci at 0,0/pci8086,340a at 3/pci17d3,1680 at 0/disk at 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 <dd-b at dd-b.net>
> To: zfs-discuss at opensolaris.org
> Subject: Re: [zfs-discuss] zpool status output confusing
> Message-ID: <4B7CC003.3020300 at 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>
> > /pci at 0,0/pci8086,340a at 3/pci17d3,1680 at 0/disk at 1,0
> > 1. c7t1d1<DEFAULT cyl 60797 alt 2 hd 255 sec 126>
> > /pci at 0,0/pci8086,340a at 3/pci17d3,1680 at 0/disk at 1,1
> > 2. c7t1d2<DEFAULT cyl 60797 alt 2 hd 255 sec 126>
> > /pci at 0,0/pci8086,340a at 3/pci17d3,1680 at 0/disk at 1,2
> > 3. c7t1d3<DEFAULT cyl 60797 alt 2 hd 255 sec 126>
> > /pci at 0,0/pci8086,340a at 3/pci17d3,1680 at 0/disk at 1,3
> > 4. c7t1d4<DEFAULT cyl 60797 alt 2 hd 255 sec 126>
> > /pci at 0,0/pci8086,340a at 3/pci17d3,1680 at 0/disk at 1,4
> > 5. c7t1d5<DEFAULT cyl 60797 alt 2 hd 255 sec 126>
> > /pci at 0,0/pci8086,340a at 3/pci17d3,1680 at 0/disk at 1,5
> > 6. c7t1d6<DEFAULT cyl 60797 alt 2 hd 255 sec 126>
> > /pci at 0,0/pci8086,340a at 3/pci17d3,1680 at 0/disk at 1,6
> > 7. c7t1d7<DEFAULT cyl 60797 alt 2 hd 255 sec 126>
> > /pci at 0,0/pci8086,340a at 3/pci17d3,1680 at 0/disk at 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, dd-b at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100218/cc7bc23a/attachment.html>