nfs synchronous mode on 11.23

[fabio sibillano]

Hi all, this question can be both a sysadm or a db question...

I have a nfs disk exported for dumping rman jobs for a 10g rac oracle installation.
The disk, itself, works without problems, but with relative "poor" performance because is exported in synchronous mode. Hp-ux is 11.23, and of course nfs is v.3, and it goes with tcp.
At the time of the planning and developing this cluster, the sysadm (now he works in another company) was a solaris adm, and decided to export this disk in syncronous mode.
But i can't understand why.
In this disk rman allocates four channels, and dumps out very big files, up to 240gb and more, but this is not a problem for nfs v3 and largefile, so the question:

Teorically speaking, asynchronous mode can experience data corruption in case of crash or power outage, but for a rman jobs I can assume this risk. After all I (eventually) only have to resubmit the job.

Why, in your opinions, this adm wants (months ago) to export this nfs disk in synchronous mode ?
I think i can safely change it in to an asynchronous nfs disk, without risks...
Or there are particular problems for a 10g raw/rac/asm cluster installation ? The exported disk is used ONLY to retain rman data, until a backup agent takes all files in a tape.

Thanks in advance.

Fabio

[Steven E. Protter]

Shalom Fabio,

I'd have done it async based on everything you say.

Its a backup disk, the risk seems reasonable.

SEP

[Dave Olker · Accepted solution]

Hello Fabio,

First of all, how is your server exporting the filesystem for "synchronous" access? What type of server is this? What OS is it running? What export option is it using to force synchronous semantics?

Secondly, there seems to be a misunderstanding about how NFS works with asynchronous writes:

> Teorically speaking, asynchronous mode can
> experience data corruption in case of crash
> or power outage

With NFS version 2 this was a concern but not with NFS version 3.

NFS v3 was specifically designed to eliminate this problem. NFS v3 has something called "Safe Asynchronous Writes" where the client and server exchange verifiers with each write request and the client keeps a copy of the data in it's cache until it receives confirmation from the server that the data has been posted to stable storage. If the server crashes in the middle of a write, once the server reboots it will advertise a different verifier to the client and the client will know it needs to re-send it's cached copy of the data to the server. This will continue until the server replies that all data is safely on stable storage.

In other words, as long as you're using the "hard" mount option, there should *never* be a case of data corruption with NFS v3 asynchronous writes. If there is, it's a bug and needs to be treated as a bug. If you use the "soft" mount option then all bets are off because "soft" allows the client to time out an NFS request after a number of attempts and return an error up to the writing application. If the application doesn't know how to deal with that error and results in data corruption - that's the fault of the application.

Again, the "hard" mount option (which is the default) and NFS v3 guarantee data integrity for written data. If you have a case where data gets corrupted in this scenario it's likely either a bug or a hardware failure of some kind.

Regards,

Dave

[fabio sibillano]

Tnx to all for the answers.
My point of view is from a just-done
H3065S F.00 (hp-ux sys and net adm II) in the italian hp hq, but the documentation seems to be not updated, at this point...
i.e. still report the 128gb file limit for nfs 3.x at all.

Regards.

Fabio

[fabio sibillano]

solution found.