Lustre 1.6 Operations Manual

22.3.17 Handling/Debugging "LustreError: xxx went
back in time"
Each time Lustre changes the state of the disk filesystem, it records a unique
transaction number. Occasionally, when committing these transactions to the disk,
the last committed transaction number displays to other nodes in the cluster to assist
the recovery. Therefore, the promised transactions remain absolutely safe on the
disappeared disk.
This situation arises when:
■ You are using a disk device that claims to have data written to disk before it
actually does, as in case of a device with a large cache. If that disk device crashes
or loses power in a way that causes the loss of the cache, there can be a loss of
transactions that you believe are committed. This is a very serious event, and you
should run e2fsck against that storage before restarting Lustre.
■ As per the Lustre requirement, the shared storage used for failover is completely
cache-coherent. This ensures that if one server takes over for another, it sees the
most up-to-date and accurate copy of the data. In case of the failover of the server,
if the shared storage does not provide cache coherency between all of its ports,
then Lustre can produce an error.
If you know the exact reason for the error, then it is safe to proceed with no further
action. If you do not know the reason, then this is a serious issue and you should
explore it with your disk vendor.
If the error occurs during failover, examine your disk cache settings. If it occurs after
a restart without failover, try to determine how the disk can report that a write
succeeded, then lose the Data Device corruption or Disk Errors.
22.3.18 Lustre Error: "Slow Start_Page_Write"
The slow start_page_write message appears when the operation takes an
extremely long time to allocate a batch of memory pages. Use these pages to receive
network traffic first, and then write to disk.
22-16 Lustre 1.6 Operations Manual • September 2008