Re: async i/o via nfs?

"Volker Hetzer" <volker.hetzer_at_ieee.org> wrote in message news:bgtbe5$55l$1_at_news.fujitsu-siemens.com...

> Ok, I don't know about async i/o but what I had assumed is that oracle
> does some kind of out-of-band return value collection and errno check
> so that no stati get lost.

No need. Async I/O is part and parcel of the standard unix System V stuff. I think many aeons ago, Ingres had a special driver they loaded into Unix to do async I/O themselves. Oracle had something similar for AIX. But that was before Unix itself fully supported it and is not needed/used nowadays.

> Did. Thanks! Only, apart from the O_SYNC flag I got not much more.
> I'll check some more.

Look at file systems, ioctl. Do an apropos for "async". It varies with Unix systems. Might also work to do a search on google for the term, usually you get fairly good texts on anything Unix. Another thing is to look for it in IBM's AIX on-line doco: they have some good stuff there. HP has also some nice config stuff on it. And NCR used to have good info on it, but I'll be damned if I can find it anywhere!

> Okay, but only if I truly understand advice I can properly see whether
> it's relevant implementing or fighting with my boss over. Because first,
> things change and reliability of disks or nfs systems changes too and
> second, every environment is different and the availability/perfor-
> mance/safety requirements are different for every environment.

Sure. Not saying it will never improve. It's just that at current stage, I wouldn't trade a SAN for a NAS...

> Yeah, right. During my first three months I had two real problems:
> 1) a defective board which caused oracle to write wrong data to the disk
> without noticing it for several days. "Notification" came when a select
> complained about corrupt data. Naturally, the corrupt data was in the
> archived redo logs too, so no means of recovery. Errors were sprinkled
> across all sorts of tables. Fortunately we were still testing so no harm
> done.

Fun eh? :D
I don't miss the joy of the Pyramid SCSI1 controllers that used to wipe out an entire string of disks...

> After that local disks are definitely not the holy grail of storage for me
> anymore
> but just one part in the safety architecture which can fail like everything
> else. Or
> administrated into failing. So I've got to guard against local
> disk/system/people
> failure as well.

Yup. No contention there!

> So far my strategy is to have some files mirrored on a system that gets
> administered by
> a different group, runs a different OS and has a completely different
> hardware.

Not a bad idea, actually. But do that only when files are backed up or offline or all will break loose.

--
Cheers
Nuno Souto
wizofoz2k_at_yahoo.com.au.nospam