[LU-7493] Mess of atime of OST objects Created: 27/Nov/15 Updated: 17/Aug/18 Resolved: 17/Aug/18 |
|
| Status: | Closed |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Minor |
| Reporter: | Li Xi (Inactive) | Assignee: | Li Xi |
| Resolution: | Not a Bug | Votes: | 0 |
| Labels: | None | ||
| Severity: | 3 |
| Rank (Obsolete): | 9223372036854775807 |
| Description |
|
I am not sure whether it is a feature or not (maybe not). But currently there are some problems of timestamps on OST. 1) If use ‘lfs setstripe’ to create a file, the OST object(s) won't have any atime/ctime/mtime So, is there any special reason of these behaviors? I understand it won't cause any problem to the POSIX semantics on Lustre client. And we can even avoid performance degredation by using noatime on OST. But we need to make sure everything is behaving in the way that we expect. |
| Comments |
| Comment by Andreas Dilger [ 27/Nov/15 ] |
|
The atime handling on OSTs is intended to avoid overhead during reads. The initial timestamp on the OST objects is set so that it will always be updated by any real timestamp from the client, and so that the inode timestamp on the MDT is newer unless the OST object was updated after creation, so setting the OST atime to zero is not harmful - the client will use the newer MDT inode atime instead. . The OST object atime is updated in memory during each read, so that if one client reads the file and then another client stats the file it will have the correct atime. The atime update on the OST will not update the inode on disk unless the inode is modified again for some other reason, and it will not revoke the locks held by clients, so any atime fetched by a client will be cached by that client until it loses its lock on the object. The atime is written to disk only on the MDS when the file is closed, and only if it is (by default) more than 60s out of date (this can be tuned in /proc). That avoids thousands of atime updates when many clients close the same file. In combination with the OSS in memory cache of atime, clients will typically see the correct atime, and it will be saved to disk on file close, unless all the clients reading the file crash or are evicted. Is there a specific problem you are seeing with atime on the clients, or is this only a question about how atime works? It might be useful if you could put the above in a comment, maybe near the OST atime updates so that it is available for other developers. |
| Comment by Andreas Dilger [ 27/Nov/15 ] |
|
To clarify your comment about writes updating the atime to zero - is that only on the first write, or does that always happen for any write? That probably is not correct if it happens on every write. Either the o_atime should contain valid atime, or the OBD_MD_FLATIME flag should not be set. |
| Comment by Li Xi (Inactive) [ 28/Nov/15 ] |
|
Hi Andreas, Thank you very much for the explanation. I might need some time to read it through. I am interested in atime on OST because I am implementing a policy engine on OST side for cache. And as you can image, atime could be a useful attribute to determine to prefetch an object to cache or not. So, at least, I need to understand what is the expected behavior of atime. Following is the result that I got from ofd_attr_get(). Can I say all the behaviors are all expected? It seems atime on OST is not updated after read. So, which way should I use to get the cached atime in memory, please? Timestamps after using "lfs setstripe" to generate a empty file |
| Comment by Li Xi (Inactive) [ 28/Nov/15 ] |
|
And sorry, ofd_commitrw_write() does NOT update the atime to zero according to the results. I was surprised that LA_ATIME was not filtered in ofd_commitrw_write() because write should NOT change atime. |
| Comment by Andreas Dilger [ 30/Nov/15 ] |
|
The write should update the atime if it is updated from a previous read, since the read itself won't update atime on disk. Can you check that the read RPC is properly sending the atime from the client and setting OBD_MD_FLATIME. Otherwise it can't do anything. |
| Comment by Li Xi [ 17/Aug/18 ] |
|
I am closing this ticket since I feel this might not be a problem. Thanks! |