Questions about checkld recover LD

[louisji2008]

The checkld command with -p -recover option is running for 12 hours, the LD size is around 70GB.
1. Is the recover speed normal?
2. How can I know the number of chunklets need to be recovered?
3. After checkld finished, should I execute checkvv?
4. How to resolve the question: I've run checkvv, the showtask displayed "There is no SA/SD space for volume xxx", then the command just finished.

[sbhat09]

Hi Louis,

Are you still facing the issue? If yes, please if the below is useful for you:

1. 12 hours is not the ideal time it may take. It is longer than normal for the task.

2. YOu may verify with checkld -progress

3. After finishing checkld, you can validate with showld -vv <vv_name>

4. Can you please share the complete command output for showtask -d <task_id>

Regards,

Srinivas

[louisji2008]

Hi,

here are the shwold  commands.

[louisji2008]

Before run the checkld -y -progress -recover command, I found  the state of a chunlet 364:504  is "logging", as all the others are normal:

60 0 7 14:8:0 415 506 normal ld valid N --- ---
61 0 7 10:8:0 344 507 normal ld valid N --- ---
62 0 7 15:7:0 500 507 normal ld valid N --- ---
63 0 7 8:9:0 364 504 logging ld valid N --- ---
64 0 8 9:7:0 446 500 normal ld valid N --- ---
65 0 8 12:7:0 404 500 normal ld valid N --- ---

So I run the checkld command:

checkld -y -progress -recover 364:504 B3-C7000-VM.63.usr.3 
Performing a kernel level consistency check, will try to fix inconsistencies
ld B3-C7000-VM.63.usr.3 has 9 rsets, checked 7, inconsistent 0
0 out of 1 lds ( 7 out of 9 rsets) have been checked, will check the ldck progress in 5 seconds ...

this command has run for 3 days, the current output is:

ld B3-C7000-VM.63.usr.3 has 9 rsets, checked 8, inconsistent 0
ld B3-C7000-VM.63.usr.3 has 9 rsets, checked 8, inconsistent 0
ld B3-C7000-VM.63.usr.3 has 9 rsets, checked 8, inconsistent 0
ld B3-C7000-VM.63.usr.3 has 9 rsets, checked 8, inconsistent 0

[sbhat09]

Hi Louis,

When a connection is lost to a physical disk or a physical disk fails, all future writes to the disk are automatically written to a logging LD until the physical disk comes back online, or until the time limit for logging is reached. Logging disk space is allocated when the system is set up. If the time limit for logging is reached, or if the logging LD becomes full, the relocation of chunklets on the physical disk to free chunklets designated as spares starts automatically.

So, this is not an issue to be concerned much. When the system goes on writing data and all the chunklets in the 'logging' LD are relocated to different LD, logging state will recover. As the LD size is bigger, it logging state may persist for an extended period.

Regards,

Srinivas