According to Jonathan Stone:
>
>My primary concern is wethher or not the vendor OSes force dirty data
>in the NVRAM to disk when they shutdown or reboot or panic. If they
>don't, there's a potential for inconsisency and dataloss for any
>reboot that ends up changing the OS -- possibly accidentally.
>

>From what I know of Sun's offering of prestoserve, the cache is not
flushed automatically when the machine goes down.  If you have the
correct command in the rc* files then the data will be flushed on
state transition but it is still very easy to down the machine and
leave dirty pages in the presto memory.  These pages are written back
on boot - presumably when the presto driver is brought up and notices
the dirty pages.  You can very easily confuse the presto driver just
by shifting disks around on scsi chains because it keeps an
association of the device number to the dirty page.  The presto driver
gets _very_ upset when it cannot find a device to write to ;-)

>Whether you think this is worth worrying about depends on how many
>people with PrestoSevre-aware vendor OSes would want to multiboot
>NetBSD on that same hardware.  Given that we don't currently support
>PrestoServe, a high fraction of the people out there who have
>PrestoServe hardware might not be running NetBSD and may want to
>initially multiboot NetBSD and <vendor OS> to convince themselves
>things really work.
>

Perhaps what we should do is work out what <vendor OS> uses to
determine that the data in the presto memory is valid and deliberately
choose a different scheme?  The worst that could happen then is that
the data in the presto is lost rather than random cruft being written
back to disk.

I am not really sure that the issue of "foreign" data in the presto
ram figures that large.  You are looking at a couple of seconds worth
of data on a busy 10Base network, less for a multihomed device.  If
the concern is still great then why not get the boot process to go
into single user mode and print a great big warning message iff the
presto driver finds a dirty presto ram that it does not recognise.
This way, at least, someone has to actually do something to screw up.
Even here <vendor OS> will be a problem but you cannot win them all.

>Sure, this terribly likely in the scheme of things; but I think
>_anything_ where NetBSD design could be blamed for the loss of user
>data should be avoided.
>

People ditzing with this sort of stuff on a production style machine
need an application of the ClueBat(tm), repeat treatment as
necessary.  Big warnings in manual pages & config files are all you
can do, just so they are warned.  When it comes down to it you cannot
protect people from themselves if they have enough access to be
playing around with this sort of stuff in the first place.

-- 
Brett Lymn, Computer Systems Administrator, British Aerospace Australia
===============================================================================
  +++ Divide By Cucumber Error.  Please Reinstall Universe And Reboot +++
  - Hogfather, Terry Pratchett.