On Mon, Jun 9, 2008 at 10:44 PM, Robert Thurlow <[EMAIL PROTECTED]> wrote:
> Brandon High wrote:
>> AFAIK, you're doing the best that you can while playing in the
>> constraints of ZFS. If you want to use nfs v3 with your clients,
>> you'll need to use UFS as the back end.
>
> Just a clarification:
Brandon High wrote:
> On Mon, Jun 9, 2008 at 3:14 PM, Andy Lubel <[EMAIL PROTECTED]> wrote:
>> Tried this today and although things appear to function correctly, the
>> performance seems to be steadily degrading. Am I getting burnt by
>> double-caching? If so, what is the best way to workaround f
On Mon, Jun 9, 2008 at 3:14 PM, Andy Lubel <[EMAIL PROTECTED]> wrote:
> Tried this today and although things appear to function correctly, the
> performance seems to be steadily degrading. Am I getting burnt by
> double-caching? If so, what is the best way to workaround for my sad
> situation? I
On Jun 9, 2008, at 12:28 PM, Andy Lubel wrote:
>
> On Jun 6, 2008, at 11:22 AM, Andy Lubel wrote:
>
>> That was it!
>>
>> hpux-is-old.com -> nearline.host NFS C GETATTR3 FH=F6B3
>> nearline.host -> hpux-is-old.com NFS R GETATTR3 OK
>> hpux-is-old.com -> nearline.host NFS C SETATTR3 FH=F6B3
>> nea
On Jun 6, 2008, at 11:22 AM, Andy Lubel wrote:
> That was it!
>
> hpux-is-old.com -> nearline.host NFS C GETATTR3 FH=F6B3
> nearline.host -> hpux-is-old.com NFS R GETATTR3 OK
> hpux-is-old.com -> nearline.host NFS C SETATTR3 FH=F6B3
> nearline.host -> hpux-is-old.com NFS R SETATTR3 Update synch m
That was it!
hpux-is-old.com -> nearline.host NFS C GETATTR3 FH=F6B3
nearline.host -> hpux-is-old.com NFS R GETATTR3 OK
hpux-is-old.com -> nearline.host NFS C SETATTR3 FH=F6B3
nearline.host -> hpux-is-old.com NFS R SETATTR3 Update synch mismatch
hpux-is-old.com -> nearline.host NFS C GETATTR3 FH=F
Andy Lubel wrote:
> I've got a real doozie.. We recently implemented a b89 as zfs/nfs/
> cifs server. The NFS client is HP-UX (11.23).
>
> What's happening is when our dba edits a file on the nfs mount with
> vi, it will not save.
>
> I removed vi from the mix by doing 'touch /nfs/file1' t
Andy Lubel wrote:
> Hello,
>
> I've got a real doozie.. We recently implemented a b89 as zfs/nfs/
> cifs server. The NFS client is HP-UX (11.23).
>
> What's happening is when our dba edits a file on the nfs mount with
> vi, it will not save.
>
> I removed vi from the mix by doing 'touch /nfs
Hello,
I've got a real doozie.. We recently implemented a b89 as zfs/nfs/
cifs server. The NFS client is HP-UX (11.23).
What's happening is when our dba edits a file on the nfs mount with
vi, it will not save.
I removed vi from the mix by doing 'touch /nfs/file1' then 'echo abc
> /nfs/f
Hello Ben,
Thursday, January 25, 2007, 9:02:53 PM, you wrote:
BR> I completely agree with Robert. I'd personally suggest 'truss' to start
BR> because its trivial to use, then start using DTrace to further hone down
BR> the problem.
I would argue that truss is simpler than dtrace in that case,
On Jan 25, 2007, at 1:02 PM, Ben Rockwood wrote:
Robert Milkowski wrote:
CLSNL> but if I click, say E, it has F's contents, F has Gs
contents, and no
CLSNL> mail has D's contents that I can see. But the list in the
mail
CLSNL> client list view is correct.
I don't belive it's a problem wi
Robert Milkowski wrote:
CLSNL> but if I click, say E, it has F's contents, F has Gs contents, and no
CLSNL> mail has D's contents that I can see. But the list in the mail
CLSNL> client list view is correct.
I don't belive it's a problem with nfs/zfs server.
Please try with simple dtrace script
Hello Chad,
Thursday, January 25, 2007, 9:14:24 AM, you wrote:
CLSNL> I am not sure if this is a zfs issue, and nfs issue, or a combination
CLSNL> of the two, or not an issue with them per se (caching or whatever),
CLSNL> or a courier-imap issue, or even a mail client issue.
CLSNL> However, th
I am not sure if this is a zfs issue, and nfs issue, or a combination
of the two, or not an issue with them per se (caching or whatever),
or a courier-imap issue, or even a mail client issue.
However, the issue happens in at least two different unrelated mail
clients, so I don't think it is
Don't forget to restart mapid after modifying default domain in
/etc/default/nfs.
As root, run "svcadm restart svc:/network/nfs/mapid".
I've run into this in the past.
Karen
eric kustarz wrote:
Erik Trimble wrote:
I actually think this is an NFSv4 issue, but I'm going to ask here
anyway...
Erik Trimble wrote:
I actually think this is an NFSv4 issue, but I'm going to ask here
anyway...
Server:Solaris 10 Update 2 (SPARC), with several ZFS file systems
shared via the legacy method (/etc/dfs/dfstab and share(1M), not via the
ZFS property). Default settings in /etc/default/nfs
b
I actually think this is an NFSv4 issue, but I'm going to ask here
anyway...
Server:Solaris 10 Update 2 (SPARC), with several ZFS file systems
shared via the legacy method (/etc/dfs/dfstab and share(1M), not via the
ZFS property). Default settings in /etc/default/nfs
bigbox# share
- /
17 matches
Mail list logo
