Details
-
Bug
-
Resolution: Fixed
-
Major
-
None
-
Lustre 2.1.3
-
None
-
3
-
5491
Description
The problem comes when some tools try to detect changes in files thanks to the changelog functionality. The changelog is regularly read (every second) from a registered client (actually the only one registered) and then the records are acknowledged so they can be deleted in the changelog.
At the same time, on another Lustre client we run the next process every second on a file:
- Open a file
- Write of 1MB
- Sync file
- Close file
We would expect to see MTIME or OPEN or CREATE in the changelog but we don't see anything. The only way to see an MTIME event is to specify a SETATTR operation which provokes the modification on the MDT.
Another example of this pattern can be seen with the differences between cat and touch commands. If we run "cat whatever >> my_lustre_file", the MDT will never see the modification. If we run "touch my_lustre_file", then we'll see an MTIME event as touch command will specifically do SETATTR.
It is normal not to see any modification while the write is being done on the OSTs but my question is: shouldn't MDT see the modification once the file is closed? Because if applications must do a SETATTR then I'm not sure that changelog can be used to detect any kind of event.
Description of the reproducer:
- On the MDT:
[root@hsm6 ~]# cat /proc/fs/lustre/mdd/hsmfs-MDT0000/changelog_users
current index: 29724
ID index
cl1 29723
[root@hsm6 ~]# cat /proc/fs/lustre/mdd/hsmfs-MDT0000/changelog_mask
MARK CREAT MKDIR HLINK SLINK MKNOD UNLNK RMDIR RNMFM RNMTO OPEN CLOSE IOCTL TRUNC SATTR XATTR HSM MTIME CTIME
- On the changelog reader and while the write process is being run every second on another client:
>>>lfs changelog hsmfs-MDT0000
29723 00MARK 15:07:01.651522750 2012.11.07 0x0 t=[0x40001:0x0:0x0] p=[0:0x0:0x0] mdd_obd-hsmfs-MDT0000
>>>lfs changelog_clear hsmfs-MDT0000 cl1 29723
>>>lfs changelog hsmfs-MDT0000
29724 00MARK 15:07:07.399483862 2012.11.07 0x0 t=[0x40001:0x0:0x0] p=[0:0x0:0x0] mdd_obd-hsmfs-MDT0000
And the changelog will always remain in the last entry until the client acknowledges an entry (having then another MARK event).