Details
Description
While archiving a 5GiB file on a client:
# ls -l bigf -rw-r--r-- 1 root root 5129887744 Jun 18 16:48 bigf # lfs hsm_archive bigf
I repeatedly checked the progress with lfs hsm_action:
bigf: ARCHIVE running (0xa00000 bytes moved) ... bigf: ARCHIVE running (0x3200000 bytes moved) ... bigf: ARCHIVE running (0x6400000 bytes moved) ... ... ... bigf: ARCHIVE running (0x1a0e500000 bytes moved) ... bigf: NOOP
The last result should have been close to 5 GiB, instead it was 0x1a0e500000 = 111909273600 = 104GiB
It appears the (correct) lengths sent by the copytool through llapi_hsm_action_progress() are being added somewhere in the kernel modules.
Also, is there a reason for the reported size to be written in hex? It's not convenient.
Attachments
Activity
Resolution | Original: Fixed [ 1 ] | |
Status | Original: Resolved [ 5 ] | New: Reopened [ 4 ] |
Fix Version/s | Original: Lustre 2.8.0 [ 11113 ] |
Fix Version/s | New: Lustre 2.8.0 [ 11113 ] | |
Resolution | New: Fixed [ 1 ] | |
Status | Original: Open [ 1 ] | New: Resolved [ 5 ] |
Labels | Original: HSM | New: HSM patch |
Attachment | New: LU-5231_logs.txt [ 15850 ] |
My overzealousness I'm afraid - sorry. Reopening