This Knowledgebase article details a known issue that may arise when compressing a large protected file on a server running Neverfail Heartbeat.
- The Neverfail Channel connection between the two servers is lost.
- The System status on the Active server states: "Stopping replication".
- The following error is logged on the Passive server: Unrecoverable error in the NF Channel.
The compression application (which might be Explorer) sends a file system control request called FSCTL_SET_COMPRESSION to the file system for the file in question. This request is seen by the filter driver which sends a "compression request" message to apply and then passes the request down the file system stack on its way to the file system driver (it might pass through other filter drivers before it reaches the file system).
The NTFS implementation of compression causes the file to be mapped and causes page writes for the complete file to be sent back through the entire file system device stack. There appears to be no specific or signature relationship between the file object, the thread context in the compression request, and the page writes. In any case, the file can be written, using regular or paged writes, while the compression operation is in progress. The filter driver sends a write message to apply for each of these page writes since the file was memory mapped.
Once these page writes are all done, the file system completes the compression request. This is visible to the filter driver, which then sends a "compression complete" message to apply. The complete message contains the completion status, which can indicate success or failure.
In the current model, apply cannot process the "compression request" until the "compression complete" message is received. In the mean time, the page writes will be received and buffered on the passive server.
The proposed solution for the specific base issue with compression as described is that apply should process the compression in completion order as opposed to request order.
The second issue, which will need to be addressed, is the time taken for the compression operation for a large file, which can be somewhat long. In the current model, apply will not be able to perform other operations while the compression operation is in progress. This will also lead to the backing up of messages in the passive server (safe) queue buffers and could lead to similar or identical effects.
The proposed solution for the second issue is that apply should perform the compression operation in an alternative thread and continue to process other operations while the compression operation is in progress.
Currently, A Resolution Does Not Exist