> >I don't agree that this
> >is a valid concern - if we do a prestoserve, and we don't have
> >documentation to make it completely compatible, then we should just
> >say "DON'T SHARE THIS FS BETWEEN OPERATING SYSTEMS" in large,
> >prominent, unfriendly letters in the documentation.

> Fine with me.  But saying "IF YOU ENABLE PRESTOSERVE, DON'T SHARE
> _ANY_ FS BETWEEN OPERATING SYSTEMS", might be better.  (Along with
> making sure we do a good job of syncing dirty data on shutdown).

The whole point of the battery-backed RAM there is to survive spontaneous
crash-and-autoreboot cycles.  Now, an administrator might boot NetBSD as
a temporary measure just to try it out, while leaving the autoboot sequence
set to boot the traditional operating system, but I think an administrator
cautious enough to be interested in Prestoserve as a way to speed NFS (rather
than just having NFS always reply asynchronously) is someone who will not
tell his user base "OK, the NFS server is up and your data is guaranteed!"
Such an administrator might hammer on the NetBSD NFS server as a test of
reliability, but is unlikely to rely on that reliability until he's sure
enough of NetBSD to make it the autoboot kernel.  (Of course, if that admin
suffers a crash every hour for a week, eventually one of those crashes
will be followed by a manual boot of the old OS, but in that case, he's
likely to just restore all filesystems from tape anyway, I guess.)

So, if you make this assumption (if NetBSD crashes, NetBSD is what will be
autobooted, if the prestoserve card is in use) into a requirement, I think
you'd be on very solid ground.  In that case, switching OSes would normally
be done after a graceful shutdown, when there will presumably be no data
in the prestoserve card to be recovered after the crash.

One thing does occur to me, though:  the traditional prestoserve driver in
the traditional kernel *might* not be able to cope with seeing leftover
NetBSD data in the card, even if that leftover data is from a clean shutdown.
One would hope the card memory would be checksummed or something like that,
and the failed checksum would result in the traditional driver declaring it
corrupt and wiping it clean; however, if they did something horrible like
assuming that their driver was the only way to put data in there (and that
plugging in a fresh battery causes the memory to be automatically zeroed or
something like that), then they might not test "their" on-card data structures
for sanity...

This is assuming that the on-disk filesystem is a traditional UFS filesystem.
If Prestoserve has a customized on-disk layout as well, then complete
documentation of that would be needed, and probably some understanding of
precisely *how* metadata writes are ordered by the existing FS code.