Kbase 12649: Why PROGRESS does NOT support DISK CACHE NFS or RFS until 9.1
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
19/09/2007 |
|
Status: Unverified
GOAL:
Why PROGRESS does NOT support DISK CACHE NFS or RFS until 9.1C
FIX:
You cannot use disk caching programs or remote filesystems such as NFS or RFS for the DB, BI or AI files. If you use them, PROGRESS cannot recover from crashes.
The PROGRESS database manager is designed to:
- Recover from failures and still provide transaction autonomy.
- Maintain the consistency of the internal structures of the database.
To ensure database integrity and recover from crashes, PROGRESS depends on its ability to do synchronous, unbuffered writes to the before-image log.
As you make changes to the database, PROGRESS buffers them in memory and defers writes to the DB file for a time. Over time, the in-memory state of the database diverges from the memory on the disk. However, PROGRESS logs all the changes in the before-image log before it writes the changes to the database. This is called write-ahead logging. If a failure occurs, the in-memory state of the database is lost.
During crash recovery, PROGRESS reads the BI files and uses them to reconstruct the in-memory state of the database at the time of the failure. It then rolls back any incomplete transactions, restoring the database to a consistent state again. Crash recovery works because:
* The BI file contains a record of ALL database changes that were made in-memory but not yet written to the disk-resident copy of the database.
* The disk-resident copy of the database DOES NOT contain any of the changes that PROGRESS recorded in the BI file.
Disk caching programs interfere with this carefully orchestrated sequence of events. A caching program writes to the disk in whatever order and whenever it chooses. PROGRESS does not know disk-caching is there and cannot control its behavior.
If you use a disk caching program, data which you think is on the disk might be buffered in memory somewhere. The data can be lost if a failure occurs. Because the caching algorithm might write changes to the disk before it writes them to the corresponding BI record, crash recovery can fail. The failure might not be obvious. For example, the system might not crash, but the database could be corrupted.
You cannot store the DB, BI, or AI files on NFS or other remotely mounted filesystems. NFS buffers data for both the server and the client. Caches on multiple clients are not synchronized and you cannot determine who has the most recent copy of a block from a file. NFS is inherently unreliable for databases.
Progress 9.1C removes the limitation prohibiting the use of NFS and allowing the use of NFS-mounted storage solutions where appropriate. This applies to all platforms EXCEPT Linux.
Progress 9.1E01 removes the limitation prohibiting the use of NFS and allowing the use of NFS-mounted storage solutions on Linux. Please check the solution P101496, "Progress 9.1E support for NFS on Linux?" for more information about the minimum requirements.