On 11/11/2010 07:56, Kathey Marsden wrote:
I have always told users they have to have their databases on a local disk to ensure data integrity and that a system crash for an NFS mounted database could cause fatal corruption, but had a user this morning take me to task on this and ask me to explain exactly why. I gave my general response about not being able to guarantee a sync to disk over the network, but want to have a more authoritative reference for why you cannot count on an NFS mounted disk although I did find several places where the sync option "favors data integrity" which certainly doesn't sound like a guarantee. Does anyone know a good general reference I can use on this topic to support my "you gotta use a local disk" mantra.
Part of the issue is that that documentation is really old and file systems have moved on since it was written. There are other shared file systems that maybe do support integrity across the network with Derby, e.g. IBM's GPFS. Thus it's more complicated than local disk versus NFS.
Also I think our documentation on this topic should be a bit stronger. Currently we just say it may not work and probably should be clearer that data corruption could occur.
The documentation may need to state what Derby requires (sync through Java APIs ensure the data is recoverable) and then have per-file system sections, filled out on a scratch your own itch approach. E.g. even a local disk is not recoverable if the OS is performing disk caching.
Dan.
