NBUF and pstat

sramtrc at windy.dsir.govt.nz sramtrc at windy.dsir.govt.nz
Fri Jan 18 22:39:59 AEST 1991


In article <2676 at dftsrv.gsfc.nasa.gov>, jim at jagubox.gsfc.nasa.gov (Jim Jagielski) writes:
> Anyway, this all leads to an interesting question... certainly, as far as
> disk buffers are concerned, there is a point of diminishing returns where
> increasing the amount of buffers adds very little or even DECREASES performance
> (possibly). Does anyone have any good system tuning information for A/UX...
> 25% memory for NBUF seems about right, but with large systems (32 megs) that
> still leaves a good chunk of free memory... Of course, that isn't bad since
> that means that swapping won't occur :)

As I understand it the bigger the disk cache, the better the performance
because the less the actual disk has to be accessed. Accessing RAM is faster
than accessing iron so the more there is in RAM the better. And the more
the NBUFS, the more the RAM available for caching. If you are doing program
development this is really useful because the compiler, the include files,
and all the tmp files stay in RAM and that's a lot of disk accesses that
are saved. There are still some disk accesses that are not "necessary"
because the ufs filesystem writes enough stuff to disk immediately to be
able to maintain filesystem consistency in case of a crash.

I'm not sure what happens in the event of a crash with a large cache. I
think the larger the cache the more data you lose. But definitely you do
lose data in any crash. How much depends on how long since the last sync.
I do kernel programming so I'm used to dealing with crashes so I'm in the
habit of doing syncs before running dodgy software. Especially more so now
that MacOS programs can crash the kernel. I include a sync in my makefiles
in case I forget.

Twice now I have rebooted after a crash to find my current work missing.
This is quite disconcerting because one never has backups of the past few
hours work. I don't know why this happens. Files never used to disappear
completely with the svfs filesystem. In both cases I was able to recover
my files from the raw disk and the recovered files seem to be the most
recent versions ie the data did make it to disk.

Tony Cooper
sramtrc at albert.dsir.govt.nz



More information about the Comp.unix.aux mailing list