Right, that's useful to know. The application that is sensitive to atime (and mtime) is using the combination to (dodgily) tell if a file is up-to-date with its index (which is in another file). If it isn't, the index is rebuilt.
The exact behaviour of the code isn't critical, we can change that to match how the file system works. We just needed to know how Lustre works. Anyway, thanks for the explanation. > This is likely because these clients have cached the MDS+OST locks for the > file and the read on the client will not invalidate those locks. If there > was other activity on those clients (e.g. lustre locks causing old entries > in the lock LRU to be expired, or memory pressure causing the inodes to be > evicted) then they would get the right atime on the next access. > >> Is this expected? The reason I ask is that we have an application which >> is sensitive to atime changes and it is running really really slowely. > > It sounds like a relatively fragile application model? Could you describe > in a nutshell what the application is trying to do? > > Cheers, Andreas -- Dr Stuart Midgley [EMAIL PROTECTED] _______________________________________________ Lustre-discuss mailing list [email protected] https://mail.clusterfs.com/mailman/listinfo/lustre-discuss
