[LU-5231] HSM: incorrect progress reported by lfs hsm_action

• Type: Bug
• Resolution: Unresolved
• Priority: Minor
• Affects Version/s: Lustre 2.6.0
• Labels: HSM patch
• Environment: Centos 6.5; Lustre 2.5.56
• Severity: 3
• Assignee: WC Triage
• Reporter: Frank Zago (Inactive)

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.

Comments

[Peter Jones]

My overzealousness I'm afraid - sorry. Reopening

[Cory Spitz]

I'm not sure why this ticket was marked resolved when http://review.whamcloud.com/12020 is still pending.

[Peter Jones]

Landed for 2.8

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch http://review.whamcloud.com/13678/
Subject: LU-5231 hsm: display file size in decimal not hex
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 9e40a86a875475f3fe1991a48694ba5601033ebe

[Gerrit Updater]

frank zago ([e-mail]) uploaded a new patch: http://review.whamcloud.com/13678
Subject: LU-5231 hsm: display file size in decimal not hex
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 1f8c980d4cd2328936e9dd484909c62a4a5fd8cc

[Vinayak Hariharmath (Inactive)]

Please observe the comments and kernel logs below.
Looking at these logs, I strongly feel that last extent alone will give proper amount of data moved.
Logs are taken in steps. Please observe the data->done_size in each step (numbered as 1, 2, 3....).
The values are repeating in each step which means whenever the ioctl is performed, the extents are
getting stored in tree. I believe we should not add up all these extents and the last entry in the
tree (last extent) will alone give the total amount of data moved.