https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-7493 Lustre <p>I am not sure whether it is a feature or not (maybe not). But currently there are some problems of timestamps on OST. </p> <p>1) If use ‘lfs setstripe’ to create a file, the OST object(s) won't have any atime/ctime/mtime<br/> 2) Writing to an OST object will update atime to zero. However, atime should only be updated when reading the file. And, the value of atime shouldn't be updated to zero in any sense.<br/> 3) Reading an OST doesn't update the atime.</p> <p>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.</p> LU-7493

Mess of atime of OST objects

Bug Minor Closed Not a Bug Li Xi Li Xi Fri, 27 Nov 2015 15:38:40 +0000 Fri, 17 Aug 2018 00:47:54 +0000 Fri, 17 Aug 2018 00:47:54 +0000 0 3 <p>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. .</p> <p>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 <b>not</b> update the inode on disk unless the inode is modified again for some other reason, and it will <b>not</b> 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. </p> <p>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. </p> <p>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. </p> <p>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. </p> <p>Hi Andreas,</p> <p>Thank you very much for the explanation. I might need some time to read it through.</p> <p>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.</p> <p>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?</p> <p>Timestamps after using "lfs setstripe" to generate a empty file<br/> obdfilter.ofd_cache.prefetch_rule=atime <br/> Result: 0<br/> obdfilter.ofd_cache.prefetch_rule=mtime <br/> Result: 0<br/> obdfilter.ofd_cache.prefetch_rule=ctime <br/> Result: 0<br/> Timestamps after "sleep 3 &amp;&amp; dd if=/dev/zero of=FILE bs=1048576 count=10 &amp;&amp; sync"<br/> obdfilter.ofd_cache.prefetch_rule=atime <br/> Result: 0<br/> obdfilter.ofd_cache.prefetch_rule=mtime <br/> Result: 1448645957<br/> obdfilter.ofd_cache.prefetch_rule=ctime <br/> Result: 1448645957<br/> Timestamps after "sleep 3 &amp;&amp; dd if=FILE bs=/dev/null of=FILE bs=1048576 " again<br/> obdfilter.ofd_cache.prefetch_rule=atime <br/> Result: 0<br/> obdfilter.ofd_cache.prefetch_rule=mtime <br/> Result: 1448645957<br/> obdfilter.ofd_cache.prefetch_rule=ctime <br/> Result: 1448645957<br/> Timestamps after "sleep 3 &amp;&amp; touch"<br/> obdfilter.ofd_cache.prefetch_rule=atime <br/> Result: 1448645964<br/> obdfilter.ofd_cache.prefetch_rule=mtime <br/> Result: 1448645964<br/> obdfilter.ofd_cache.prefetch_rule=ctime <br/> Result: 1448645964<br/> Timestamps after "sleep 3 &amp;&amp; dd if=/dev/zero of=FILE bs=1048576 count=10 &amp;&amp; sync" again<br/> obdfilter.ofd_cache.prefetch_rule=atime <br/> Result: 1448645964<br/> obdfilter.ofd_cache.prefetch_rule=mtime <br/> Result: 1448645967<br/> obdfilter.ofd_cache.prefetch_rule=ctime <br/> Result: 1448645967</p> <p>And sorry,</p> <p>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.</p> <p>The write should update the atime if it is updated from a previous read, since the read itself won't update atime on disk. </p> <p>Can you check that the read RPC is properly sending the atime from the client and setting <tt>OBD_MD_FLATIME</tt>. Otherwise it can't do anything. </p> <p>I am closing this ticket since I feel this might not be a problem. Thanks!</p> Development End date Mon, 30 Nov 2015 15:38:40 +0000 Rank 1|hzxufr: Rank (Obsolete) 9223372036854775807 Severity Start date Fri, 27 Nov 2015 15:38:40 +0000