Unfortunately I've started restoring data onto my array (2.5TB @ the 20ish
MB/sec my LTO2 drive maxes out at will take a while ;) ) so I can't do any more
testing that involves destroying the zpool and/or individual devices...
So all the numbers below are to a 16-disk raidz2 zpool (unless otherw
Hello zfs-discuss,
I did 'zfs umount -a' in a global zone and all (non busy) datasets
also in local zone were unmounted (one dataset was delegated to the
local zone and other datasets were created inside). Well, I belive it
shouldn't be
that way at least not by default.
What do you thi
Richard Elling wrote:
Gael wrote:
jumps8002:/etc/apache2 #cat /etc/release
Solaris 10 11/06 s10s_u3wos_10 SPARC
Copyright 2006 Sun Microsystems, Inc. All Rights Reserved.
Use is subject to license terms.
Assemb
Gael wrote:
jumps8002:/etc/apache2 #cat /etc/release
Solaris 10 11/06 s10s_u3wos_10 SPARC
Copyright 2006 Sun Microsystems, Inc. All Rights Reserved.
Use is subject to license terms.
Assembled 14 November 2006
Hi Robert,
Will build 54 offline the drive?
Best Regards,
Jason
On 1/13/07, Robert Milkowski <[EMAIL PROTECTED]> wrote:
Hello Jason,
Saturday, January 13, 2007, 12:06:57 AM, you wrote:
JJWW> Hi Robert,
JJWW> We've experienced luck with flaky SATA drives in our STK array by
JJWW> unseating a
Eric Schrock <[EMAIL PROTECTED]> wrote:
> On Sat, Jan 13, 2007 at 12:11:26PM -0800, Richard Elling wrote:
> >
> > So, what is in your format.dat? I haven't seen an MD21 in over 15 years.
> > I would have thought that we removed it from format.dat long ago...
> > -- richard
>
> This sounds like:
On 1/13/07, Eric Schrock <[EMAIL PROTECTED]> wrote:
On Sat, Jan 13, 2007 at 01:30:19PM -0600, Gael wrote:
> Hello,
>
> jumps8002 #zpool create sanpool c7t50060E8004758654d0
c7t50060E8004758654d1
> c7t50060E8004758654d2
> cannot open '/dev/dsk/c7t50060E8004758654d0s0':
This is a strange error, c
On Sat, Jan 13, 2007 at 01:30:19PM -0600, Gael wrote:
> Hello,
>
> jumps8002 #zpool create sanpool c7t50060E8004758654d0 c7t50060E8004758654d1
> c7t50060E8004758654d2
> cannot open '/dev/dsk/c7t50060E8004758654d0s0':
This is a strange error, can you do a 'truss -topen' of this process?
Does the a
On 1/13/07, Eric Schrock <[EMAIL PROTECTED]> wrote:
On Sat, Jan 13, 2007 at 12:11:26PM -0800, Richard Elling wrote:
>
> So, what is in your format.dat? I haven't seen an MD21 in over 15
years.
> I would have thought that we removed it from format.dat long ago...
> -- richard
This sounds like:
On 1/13/07, Richard Elling <[EMAIL PROTECTED]> wrote:
Gael wrote:
> Hello,
>
> I'm currently trying to convert a system from Solaris 10 U1 with Veritas
> VM to Solaris 10 U3 with ZFS... the san portion of the server is managed
> by Hitachi HDLM 5.8.
>
> I'm seeing two distinct errors... let me k
On Sat, Jan 13, 2007 at 12:11:26PM -0800, Richard Elling wrote:
>
> So, what is in your format.dat? I haven't seen an MD21 in over 15 years.
> I would have thought that we removed it from format.dat long ago...
> -- richard
This sounds like:
5020503 *format* Unknown controller 'MD21' warnings
Gael wrote:
Hello,
I'm currently trying to convert a system from Solaris 10 U1 with Veritas
VM to Solaris 10 U3 with ZFS... the san portion of the server is managed
by Hitachi HDLM 5.8.
I'm seeing two distinct errors... let me know if they are classical or
if I should open a ticket (bug re
Hello,
I'm currently trying to convert a system from Solaris 10 U1 with Veritas VM
to Solaris 10 U3 with ZFS... the san portion of the server is managed by
Hitachi HDLM 5.8.
I'm seeing two distinct errors... let me know if they are classical or if I
should open a ticket (bug report)... Thanks i
roland wrote:
i have come across an interesting article at :
http://www.anandtech.com/IT/showdoc.aspx?i=2859&p=5
it`s about sata vs. sas/scsi realiability , telling that typical desktop sata drives
".on average experience an Unrecoverable Error every 12.5 terabytes written or read (EUR of
On 13-Jan-07, at 11:52 AM, roland wrote:
i have come across an interesting article at :
http://www.anandtech.com/IT/showdoc.aspx?i=2859&p=5
it`s about sata vs. sas/scsi realiability , telling that typical
desktop sata drives
".on average experience an Unrecoverable Error every 12.5
te
On 1/13/07, roland <[EMAIL PROTECTED]> wrote:
thanks for your infos!
> > can zfs protect my data from such single-bit-errors with a single drive ?
> >
>nope.. but it can tell you that it has occurred.
can it also tell (or can i use a tool to determine), which data/file is
affected by this erro
thanks for your infos!
> > can zfs protect my data from such single-bit-errors with a single drive ?
> >
>nope.. but it can tell you that it has occurred.
can it also tell (or can i use a tool to determine), which data/file is
affected by this error (and needs repair/restore from backup) ?
T
On 1/13/07, roland <[EMAIL PROTECTED]> wrote:
i have come across an interesting article at :
http://www.anandtech.com/IT/showdoc.aspx?i=2859&p=5
it`s about sata vs. sas/scsi realiability , telling that typical desktop sata
drives
".on average experience an Unrecoverable Error every 12.5 te
i have come across an interesting article at :
http://www.anandtech.com/IT/showdoc.aspx?i=2859&p=5
it`s about sata vs. sas/scsi realiability , telling that typical desktop sata
drives
".on average experience an Unrecoverable Error every 12.5 terabytes written
or read (EUR of 1 in 1014 bit
I'm observing the following behavior in our environment (Sol10U2, E2900, 24x96,
2x2Gbps, ...)
- I've a compressed ZFS filesystem where I'm creating a large tar file. I
notice that the tar process is running fine (accumulating CPU, truss shows
writes, ...) but for whatever reason the timestamp o
On Mon, Jan 08, 2007 at 11:00:36AM -0600, [EMAIL PROTECTED] wrote:
> I have been looking at zfs source trying to get up to speed on the
> internals. One thing that interests me about the fs is what appears to be
> a low hanging fruit for block squishing CAS (Content Addressable Storage).
> I think
Hello Jason,
Saturday, January 13, 2007, 12:06:57 AM, you wrote:
JJWW> Hi Robert,
JJWW> We've experienced luck with flaky SATA drives in our STK array by
JJWW> unseating and reseating the drive to cause a reset of the firmware. It
JJWW> may be a bad drive, or the firmware may just have hit a bug
22 matches
Mail list logo
