update on this one:
a workaround if you so will, or the more appropriate way to do this is
apparently
to use lofiadm(1M) to create a pseudo block device comprising the file hosted
on NFS
and use the created lofi device (eg. /dev/lofi/1) as the device for zpool create
and all subsequent I/O (thi
On Fri, 08 Jan 2010 18:33:06 +0100, Mike Gerdts wrote:
> I've written a dtrace script to get the checksums on Solaris 10.
> Here's what I see with NFSv3 on Solaris 10.
jfyi, I've reproduces it as well using a Solaris 10 Update 8 SB2000 sparc client
and NFSv4.
much like you I also get READ error
On Fri, Jan 8, 2010 at 12:28 PM, Torrey McMahon wrote:
> On 1/8/2010 10:04 AM, James Carlson wrote:
>>
>> Mike Gerdts wrote:
>>
>>>
>>> This unsupported feature is supported with the use of Sun Ops Center
>>> 2.5 when a zone is put on a "NAS Storage Library".
>>>
>>
>> Ah, ok. I didn't know that.
On Jan 8, 2010, at 6:20 AM, Frank Batschulat (Home) wrote:
On Fri, 08 Jan 2010 13:55:13 +0100, Darren J Moffat > wrote:
Frank Batschulat (Home) wrote:
This just can't be an accident, there must be some coincidence and
thus there's a good chance
that these CHKSUM errors must have a common sou
On 1/8/2010 10:04 AM, James Carlson wrote:
Mike Gerdts wrote:
This unsupported feature is supported with the use of Sun Ops Center
2.5 when a zone is put on a "NAS Storage Library".
Ah, ok. I didn't know that.
Does anyone know how that works? I can't find it in the docs, no on
Mike Gerdts wrote:
> This unsupported feature is supported with the use of Sun Ops Center
> 2.5 when a zone is put on a "NAS Storage Library".
Ah, ok. I didn't know that.
--
James Carlson 42.703N 71.076W
___
zfs-discuss mailing list
z
On Fri, 08 Jan 2010 13:55:13 +0100, Darren J Moffat
wrote:
> Frank Batschulat (Home) wrote:
>> This just can't be an accident, there must be some coincidence and thus
>> there's a good chance
>> that these CHKSUM errors must have a common source, either in ZFS or in NFS ?
>
> What are you using
Frank Batschulat (Home) wrote:
> This just can't be an accident, there must be some coincidence and thus
> there's a good chance
> that these CHKSUM errors must have a common source, either in ZFS or in NFS ?
One possible cause would be a lack of substantial exercise. The man
page says:
On Fri, Jan 8, 2010 at 9:11 AM, Mike Gerdts wrote:
> I've seen similar errors on Solaris 10 in the primary domain and on a
> M4000. Unfortunately Solaris 10 doesn't show the checksums in the
> ereport. There I noticed a mixture between read errors and checksum
> errors - and lots more of them.
On Fri, Jan 8, 2010 at 5:28 AM, Frank Batschulat (Home)
wrote:
[snip]
> Hey Mike, you're not the only victim of these strange CHKSUM errors, I hit
> the same during my slightely different testing, where I'm NFS mounting an
> entire, pre-existing remote file living in the zpool on the NFS server an
On Fri, Jan 8, 2010 at 6:51 AM, James Carlson wrote:
> Frank Batschulat (Home) wrote:
>> This just can't be an accident, there must be some coincidence and thus
>> there's a good chance
>> that these CHKSUM errors must have a common source, either in ZFS or in NFS ?
>
> One possible cause would b
On Fri, Jan 8, 2010 at 6:55 AM, Darren J Moffat wrote:
> Frank Batschulat (Home) wrote:
>>
>> This just can't be an accident, there must be some coincidence and thus
>> there's a good chance
>> that these CHKSUM errors must have a common source, either in ZFS or in
>> NFS ?
>
> What are you using
Frank Batschulat (Home) wrote:
This just can't be an accident, there must be some coincidence and thus there's
a good chance
that these CHKSUM errors must have a common source, either in ZFS or in NFS ?
What are you using for on the wire protection with NFS ? Is it shared
using krb5i or do y
On Wed, 23 Dec 2009 03:02:47 +0100, Mike Gerdts wrote:
> I've been playing around with zones on NFS a bit and have run into
> what looks to be a pretty bad snag - ZFS keeps seeing read and/or
> checksum errors. This exists with S10u8 and OpenSolaris dev build
> snv_129. This is likely a blocker
14 matches
Mail list logo
