From bb8c2b0087e87a28b0c96fdea1f0f0dacf0589b3 Mon Sep 17 00:00:00 2001 From: Richard Henwood Date: Fri, 20 May 2011 13:40:24 -0500 Subject: [PATCH] FIX: validation, ulink -> link --- LustreRecovery.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/LustreRecovery.xml b/LustreRecovery.xml index b18a41b..603c9a7 100644 --- a/LustreRecovery.xml +++ b/LustreRecovery.xml @@ -101,7 +101,7 @@
30.1.6 Failed Recovery - In the case of failed recovery, a client is evicted by the server and must reconnect after having flushed its saved state related to that server, as described in Client Eviction, above. Failed recovery might occur for a number of reasons, including: + In the case of failed recovery, a client is evicted by the server and must reconnect after having flushed its saved state related to that server, as described in , above. Failed recovery might occur for a number of reasons, including: Failure of recovery @@ -160,7 +160,7 @@ 30.2.7 Gaps in the Replay Sequence In some cases, a gap may occur in the reply sequence. This might be caused by lost replies, where the request was processed and committed to disk but the reply was not received by the client. It can also be caused by clients missing from recovery due to partial network failure or client death. In the case where all clients have reconnected, but there is a gap in the replay sequence the only possibility is that some requests were processed by the server but the reply was lost. Since the client must still have these requests in its resend list, they are processed after recovery is finished. - In the case where all clients have not reconnected, it is likely that the failed clients had requests that will no longer be replayed. The VBR feature is used to determine if a request following a transaction gap is safe to be replayed. Each item in the file system (MDS inode or OST object) stores on disk the number of the last transaction in which it was modified. Each reply from the server contains the previous version number of the objects that it affects. During VBR replay, the server matches the previous version numbers in the resend request against the current version number. If the versions match, the request is the next one that affects the object and can be safely replayed. For more information, see Version-based Recovery. + In the case where all clients have not reconnected, it is likely that the failed clients had requests that will no longer be replayed. The VBR feature is used to determine if a request following a transaction gap is safe to be replayed. Each item in the file system (MDS inode or OST object) stores on disk the number of the last transaction in which it was modified. Each reply from the server contains the previous version number of the objects that it affects. During VBR replay, the server matches the previous version numbers in the resend request against the current version number. If the versions match, the request is the next one that affects the object and can be safely replayed. For more information, see .
30.2.8 Lock Recovery -- 1.8.3.1