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, 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 Z
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
On Sat, 30 Dec 2006 18:13:04 +0100, <[EMAIL PROTECTED]> wrote:
I think removing the ability to use link(2) or unlink(2) on directories
would hurt no-one and would make a few things easier.
I'd be rather carful here, see the standards implications drafted in
4917742.
The standard gives perm
On Sat, 30 Dec 2006 02:28:49 +0100, Pawel Jakub Dawidek <[EMAIL PROTECTED]>
wrote:
Hi.
Here are some things my file system test suite discovered on Solaris ZFS
and UFS.
Bascially ZFS pass all my tests (about 3000). I see one problem with UFS
and two differences:
1. link(2) manual page state
On Sat, 30 Dec 2006 15:50:53 +0100, <[EMAIL PROTECTED]> wrote:
Link with the target being a directory and the source a any file or
only directories? And only as superuer?
I'm sorry, I ment unlink(2) here.
Ah, so symmetrical with link(2) to directories.
unlink(2) doesn't always work and r
On Tue, 10 Oct 2006 01:25:36 +0200, Roch <[EMAIL PROTECTED]> wrote:
You tell me ? We have 2 issues
can we make 'tar x' over direct attach, safe (fsync)
and posix compliant while staying close to current
performance characteristics ? In other words do we
have the
