offline

Dave's suggestion:

A). You should be able to debug this from the logs. Using pathDiag, the client log will tell you why it failed. Look for the last "========" in the log and use the NT stats to find the IO.

If the uServer(s) asserted you should have logs that the log aggregation will fetch for you. Please try and understand any asserts found.

Under RAID6 the client should still be able to write with 2 uServers down (and no other transient failures).

B). You need to start from the client and try to find the uServers that are causing the problem. From there the uServer logs will guide you. Since this is RAID6 the client is having problem with two uServers (since one is already down).

0725

1. Old version, mirror write, 2 offline, is there any assert in userver?
If it is yes, then 2 offline will lead to assert.
If the answer is no. Then we can draw a conclusion that the assert is not caused by 3 offline in Raid.


2. Old version, raid write, 3 offline, any assert? what happen in servers? compare with the assert case?

My qusetion.
1. What about assert(cacheEntry) fails?
   Make clear about everything about this assert.

The  problem :

1. One SE is taken offline, some SEs turn "no connection", i spent some time analyzed the SEs' log. but still have no idea to solve the problem.

also, is client read at this time. 

2. One intersting thing is that: When i am reading , i take offline, the test will finish with no error.

so, is only write's issue?

3. 5000 Hedorih, offline, NO AUTO recovery!

    5000 old version, can offline?

Idea or clue:

1. How about test offline on ISIS5000, debug on ISIS5000, since common code is based on 5000's code.

2. I use 4.0 client and connect to 2.4 server. and do read, the phenomenon is the same as offline of Hedorah...

offline relative:

1. Offline Timeout： Indicates the amount of time (in seconds) a Storage Element is offline before the System Director logs an error message

2. Offline:  the Storage Element has been taken offline, usually in preparation for removal