OGAWA Hirofumi <hirofumi@xxxxxxxxxxxxxxxxxx> writes: > Jeff Layton <jlayton@xxxxxxxxxx> writes: > >> I'm a little confused too. Why do you believe this will break >> -o relatime handling? This patch changes two things: >> >> 1/ it has fat_update_time fetch its own timestamp (and ignore the "now" >> parameter). This is in line with the changes in patch #3 of this series, >> which explains the rationale for this in more detail. >> >> 2/ it changes fat_update_time to also update the i_version if any of >> S_CTIME|S_MTIME|S_VERSION are set. relatime is all about the S_ATIME, >> and it is specifically excluded from that set. >> >> The rationale for the second change is is also in patch #3, but >> basically, we can't guarantee that current_time hasn't changed since we >> last checked for inode_needs_update_time, so if any of >> S_CTIME/S_MTIME/S_VERSION have changed, then we need to assume that any >> of them may need to be changed and attempt to update all 3. >> >> That said, I think the logic in fat_update_time isn't quite right. I >> think want something like this on top of this patch to ensure that the >> S_CTIME and S_MTIME get updated, even if the flags only have S_VERSION >> set. >> >> Thoughts? > > I'm not talking about "relatime" at all, I'm always talking about > "lazytime". > > I_DIRTY_TIME delays to update on disk inode only if changed > timestamp. But you changed it to I_DIRTY_SYNC, i.e. always update on > disk inode by timestamp. And if change like it, why doesn't same change goes to generic_update_time()? It looks like generic_update_time() in this series doesn't work like you said. -- OGAWA Hirofumi <hirofumi@xxxxxxxxxxxxxxxxxx>
