[LU-5231] HSM: incorrect progress reported by lfs hsm_action Created: 18/Jun/14  Updated: 03/Sep/15

Status: Reopened
Project: Lustre
Component/s: None
Affects Version/s: Lustre 2.6.0
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Frank Zago (Inactive) Assignee: WC Triage
Resolution: Unresolved Votes: 0
Labels: HSM, patch
Environment:

Centos 6.5
Lustre 2.5.56


Attachments: Text File LU-5231_logs.txt    
Severity: 3
Rank (Obsolete): 14572

 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   
Comment by Frank Zago (Inactive) [ 18/Jun/14 ]

copytool is standard posix copytool.

Comment by Vinayak Hariharmath (Inactive) [ 22/Sep/14 ]

Posted changes for fixing this issue on b2_6

http://review.whamcloud.com/12006

Comment by Peter Jones [ 22/Sep/14 ]

Vinayak

Could you please push your proposed patch against master?

Thanks

Peter

Comment by Vinayak Hariharmath (Inactive) [ 23/Sep/14 ]

Hi Peter,

Pushed the changes to master branch.
http://review.whamcloud.com/12020

Thanks,
Vinayak

Comment by Vinayak Hariharmath (Inactive) [ 26/Sep/14 ]

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.

Comment by Gerrit Updater [ 06/Feb/15 ]

frank zago (fzago@cray.com) 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

Comment by Gerrit Updater [ 08/Mar/15 ]

Oleg Drokin (oleg.drokin@intel.com) 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

Comment by Peter Jones [ 07/Jul/15 ]

Landed for 2.8

Comment by Cory Spitz [ 03/Sep/15 ]

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

Comment by Peter Jones [ 03/Sep/15 ]

My overzealousness I'm afraid - sorry. Reopening

Generated at Sat Feb 10 01:49:39 UTC 2024 using Jira 9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c.